Building and Scaling Design Systems. Expansion — Design Methodology. Version 0.1 (Draft)

Updated to version 1.0

There are a huge number of solutions on the Internet on how to work with design systems, where the authors explain how to… Not really.

Design Methodology

Available solutions and their problems

1. No solutions to save time, just words.
2. No solutions for real flexible consistency.
3. No way from a to z.
4. No explanation for the product design process and it’s changeable, scalable and iterative nature.
5. No information about versioning.
6. No options for borrowing for companies with multiple products.
7. No solutions for storing and conducting experiments.
8. …

Problems of available tools

1. Only nested structure with slashes like “my-button/my-button-xl/my-button-xl-hover”.
2. No parallel attributes.
   Have you seen this aircraft control panel? This is the best anti-advertising. https://www.figma.com/file/TkXJANnvQfS4sH8UE2W6zx/Material-Design-Theme-Kit-Copy?node-id=0%3A6209
3. Strong abstraction from the realities of development.
4. No generation to demonstrate your design system.
   You will have to move the elements for easy display to team members, and if you change something — repeat.
5. No solutions for content data management and its switching between mock and real.
6. No functional for information architecture, at least elementary.
7. Nothing about proper versions and switching between them.
   Where is my alpha, beta, candidate indicators? Developers are much closer to reality and some companies sell us a graphics editor as a design tool!
8. …

But…

We’re designers. We somehow have to do our job using the available tools.

Obligatory values

1. Focus
2. Collaboration
3. Reality
4. Flexibility
5. Continuity
6. Evolution
7. Clarity

Tight-packed process

To begin with let’s talk about how the process look like.

1. Focus & Understand the problem
   business model, industry, research, competitors, requirements, …
2. Define & Prototype the solutions
   hypotheses, methods, flow maps, visualizations, tests, …
3. Deliver & Evaluate the resolution
   finalization, docs, reviews, analytics, feedback, …

I could draw a beautiful diagram with a bunch of clever words and a lot of steps. But we’re here for another reason.

Fractions and naming convention

Now we need to identify the necessary fractions from the above process.
It is important to understand that I am considering all from the prism of available tools (Figma, Sketch…) and the limitations inside them.

1. If the value starts with a number use square brackets:
   a.123 → a[123]
   In other cases, use dots as a separator to show nesting:
   a.b
2. Allowed symbols:
   a-z, 0–9, [], {}, emojis, glyphs
3. If the name contains several words — use camelCase:
   my button → myButton
4. For fraction nesting, use slashes:
   a/b/c
5. Fractions can work with parameters:
   1 parameter: a.(b=c)
   ≥1 parameters: a.({b:c}), a.({b:c, d:e})
6. Tools have limited space to display titles so use acronyms and emojis actively.
7. If you have two parameters starting with the same letter-use a two-letter acronym:
   closed & completed → cl & cm
8. Use titles that reflect the essence.
   —
   Bad
   Color: red
   Grid: columns
   Effect: shadow
   —
   Good
   Color: danger
   Grid: icon
   Effect: elevation

Be careful when using Emoji. They may not appear or appear differently on different devices.

📡 Abstraction (acronym: a)

This is the top-level — all other fractions come from here. Each project can have multiple abstractions. For example: root, 2560, 1368, 414, … One abstraction can extend another one: 1368 extends root …
This logic is necessary for scalability. You can build one design system with the root abstraction and extend it in other projects building the new system on top of it, without increasing the specificity. Root — should be dry without any specificity.

🍽 Platform (acronym: p)

As you already understood from the name: desktop, web, mobile, ios, android, ie8, windows xp, … Here is the same logic for scaling as in abstractions. Each abstraction could have several platforms inside and one platform can extend another one: ios extends mobile. All niche situations, when you need to maintain something old, are fixed here also: font fall backs; outdated browsers outdated, cheap and weak gadgets…

Structure examples
abstraction.root
__abstraction[2560]
____platform.desktop
____platform.web
__abstraction[414]
____platform.mobile
______platform.ios
– or –
📡.root
__📡[2560]
____🍽.desktop
____🍽.web
__📡[414]
____🍽.mobile
______🍽.ios
– or –
a.root
__a[2560]
____p.desktop
____p.web
__a[414]
____p.mobile
______p.ios

🌈 Theme (acronym: t)

All stylistic and decorative moments should be fixed here. This fraction also have the root theme which can be extended. Examples: root, dark, light, blackFriday, foolsDay; light extends root.

Usage
📡[2560]/🍽.web/🌈.light…
– or –
a[2560]/p.web/t.light…

💫 Level (acronym: l)

This displays the complexity of the component or its type.
Use Atomic Design levels here: atoms, molecules, organizations, templates, pages. Each component could contain a component with a lower level of complexity: form contains button, button contains link.

Page level should have parameter:
📼 data (acronym: d)

Keep 2 data variants of each page:
🏔 mock (acronym: m)
🌋 real(acronym: r)

Usage
…/🍽.web/🌈.light/💫.page(📼=🏔)…
– or –
…/🍽.web/🌈.light/💫.Ⓟ(d=m)…
– or –
…/p.web/t.light/l.p(d=m)…

The parameters in fractions working in the following way:
1 parameter: page.(d=m)
≥1 parameters: page.({d:m}), page.({d:m, x:y})

🎸 Band (acronym: b)

If you’ve ever used atomic design, you’ve probably noticed the inconvenience of searching for categories where all the entities would be grouped by type: form, navigation, message, header, ... That’s what we use bands for.

