Design systems learnings

Reasons for writings this

Design systems have been around for some years now. They’re getting more complex and businesses are realizing their critical role in the business context. I’ve been involved is design systems in a way or another for about 5 years now, and there hasn’t been two years identical between each other. The tools and processes evolve in a baffling speed, but here’s my learnings from along the way.

Read the full story below

Design systems is an inside job

Design systems should be an inside job – at least for some part. It shouldn’t be externalized entirely. To ask for help and find expertise from outside the organization is smart in case there’s not earlier knowledge of that, but it’s crucial to have at least some people committed to DS building and development from the organization.

 Developing DS groundings and ways of working needs commitment from various disciplines from the organization; design team members, development and at least high-level understanding from the management, about how to apply resources and time, spreading the understanding  and commitment to DS. Depending on the design maturity, the DS also might need someone evangelizing it, to truly gain commitment in all parts of the organization.

Be humble – you don’t it all/listen for the beat of the organization drum first.

From consultant point of view, it’s important to keep humble mind in how DS principles should be applied to organization. The last decade in various client organizations has showed that there’s no two identical organization, what comes to design and dev organizations, team models, and how product teams or brand teams work. From that perspective the best is not to appear with a big bang, but to humbly listen and sympathize the culture, people, and ways of working before establishing any groundbreaking ideas how to change the status quo, ways of working or profoundly change designs. Before suggesting new ways, it’s often times beneficial to ask why have things been done in a certain way in the past – it usually cuts half of your suggestions to the trash bin.

In my experience, having had product design work – and thus having had valuable ‘grounding work’ to teams, tools, brand identity and unspoken ways of working – has helped hugely with Design system work. That is also why I personally strongly enforce the idea that design system work should at least for some part be in rotations, so that all or most product team designers have at least current knowledge on DS building – if not constant hands-on work to DS. This way, the product designers also bring the tacit knowledge from their projects, teams and products that would otherwise left unspoken.

Design system is a (complex) constellation of disciplines

Design system is intangible, abstract and spreads across organization to various disciplines and that is probably why it’s also hard to grasp in organization. It’s easy to fall into a thinking that it’s only some UI components that are eventually been applied to user interfaces in digital domains. In DS work there’s often times more work than to first think of, with various stakeholders. DS is a constellation of stakeholders – designers, developers, marketing, and branding, often times even management.

Only from building DS from ground up it becomes obvious how it starts to bring up discussions such as ‘should we still sharpen up an edge of an brand’, ‘are the brand identities comparable and in line with each other?’, ‘What message do we want to enforce in visual cues?’,’Is our brand and it’s communication up to date?’ You might start from taking an UI element to drawing table and end up in days of in-depth discussions with either marketing, branding, management, or employee onboarding.

Simple questions along DS work can lead to big philosophical conversations – they take time but often times create all important alignment across disciplines and many people will thank you later for ask. Many people will thank after asking these questions.  Also – having done the Foundations work profoundly, speeds your work in this without fail.

Build from ground up

Before drawing any UI elements there are solid foundation to be done. By the time you start to build your DS elements you have hopefully worked with foundations: the brand/company philosophy, product story, mission, values, tone of voice. In my experience, DS work is, in my opinion, most fruitful to start just after brand renewal work. That’s usually when the company is most sensitive to aligning to the new brand or identity. I’ve also been in situations where the brand work starts after DS work has started. That’s not the end of things but predicts delays in DS work and probably more work.

During latest projects in DS work, we had customer experience pillars and visual design principles defined. Those valuable pre-defined pillars and principles were re-visited many times – helping in daily decision making between different design solutions.

After having design principles and pillars built, it’s also important to define the baselines for future DS components; grids, breakpoints, colour palettes, font families. In this – like in every other stages in DS work – alignment and co-operation between disciplines is needed. This, in practice, is discussions and time.

Develop understanding before building and respect your end user

