Recently, I was part of a 3-person team of consultants who in 12 weeks built the foundations of a new design system. That design system is now used in multiple products and is contributed to by other developers and designers.

In this post you’ll find some of the techniques we used to make the project a success within its short timespan. (While we did deliver code on the project, this article is written from my perspective as a designer.)

1. Invest in Relationships

When building a design system, it’s crucial to first secure buy-in from your stakeholders, from product managers, product managers’ managers, developers and designers.

Ultimately, a design system can only be successful if everyone is on board. One way to do this is to meet with key figures one-on-one to discuss with them their hopes and fears for the design system. That helps with building trust and identifying potential roadblocks early on. The groundwork should be laid for relationships where you feel comfortable seeking feedback from any person as often and as many times as needed, no matter how high up they are.

In order to make any project work – and make it work fast – it’s imperative that neither side see these repeated interactions as nuisances. That’s easier said than done: outside consultants, in particular, have to make an impression and make it fast.

Be proactive in setting up meetings and slot yourselves in whatever available time you can find on a person’s calendar.

2. Get Clear on Your Design Principles

Once all stakeholders are involved, it’s crucial to set a clear vision for the project along with a design vision.

Getting aligned on project goals is best achieved with a kickoff meeting. Getting on the same page regarding the design vision is most often achieved by defining the design principles.

It’s best to avoid using generic adjectives such as ‘simple’ and ‘beautiful’ when formulating design principles — all design systems should be this by default! Instead, focus on the goals and needs of the target audience of the products, that the design system serves.

One practical way to zero in on your design principles is to bring all stakeholders together in a short workshop. First, share examples of specific, working design principles that help everyone not familiar with the concept to understand what a good set of design principles should look like. Next, ask that everyone write down design principles they believe apply to their product (not just the design system, but the product(s) that the design system will be applied to). Then, have everyone share their thoughts with the group. Go through rounds of affinity mapping to reach a final set of principles. Don’t panic if the key terms aren’t beautifully worded at the end of the workshop.

When we used this approach, the group work resulted in a set of specific and actionable principles, all ones that then needed to be reworded multiple times until they became clear and succinct. Agreeing on your design principles helps make sure everyone is heading full steam in the right direction.

3. Keep the Team Focused and Nimble

Dedicating yourself entirely to the project at hand will lead to faster results — in any project.

A benefit of working on a design system as a consultancy is that it is easier to have that type of focus. Often, when a design system is built in-house, the designers and developers involved juggle that project alongside other responsibilities. The multitasking approach makes it challenging to get to a first usable version of a design system within a short timeframe.

With a design system, there is plenty of high-level conceptual work to be done, including defining the design principles, but also an array of nitty-gritty, low-concept tasks, such as naming components and building a symbol library. It is often beneficial therefore to initially have at least two designers on the team, meaning that design tasks can be allocated according to the type of work they require. A repeated context switch between high and low concept work can otherwise wear the team out, significantly slowing down progress.

For developers, by contrast, operating in the beginning as a single unit can be beneficial: it means a certain nimbleness and speed in implementing decisions. That said, it is necessary to acknowledge that there is more design work to be done in the beginning stages of a design system and an increasing amount of developer work towards the project end. That’s why — midway through our project — we mixed up the team by replacing one of the designers with another developer. That kind of agile, focused approach allows the team to maintain maximum speed throughout the project.

4. Build Robust Foundations That Allow For Quick Changes at Scale

This is where the work of a designer gets tricky but rewarding: it’s critical to find the right balance between a near-perfectionism on the one hand, and a willingness to discard things that don’t work on the other.

The foundations must become robust. A common way of doing that is to make heavy use of reusable symbols and styles from the start and then use those symbols as a base structure for the rest of the system.

Especially on short projects, it’s imperative to be able to execute repeated large-scale changes with rapid speed and limited effort. We did this by making heavy use of text styles and layer styles inside all symbols in Sketch, so that if we needed to adjust a color somewhere, we didn’t need to then change it in countless other places too.

5. Keep it Standard

No one reads the manual, even if there is one. That’s why it’s advantageous not to reinvent the wheel on the design side and keep things as standard as possible.

Often, design systems are built for other designers and developers without them being there yet to use the system. That is especially true for consultants. For that reason, it is wise to not rely on any third-party plugins or any detailed instructions.

Design systems should be easy to adopt by future designers and developers. In our project, we used only built-in Sketch functionality, which means the system works for whoever later uses it, whether they like to use plugins or not.

6. Make it Tangible For the Client From the Start

What all of these lessons ultimately hint at, is that it’s vital to create a minimum viable product and to test it often to see if it creates real value. (And then, if it doesn’t, to have the courage to kill it!)

In general, it’s not advisable to build a design system in isolation; the system needs to be plugged into the broader network of people and systems it will be influencing. It’s good to keep in mind that describing a product is one thing and showing a prototype of it is another; real, useful user feedback often requires that one additional step.

For one product, we created fake redesigns of what the new versions of our stakeholders’ systems could potentially look like. Showing people a single button does not elicit much in the way of a response. But when that same button is presented as part of a revamped, existing system the stakeholders can recognize, they suddenly have a wealth of opinions on that design language as a whole. It makes the potential change real, and that’s what all designers should be able to do. Granted, it’s harder with a design system — but equally as important as with any other product.

Because the worst type of time lag is not falling a few weeks behind on a schedule, it’s building a system that nobody wants.

7. Get Users to Implement it

Feedback on how components look is one thing, input on whether that component is usable for a designer or developer is something entirely different. A design system is only successful if designers and developers actually want to use it, so you have to make sure that it saves them time and makes their lives easier. Otherwise, they will (rightfully!) keep creating their own components from scratch and the investment in the design system will have been wasted.

In the final month of our 12-week project, we stopped adding new components and instead focused on refining the system that we had built. We were lucky to be able to work with a developer outside our team who could use our design system’s components on a product. Inevitably, he discovered gaps, bugs, and things that could be better explained.

It’s a great feeling to uncover problems through testing; correcting them means the system will have an even greater chance of success in the organization, years down the line.

8. Study the Greats

Learning from someone else’s successes and mistakes is always useful. When there’s limited time, learning from other people’s experiences becomes invaluable. You have less time to make – and learn from – your own mistakes.

Readings that were valuable to us were Anna Kholmatova’s Design Systems book, Audrey Hacq’s “Everything you need to know about design systems” Medium post, and Dan Mall’s blog (particularly the excellent blog posts on design principles and type systems).

Studying existing design systems is a great way to learn from others and speed up decision-making. When you get started and don’t yet have any components, it can be hard to imagine what the effect of documentation layout and design file organization will be later on. Taking a look at how certain choices pan out in mature design systems can help lot when making those types of choices at the very beginning.

We learned a lot from dissecting IBM’s Carbon and Shopify’s Polaris, two very different design systems, as well as UX Power Tools’ methods for speeding up workflows.

 

Featured image via Unsplash.

Source

p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}