Usage
…/🌈.light/💫.organism/🎸.form…
– or –
…/🌈.light/💫.Ⓞ/🎸.form…
– or –
…/t.light/l.o/b.form…

🍰 Component (acronym: c)

Here you need to understand what types of entity the tool itself has.
Essential types are:

⚽ symbol (acronym: s)
📝 text (acronym: t)
🎨 color (acronym: c)
🎢 effect (acronym: e)
🥅 grid (acronym: g)

No need to add component types if they are already separated in your tool:

Usage
…/💫.organism/🎸.form/🍰.signUp…
– or –
…/💫.Ⓞ/🎸.form/🍰.signUp…
– or –
…/l.o/b.form/c.signUp…

But if not:

Usage
…/💫.organism/🎸.form/🍰.⚽.signUp…
– or –
…/💫.Ⓞ/🎸.form/🍰.⚽.signUp…
– or –
…/l.o/b.form/c.s.signUp…

🔱 Version (acronym: v)

Since no tool currently, give you a true versioning system (VCS), and the functionality that is provided mostly awful.
The most popular naming convention now is Semantic Versioning or SemVer.

Briefly it looks like this: major.minor.patch → 2.12.8

https://semver.org/spec/v2.0.0.html
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

What does it mean to us?
MAJOR when you change the logic of the previous version of the component: big edits, different goals, different context. Big step — in a word.
MINOR when your changes relate to improving the current solution: improvements, fine-tuning, refinements.
PATCH when you forgot something or made a mistake.

Usage
…/🎸.form/🍰.signUp/🔱[2.12.8]…
– or –
…/b.form/c.signUp/v[2.12.8]…

Version value starts with a number that’s why we’re using square brackets

🎲 Quiz (acronym: q)

There always comes a time when the team does not know what version to deliver and then experiments come to our aid. There can be any number of them inside each version.

Usage
…/🍰.signUp/🔱[2.12.8]/🎲[1]…
…/🍰.signUp/🔱[2.12.8]/🎲[2]…
– or –
…/c.signUp/v[2.12.8]/q[1]…
…/c.signUp/v[2.12.8]/q[2]…

🏷 Release (acronym: r)

Here we go back to the already mentioned version naming methodology of Semantic Versioning or SemVer, which adds even more meaning and brings us closer to reality with release indicators. We’ll use the following:

🛴 alpha (acronym: a)
🚙 beta (acronym: b)
🚁 candidate (acronym: c)
🚀 production (acronym: p)

Each next step has more weight and more chances for stable and predicatble result than the previous ones.You can also use numbers after indicators for iterations. Both version and quiz fractions could have release indicators.

Usage
…/🍰.signUp/🔱[2.12.8]/🏷.🛴[1]…
…/🍰.signUp/🔱[2.12.8]/🎲[1]/🏷.🛴[1]…
– or –
…/c.signUp/v[2.12.8]/r.a[1]…
…/c.signUp/v[2.12.8]/q[1]/r.a[1]…

🚦 Flag (acronym: f)

To make it easier for your colleagues to understand at what stage the work is — add status flags. Managers can quickly find components awaiting review.

📬 new (acronym: n)
📖 open (acronym: o)
🔮 work (acronym: w)
💤 pause (acronym: p)
🔬 review (acronym: r)
💈 fix (acronym: f)
🎉 done (acronym: d)
🚪 closed (acronym:c)

Usage
…/🍰.signUp/🔱[2.12.8]/🏷.🛴[1]/🚦.🔮…
…/🍰.signUp/🔱[2.12.8]/🎲[1]/🏷.🛴[1]/🚦.🔮…
– or –
…/c.signUp/v[2.12.8]/r.a[1]/f.w…
…/c.signUp/v[2.12.8]/q[1]/r.a[1]/f.w…

📿 Kind (acronym: k)

This parameter is used to list the component variants:
Basic: initial, closed, filled, outlined, loading, disabled, visited, …
Advanced: completed(bad=all), completed(bad=some), completed(good=all), completed(good=requiredOnly), …

If you have two parameters starting with the same letter-use a two-letter acronym: closed & completed → cl & cm

Usage
…/🍰.signUp/…/🚦.🔮/📿.🏆(✅=ro)
– or –
…/🍰.signUp/…/🚦.🔮/📿.c(g=ro)
– or –
…/🍰.signUp/…/🚦.🔮/📿.completed(good=requiredOnly)
– or –
…/c.signUp/…/f.w/k.c(g=ro)

📐 Size (acronym: s)

Do not use standard, clumsy names: XL, L, M, S,… Otherwise, you will have to refactor your components every time. Use cities, letters, rivers, waterfalls, … – something that has progression.

The process:

Usage
…/🍰.heading/…/📐.m
– or –
…/c.heading/…/s.m

🚿 Emphasis (acronym: e)

This fraction categorizes the expressiveness and mood of the components.
Examples: primary, secondary, tertiary, handy, risky, danger.

Usage
…/🍰.button/…/📐.m/🚿.💥
– or –
…/🍰.button/…/📐.m/🚿.p
– or –
…/🍰.button/…/📐.m/🚿.primary
– or –
…/c.button/…/s.m/e.p

🤺 Interaction (acronym: i)

For working with events.

🔦 focus (acronym: f)
🦋 hover (acronym: h)
🌪 drag (acronym: d)
🗞 press (acronym: p)
💍 select (acronym: s)

Usage
…/🍰.button/…/📐.m/🤺.🗞
– or –
…/🍰.button/…/📐.m/🤺.p
– or –
…/🍰.button/…/📐.m/🤺.press
– or –
…/c.button/…/s.m/i.p