The Semantics of Our Design System

As a designer, it is with great awe that you look at all the formalities and conventions that are available for developers regarding syntax and semantics. There is seemingly no end to the resources and discussions. And yet, being the designer sitting just at the opposite end of the desk, there is almost nothing to go by.

With all the tools made for the purpose of designing digital products at our current disposal (e.g. Sketch, Zeplin, Abstract and Principle), all we can do is create faux naming conventions to help maintain our sanity and velocity in collaborating with one another.

Sprinkled with a tad bit of inspiration from BEMing

My layman fiddling with CSS has brought BEMing to my attention. BEMing is also an approach to create structure in a place where there historically has been none.

Instead of BEMing’s component, element (_ _), and modifier (- -), we are currently using a naming convention built on view, component, state/intent (#), addition modifier (+), subtraction modifier (-), and size context (@):

Views

• Name: The name of the view in its intended default state, e.g. Login.
• Name #State: A state or modification of a view, e.g. Login #Error.
• Name @Size: The size or context, e.g. Login @Large. Sketch and Figma’s constrains features has slowly but surely made this attribute superfluous.

We also combine them: Login #Error @Small.

Components

• Name: The name of the component in its intended default state, e.g. Password.
• Name #State: A state or intent of a component, e.g. Password #Focus.
• Name +Name: A modification of the default state by added elements, e.g. Password +Feedback.
• Name -Name: A modification of the default state by subtracting elements, e.g. Password -Preview switch.
• Name @Size: The size or context, e.g. Search @Large for different renditions of components or icon sets.

We also combine them: Password #Error +Feedback #Length.

Wait, what?

Yes, it might seem complex and over-engineered, and to some extent it is. We design for a white-label product; that means working with a huge amount of views, components, and variations. A certain degree of complexity is unavoidable for us as long as naming files, groups, and layers are basically the only means we have to create structure in a system.

To be fair, we only use it on a component level in our component library, and not in every design of every view we ever do. Most of the time, doing it on a view level is enough.

On the subject of complexity, if you pair this approach with How We Set Up Zeplin, you get traceability like this as a bonus:

SPK-Sprint-31/iOS/SPK-365/Login/Password #Focus

which reflects the taxonomic structure of

Sprint/Platform/Story/View/Component