During my last cases in DS work, phases of the DS work was to organize workshops with different product teams including designers and developers to gather understanding and probe hidden needs.

 The end users of design systems are designers and developers and it’s hard not emphasize too much, how important it is to discover their needs, fears, frustrations and hopes. To a great extend, Design system process at it’s start is quite like a product design process, where one needs to tap into the flow of hidden needs, frustrations and hopes of the end user – because your end users are your designers and developers. DS designers should treat their work and time with respect. Ease the adaptation by taking you end user’s concerns seriously.

At the end, DS should be a tool to enable fluent, efficient work, not cause more frustrations and hindrances. Poorly executed DS can cause lack of motivation and de-alignment – even decline of work morale at worst.

 Besides stakeholder workshops it’s also important to discover what elements are in active use. In case you have data to back this up- even greater. Map your most used design components and start from those.

Create alignment to common tools – and rules

At the current moment there’s many tools in the field of digital product design. Figma and sketch are the two most used at the moment, but – the shelf life of mainstream design tools and skills seems to get shorter and shorter. Nevertheless, what the tools are, when talking of design systems, the key here is to establish common commitment to preferably just one common tool, so that teams across organization truly can commit to DS. Also other tools in applying DS for development and other stakeholders should be defined. In my experience, Storybook and Zerohight have worked fine.

Second thing to align with is rules and ways of working. The DS is up to date only as long as people commit to the ways of working and rules. What is the process of adding new elements? On who’s responsibility it is to create new DS elements? Who ‘proofreads’ new design? Who watches over the process? How are new elements, i.e. buttons named? Do I need to add variants, autolayouts to my components? When can I detach common designs and make my own designs? When is it justified to create all new components or designs? All of these should be discussed and defined. Accessibility is also important thing to consider – and a topic for a whole new blog post.

De-centralized, centralized, federated or solitary?

Before committing to any SD model, it’s important to discuss what team model fits your organization best. Do we expect everybody to contribute to DS or do we have designated professionals for that? How can we guarantee that information flows to both ways; from product teams to DS teams and vice versa? Can we predict bottle necks in certain DS models in advance? Who are the gate keepers and decision makers in each model? In my opinion, these models should be openly discussed inside design teams to see which model suits the organization best and what are design team capabilities for different team models.

Design system work’s side product is often times alignment between teams and disciplines. Along with the DS work the team or the DS experts gain valuable insights from across disciplines. This is the reason why I would personally not assign only outside experts or single individual in charge of DS, because when and if the organization looses the person, the organization also looses vast amount of hidden multidisciplinary information.

What holds you back?

Strait design processes are rare as rainbows, so you should be prepared to face hindrances. At best you can try to foresee some. Mapping your bottlenecks and obstacles can save time later. Find people you should influence or connect with.

Most companies have legacies from which it is hard to get rid of. Have your goals high but, treat your legacy obstacles with respect – some things happen only in due time. While waiting, be realistic what you can change at once. This applies especially for large digital services with either design or dev dept, probably catering different products and brands under its umbrella.

Lastly but not leastly

Lastly my past learnings along the way is, design systems is a living thing. It needs constant watering and care, and it’s never ‘ready’. Ways of working in DS can hugely impact on how much design dept gathers over time.

Make sure your organization has enough resources for DS maintenance, renewals, communication and evangelization. DS is a tool too, and like any other tools, it’s influence in job satisfaction, and efficiency is undeniable.

My strong though on this, is that at least in larger design team or teams, rotation of professionals between product teams and DS steams is highly recommended. In my dream team I would establish ‘exchange student’ culture, where designer across the company shift into DS team for a week or two, to gain and bring up-to-date knowledge. Product teams give input to DS team, and DS team gives hands-on experience to product teams. This way, either DS nor product knowledge won’t stagnate so fast and cause design dept. Rotating also developers into this team at times, wouldn’t be that bad idea either. Also, establish common rules or DS manual for everyone in DS network. The benefits will come, but within in time.

Finally, when you establish your Design systems, keep record on acceptance, use of components and detachments. For that use Figma Design system analytics is worth checking out. Find out what works and what doesn’t – and iterate. And last – take care of your design system and it will take care of the rest.