Introduction

Is your design system documentation filled with ambiguous language, using words like 'sometimes,' 'often,' and 'maybe'?

You want to give answers, yet everything seems so indecisive.

My initial documentation was just like that. I didn't want the design system to be too strict for designers. Secondly, I felt uncomfortable making unambiguous statements as I couldn't foresee how a component would be used in a particular use case.

When it comes to keeping the consistency of design in check, transparent processes and documentation will do the work for you. However, it is impossible to govern a design system without having definitive answers – without, it is all up to the interpretation of an individual designer, applying their own rules to their use case.

Free rein to the designer, hooray! Or not at all?

I can tell you there is a middle ground…

Away with anxiety

You need to address your anxiety about becoming too strict and lacking oversight of how components are applied.

It was exhausting to get myself familiarized with all the use cases. But in the end, I knew how every component was applied IRL. Once I identified all the use cases and straightened things out and called it the status quo.

The ‘Consolidation Process’ facilitated changes made to the status quo. This transparent process is now part of the Fintech company housing more than 60 opinionated designers.

Based on the Dutch polder model, the process is about consensus decision-making via dialogue, with every party having an equal say. It gets its name from the Dutch word polder for tracts of land enclosed by dikes. Without a common objective, ‘polderen’ (verb) could ponder forever. But with it, the outcome is bolstered by shared concerns, experiences, and ideas.

Rather than policing, the process gave designers free range to experiment with new ideas and let them challenge the status quo. With the objective to complement all use cases affected by it. It was up to the designer community to gather all these use cases. In this way, the community kept giving me an up-to-date view of the current use cases per change.

This process has its roots in a Dutch company but is used by international companies and agencies too.

Accuracy matters

With my anxieties out of the way, I felt more comfortable writing unambiguous documentation.

Starting with language, I changed everything that was stated imprecisely to definitive statements; addressing sentences that are using words like ‘can,’ ‘sometimes,’ ‘often,’ and ‘maybe.’

Secondly, I scouted for incomplete ambiguity by stating what related problems the component was NOT designed for. As a bonus, I stated the unaddressed uncertainties here too.

Allow for change

The design system can be ever-evolving, with each new insight. When a change is accepted it becomes part of the status quo and will be governed accordingly.

The downside of constant change is that it is hard for everyone to follow these changes. So it might be helpful to lock recently changed components away for major changes and introduce a State of the Union to bring everyone on board again, keeping “the best is yet to come” to yourself.

What you can do today

Start working on a new status quo today by getting your design system components through the Consolidation Process. Acknowledge you are on a running train that can’t be halted – not all components can be reviewed immediately – exclude governing components until they have been reviewed. Take it easy on yourself…

“Perfectionism makes essential projects hard to start, self-doubt makes them hard to finish, and trying to do too much, too fast, makes it hard to sustain momentum.”

- Greg McKeown

author of Effortless: Make It Easier to Do What Matters Most