8 Lessons I learnt while building a Design System from scratch at Syfe.
Stairway to an impacful system.
Start Here
Hi there! My name is Aakash Suri. Pleased to see you here!
I work as a Product Designer at Syfe, a wealth management platform based out of Singapore. My first task as a PD was to start building our Design system. I had read all about it but never got the chance to get my hands dirty. With a sense of adventure I took the challenge to derive a new system out of our old system.
There’s a small gift at the end. Hope you enjoy!
1. Design system is navigation not destination.
The Design system help us (designers and engineers) construct and de construct components (buttons, colors, forms, icons etc) at a rapid pace with a lot of scalability and iteration . I learnt that design systems are made to evolve. They are not your artwork nor your personal illustration. They cater to a larger vision which is spread across many mental models, scattered teams and relevant business needs. They must evolve. Design systems give meaning to the work behind digital products. They add a new dimension of contribution and help a team work like a single organism.
2. A system is more than a UI library and components.
It’s called system for a reason. UI library is just one milestone. I understand it feels great when you have to choose between tons of beautiful Pantone shades and innumerable typefaces but there’s more to DS than just a library. Most of the teams stop at library. According to Invision’s report only 4.4% of the companies are able to harness the real power of the design system which is beyond libraries. Read the full report here. The real journey of collaboration which is the sole purpose of a Design system starts after the library. With a library you have just scratched the surface. Don’t forget to embark on this unknown journey beyond the UI library. It’s going to be messy but worth it if you’re going to put in your time and effort.
3. Designs systems must be flexible. Products define the system not vice versa.
Don’t get attached to your system because it took a lot of effort and research to pull in those components and overnight you have to change or update the whole architecture. Consider bringing in stakeholders, developers (especially developers) so you can establish common grounds. No one should reach this stage of re-doing the whole thing but even if you do don’t be afraid and conquer the fear. Update the system as per product’s needs not vice versa.
4. Just because you created it doesn’t mean you own it.
Like I said it’s a breathing organism it has to be parented not only by you but other team members as well. You should aim to make a structure so flexible that people can add or adjust the DS in your absence. Consider it as your legacy, it should carry on even when you’re gone. Not dead just gone. (All hail AFK’s)
5. Remember KISS? (keeping it simple stupid)
This is a general advice but worth mentioning. It is easy to get overwhelmed. You see a galaxy of components and colors. It’s a creative swayamvar out there. Who to choose and which ones to reject. The hack here is to start small and easy. You can always built for complicated cases. Don’t forget to talk to your dev and brand team early on. There input will come handy when you’re choosing the components/colors you need to built the foundation.
6. Document your journey. Just do it!
Building a DS is all about understanding requirements and making choices. Documenting your journey becomes a lethal communication proof. It shows why, what and how of the process and who all are involved. Anyone can pull up a mock these days and make it look like a system but they can’t replicate your exact use cases. Your product story is unique. So take your own time. Note down all the shortcomings, challenges and how you reached to a solution. For Designer and Developers, this also helps you present your DS as a nice case study. (which I’m hoping would be my next article)
7. Find a way to measure that success. Worth it!
To measure the success of any product is vital. That’s how you know and show that your efforts have paid off. Remember a Design System is product serving other products. With documentation you also need to keep few metrics in track to see the DS magic happen. Companies generally divide that into 3 categories Adoption, Usage and Collaboration. Use regular meetings, scorecards or surveys to understand your progress.
Adoption: This is all about if designers and developers are actually using the design system to build.
Keep these in consideration when talking to the team:
How many teams/people are actually using It?
Does it improve their workflow/productivity?
Can we gather the data on the time and effort saved?
Usage: How and what parts are they using.
Keep these in consideration when talking to the team:
1. How many components or what part of libraries do they use the most?
2 .Do they see the need to customize them on a regular basis?
Collaboration: If your team mates are willing to add/subtract and iterate on the system.
Keep these in consideration when talking to the team:
1. If they were to add what would they add to DS?
2. Do they refer to the library or do they still linger on their slack channels to find that right color?
3. If they had to remove anything from DS what it would be and why?
Last but not the least build a safe feedback loop for anyone and everyone to send in their requests and help you scale this beast to magnificence.
8. Speak the same language. (The language of code)
Without a successful chemistry between designers and developers this ride is going to be rough. Make sure you bring in the developer from early on and understand how they see and refer to an element. For a designer (in this case me) it was a “setup call card” but for them it was a variant of a component with different properties.
This is a real time example of how developers see things for the same things which I used to call a video card or text card.
bottomText: type: component, if passed a the component is put on bottom with a background color based on theme, with margin top 24px. if passed, bottom padding on card is zero else, 24px,
imgSrc: type: component, if passed the component is attached on the bottom right side of the card,
Yes, it might look confusing, jarring and sometimes baloney but as every relationship needs time and effort this one is going to need it too. You better choose the mature empathic side.
Finally you made it! Here’s you gift
A collection of all the links I have been going through to understand more about Design Systems. Yes, you’re welcome. Bookmark them all!
Big thanks (font size 500 and font weight superduper bold) to my team mate, Dinika and my manager, Lakshyya for proof reading this.
For you, you kick some ass designer, Keep in touch. There is so much to share.
www.aakashsuri.com
( feel free to hit me up for meditation, art and design related stuff)
