Our experiments with design systems

‘Guidelines’ for building ‘Guidelines’ for smaller teams 😅

Design systems have been hot topic of discussion amongst designers lately. No wonder, design systems are helpful. If you need little more convincing, read this article by Intercom’s Emmet Connolly. IMO, design systems will play a role similar to what coding frameworks did for developer’s community.

What shade of blue is our primary?

At some point in time, all companies require to build a common language across teams, to scale efficiently. In digital product industry, this language is nothing but the shared design system.

But, we are not here to discuss usefulness of design system. Rather, I am going to talk about our experiences in building one.

Aasaanjobs has a small design team. Hence, our learnings from this journey will be more relevant to early stage startups — less number of designers but rapidly changing product. Others, I hope you don’t find it that hopeless 😅.

So, the story begins…

As every design system story starts, we also got confronted with our ‘Fifty shades of Greys’! 😅 There were too many inconsistencies across the product, one badly maintained UI kit, designers working in isolation and much more. So, fascinated by blogs & articles, we said — ‘Let’s build a design system!’ — that ought to work, right?

Well…

First attempt

Building the system out of production-live web application:

Design system scraped out of existing web product

As you can guess, with very less amount of research, I started building a design system for our web app. It was just like a side project. As product was live, features were shipping faster than ever. We, as a team, did spent a lot of time auditing the website, but when it came to correcting those mistakes we failed.

As the coding framework was not based on any component based architecture, developers were less excited about pushing audited changes into code. We did make small changes in few modals and input fields, but the overall effect was not convincing.

So all that pretty looking sketch file went in vain — as I failed to keep others (even the design team) on-boarded. 😢 Hence, proved — Design systems can not be built in silos!

Second Attempt

Designing system for a new product from scratch:

Three to four months down the line, Aasaanjobs introduced a new staffing product. New opportunity for me to experiment with design system once again!

This time the team was pretty small — just 1 designer (me) and 1 developer (our CTO). Due to such a small setup and interest in component based system from both the parties, the experiment went successful!

I even made a Dribbble shot for this system!

It’s a very small library though. Not many components, not many constraints and hence, easy to work with.

The Ultimate Attempt

Building the ‘Mobile Design System’ for Aasaanjobs:

Due to success of reactive native in staffing app, we decided to move our frontline products into react native. This was a huge move! So we all geared up for this big task. This time, equipped with all the experience we gathered from previous attempts.

I started discussing about guidelines and components way before the actual designing started. Both design and development teams were now aware of importance of consistency. Hence, even during the development process, there were constant iterations to ensure re-usage of components. This, in a way, helped user to see familiar interfaces across the product. Made the product lighter and faster.

We were yet to achieve a balance between consistency and flexibility. Few more workflow issues arrived as we updated and distributed the library amongst ourselves & with developers.

Sketch library for Mobile Design System

But nonetheless, it was a successful attempt! 🎊 And hence, it gave me confidence to share a few Do’s and Don’ts with community. I hope, it helps 🙂

So, before you jump into systemising things,

here are few checkboxes to tick:

1. Know your designers!

Do some user research! 😏 Pretty redundant advice for designers; isn’t it?

Some cool designer making things pretty (source)

50% users of design system are none other than you and your design team. Even if we made pretty looking UI library; if it’s not solving your problems — consistency, speed of designing — then, it’s a waste of time.

Everyone has different working style. Your design system should not increase the ‘sketch-time’ of your team. Rather it should enable them to spend some more time away from pixels doing research & testing. Hence, talk to your fellow designers about the system. What will make the design system more usable? more efficient?

Once everything is set, before rolling out, make sure you inform/train your designers about ‘How to use the design system?’. Create an example project to collaboratively test it. Keep collecting the feedback. Keep updating your teammates about changes, best practices, etc.

2. Provide flexibility

Faster shipping is a characteristic of an early stage startup. In smaller teams, designers often end up building features in isolation. Maintaining limited set of components in such scenario becomes a challenge. Every designer has his/her own version for these components. And consistency gets kicked in the butt.

To avoid this, do not focus on symbols/components.

Having a flexible UI design system is very important here. Rather than building too many complex components, build a solid underlying guideline — Colours, text styles, input fields, UX principles, etc.

Plenty but well-organised text styles for designers to choose from

This will enable your designers to make complex components (customised modals, cards) on their own and change them whenever they want.

There will be few components, which will remain unchanged across interfaces — input fields, buttons, icons, etc. So, be smart about which components to keep in sketch library and which we should not.

3. Get developers onboard

The word ‘collaboration’ is very important here. To ensure successful implementation of design system, you need to look deeper into your code base. Talk to your developers. What framework are they using? How much flexibility in terms of components such framework provides? Understand their stylesheets, their component hierarchy.

This will help you to set up a common language across design and development. Document those components/symbols at one place. Use tools like Zeplin for smarter hand-offs.

And of course, keep gathering feedback from developers as teams move forward with design system.

Tools like Zeplin have embraced components for better hand-offs

4. Need For Speed

As we are always short on time, do not spend too many hours building the design system in sketch. You might even face backlash from team for keeping important features on hold.

Always try to improve your ‘sketch workflow’. Get smarter with tools and plugins. There are thousands of tutorials available on internet to help you build design system faster. Use them.

Automate Sketch

Sketch Runner

lucaorio/sketch-styles-generator

Also, do not indulge into getting things perfect. Eventually, your design system will become more robust, more perfect. So, no need to worry.

Just make sure that things don’t fall off the place. Plan a good strategy to distribute, update or collect feedback on the design system. Use versioning tools to keep track of things (e.g. Abstract, Plant ). Keep the ‘design system conversation’ alive across teams. Build the habit of thinking in terms of components (But, not at the cost of user experience.)

5. Tips & Tricks

These are few miscellaneous points, but really important ones.

Well, at this point, I realised that, this blog could have been — ‘5 things to keep in mind while building successful design system’ 😐 😫 Anyways, chuck it! 🤷‍

1. Make sure your symbols have logical nomenclature, hierarchy and hence better discoverability. If finding symbols in your library is taking time, then you’ll end up having too many detachments from library.
2. Always remember that user is more important than system. So, don’t be afraid to break your system. Consistency will come back, but users won’t 😐!
3. Move ahead gradually. Design systems are still evolving across the industry. So, no one really knows about how to get them right. They will come of age over time. Just remember your initial problem statements — consistency, speed, more user interaction, testing, etc. Try to solve them & you’ll end up with ‘your perfect’ design system.

Time to rise up again!

So, after our ‘semi-successful’ 3rd attempt at design system, everyone on the team has started believing in importance of having such system in place. (yay! 🎊)

So, we are moving ahead with (🥁drumroll…..) ‘Mobile Design System 2.0’! This system is built upon existing one, but is more elaborative, properly documented and more flexible. It has given us confidence to try this technique across other products of ours as well.

Here are few snippets of ‘Mobile Design System 2.0’

Of course this is not ‘Our perfect’ design system. It barely covers our mobile platform. But, as I said, we’ll keep trying!

Failure is simply the opportunity to begin again, this time more intelligently — Henry Ford

Thank you for reading this article! Let us know about your experiences with building such design system. Do comment of suggestions and improvements. And do clap for more! 👏