7 design system hacks

August 4th, 2020 Written by James Wheatley

It’s been 6 (very enjoyable) months since I joined Infinity Works as an interaction designer, stepping into the fast-moving fray of a recently scaled 60 person tribe. My goal has been to establish a design system for our client. For anyone new to this term a ‘design system’ is essentially a set of reusable components and guidelines that can be used to design and build a variety of products and applications. It’s been a challenging but exciting experience and I wanted to share some of the things that have helped along the way.

1. Explore and experiment for yourself

A good design process is essential and you will want to start by thoroughly immersing yourself in the world of whatever it is you are designing. While this includes previous design work it is essential to take time to explore the subject for yourself visually. I find a series of quick fire experiments attempting to combine brand elements with UI trends is a good entry point. Start with whatever you feel is the main design challenge but give yourself time to follow any idea threads you encounter.

Try to keep moving quickly forwards with this, not lingering on anything too long and simply skipping on if you get stuck. Be prepared for many failures but you will generate a lot of ideas and the process will enable your thinking to move forwards rapidly – also hopefully unlocking some interesting new ideas on the way!

This will get your brain into gear and the ideas flowing, then pull the strongest ideas into loose concepts for some fast feedback from your team and stakeholders. I like to challenge the current approach to get a feel for how far the existing design can be evolved. This may feel like a luxury in terms of time but even a few timeboxed sessions will both accelerate and ground your thinking which will help you stay focussed further into the project.

2. Tackle problems incrementally and be ready to adapt

This experimentation will prepare you to face the design challenge head on, but before diving in plan out your design process to tackle the problem. I like small tasks completed quickly, trying to focus my problem solving skills as intensely as possible. Then stop and think about or do something different (whether its a side project or just grabbing some fresh air), before returning with a fresh perspective to evaluate the results, then rinse and repeat!

Breaking down the problem in this way will allow you to solve it incrementally while also staying nimble and reactive, particularly powerful if you find yourself faced with a monolithic, impenetrable design brief. New insights or requirements can appear at any time, or life can even be turned upside down as with the switch to remote working due to the Covid-19 lockdown.

For me this happened while trying to crunch through to a finished concept, which made an intense period of solo working even more so! It makes you appreciate those incidental conversations you have with people around the workplace whether over the desk or by the coffee machine (at Infinity Works a small crowd can generally be found here, usually trying to work out how to empty/unblock it). We had to make an effort to simulate this while remote working and as our new designer Jack joined the team and onboarded in the lockdown. We made a concerted effort to stay in regular contact, share work regularly and attempted to complete a number of tasks together online to help build a natural rapport.

3. Follow your instincts when something doesn’t feel right

Introducing a design system to a project with multiple squads is a real challenge, there will be a lot of moving parts to keep an eye on, things can get chaotic and there will be a temptation to plough on and hope for the best. 

We did this while development was well underway which isn’t ideal but we agreed a plan to marry the two work streams up further into the project. A tricky point came when we had a working journey and wanted to style it enough to release and get some early feedback. An interim design seemed a sensible way to get it out the door but we had a niggling feeling. After discussing again we realised we had enough new design elements ready to get some basic styling in place, this would put us on the right path and eliminate any wasted effort.

When you have a lot of plates spinning you have to listen to your instincts, if something feels wrong stop and try to understand why, have the team share their thoughts and opinions. You have nothing to lose if proved wrong but if it turns out your instincts were right (which can happen surprisingly often) you will kick yourself for not listening to them.

4. Keep designing when the coding begins 

In previous roles I have always tried to avoid the ‘throw it over the fence’ scenario but still I had always been a step removed from the build process, this inevitably leads to compromises as unanticipated obstacles are solved without design input. As my first fully embedded design role I was determined to work closely with the developers as the UI was pieced together.

So far work had involved intense design with frequent sharing to engage the squads.

However, as the first UI tickets appeared on the Kanban board there was a change of rhythm. Through elaboration sessions we collaboratively explored each interaction in detail, explaining how we imagined them working and identifying gaps we needed to consider allowing us to iron out any potential snags.

By joining the day to day routines of the squad and being part of stand ups, elaborations, pairing and mob sessions you will feel like part of the squad. This can feel alien and intense compared to a purely design focussed role but for me it was a genuine thrill to see the tickets move across the board and the design system begin to emerge.

5. Expect one or two hurdles on the way

While this is an exciting time you will inevitably face some challenges. We’d formed a cross tribe design alliance at an early stage but up to now it had been mainly conversational. When it came to implementation we found variations in technical approach meant we had compatibility issues between what had been built and the technical approach of the new design system.

This was unfortunate but with some pragmatic conversations we were able to build a consensus. Then with a little refactoring we achieved enough consistency for everyone to leverage the benefits of the design system. While you hope to avoid these scenarios things will inevitably crop up, but working together to overcome these obstacles will ultimately strengthen the bond between those who are working to make the design system a reality.

6. Support the design system with a strong alliance

This kind of decentralised approach can be a bit of a balancing act, each squad has their own delivery objectives and roadmap milestones. Everyone wants tickets to flow smoothly across the board, but at the same time you want reusable components with enough flexibility to be adapted to different situations. Plus it takes time to set up theming and get the components organised and visible, this is all vital for the design system but does slow down the first few tickets.

Regular communication between the squads is essential to avoid the risk of duplication, blocking or worst of all breaking something. With regular catch ups, some tactically arranged elaboration and mobbing sessions plus a healthy level of chat on Slack these pitfalls are avoidable. The first few tickets were quite nerve-racking as we tackled initial setup and some teething troubles. Then the reusability factor kicked in and we saw a reassuring, steady flow of tickets.

It is at this point you start to realise that there is more to a design system than components and guidelines, it is actually about people working together to create something of mutual benefit for all.

7. Right tools for the right job

Your tooling will be an essential part of the process, especially if you suddenly have to switch to remote working. Anything that strengthens the connection between design and development is worth exploring.

We design in Sketch using a shared library, then after the office shut we started using Miro during video meetings, before long we were wireframing, elaborating and sharing design concepts on its infinite canvas.  We kept returning to the same boards which built up over time to show the progress and evolution of the features – I can see us continuing to use this when we are back in the office with real whiteboards again.

When the designs approach ‘production ready’ we share them via Zeplin. We tried a few tools but liked how it ‘joined the dots’ between the code repository, workflow tools and design files, plus things like the spacing tokens give it a neat development focus. Zeplin also connects to Storybook. Storybook is a UI component explorer that creates a visible library of everything that is built with all the different states and provides quality assurance via integrated visual testing tools. You can see the implemented design system in its entirety and provide strong visibility which promotes reuse and encourages it to grow and evolve as products are released and new insight gained. 

These tools can be further linked together via plugins and also tied into workflow systems like Jira, creating a tightly integrated set of tools.

Not just a pretty bunch of guidelines…

As I write this the first journey that uses the design system is being prepped for release, two more are in full swing production and another two are currently in design. I’m excited to see how it performs in the wild and what impact it will have on future projects. I have enjoyed my first ‘embedded designer’ role, it has been revolutionary in terms of speed, agility and quality plus it has been a real learning experience. I’m very happy with what has been accomplished and can see opportunities to enhance and finesse our approach. 

The design system starts as an idea, to grow it needs space and freedom to explore and experiment. Let it follow different idea threads, absorbing and transforming as new insights and revelations emerge. Feed, protect and guide it but don’t expect to fully control everything, it will take on a life of its own which needs nurturing. It will encounter new things and adapt to them, gradually building resilience, observe this and be mindful of your instincts. As it matures it will become more intense requiring support and encouragement, attention to detail at this point will pay off in the long run. Stay close but give others the space to develop it, supporting to unblock obstacles where required. New challenges will present themselves, this is inevitable but rising to meet them will build strength and meaning to those whose passion and enthusiasm have made it a reality.

At the start of this post I defined a design system as a set of reusable components and guidelines but what I have realised over the course of this project is that it is more than that. It is an idea, an ethos, something that can bring people together in shared enterprise with a common goal. A central part of its success is the collaboration of those working on it, this is how good user experiences are created, they say it takes a community to raise a child, for me this is also true of creating a design system.

Illustration created using icons from the Noun Project. Specifically “Worry” by Magicon, “Challenge” by Larea, “Wood Planer” by Eucalyp, “Saw” by Atif Arshad, “Hammer” by Jorge Mallo and “Screwdriver” by Hat-Tech.

Written by James Wheatley