

1
DESIGN OPS • 2020
Harmony — Design System
Scope
Document the app
Define tokens
Build components
Deploy the library
Role
Research
Documentation
Build
Maintenance
Timeline
2 months
Platform
Mobile
Overview
A design system is often the first step towards standardising design. At Wynk, with a growing team and increased projects in the pipeline, we wanted to bring consistency to the designs we ship. We are seriously considering taking some time out and deploying a design system. A design system would also help us to iterate quicker across the app and bring in changes. As the app matures, a design system would also allow us to document the evolution of the app. These things reflect the maturity of the design team too.
Allows the team to ship consistent designs and keep pace with the rapid product requirements.
Design with speed and at scale
Design systems and documentation reflect the maturity of the team. This would be a step in that direction.
Indicator of team maturity
2
Doing the groundwork
As someone setting out to make their maiden design system, I needed a basic guidelines for going about the whole thing. I referred to Brad Frost’s Atomic Design System, arguably the Bible for design systems for this. The first months was spent just wrapping my head around how to tackle the challenge. I took baby steps to breakdown the whole problem to ‘atomic’ levels (wink, wink).
Documenting the present
The first step involved just seeing the breadth of things the system had to cover. We had to gauge all the screens to get an understanding of how much effort the project will take.

Wynk was designed with a free rein without any strict quality assurance. Things were inconsistent across the app. Different colours, icon sets, typefaces, spacing, etc. were different like the seasons of a year.

We then decided the things to be built. We set a thumb-rule that anything that repeats thrice goes into the design system. Additionally, we also decided to build the system for both iOS and Android, and dark and light themes. Daunting at first go but we did eventually got it done.

Defining the atoms (or tokens) was the next task. We looked at the foundational type, colour and spacing in the app. This was then labelled by an appropriate naming system that was scalable. Once made, this was deployed on Figma. We now had the foundation to build the rest of the stuff.

Everything was compared with a ‘Design Checklist’ made by Nathan Curtis. This was a good reference to see what the various components are and their respective terminologies.

Another aspect we took care of was making sure our primary colours meet the WCAG accessibility standards. This meant tweaking the colours a bit so they could meet the 4.5:1 and 7:1 contrast ratio across the app.

Out of scope. Out of focus.
Building a design system is a daunting task. Especially if you don’t have enough resources by your side. We had a few limitations while executing this project.

Not coding the system
We did not create a parallel system in code while making our design system. Yes, it would be called half-baked but our main goal was to first have consistency within the design team.

Limited time and resources
The project was never on the organisational roadmap. This was a hygiene activity that we tookup as a design team and a lot of the work was done beyond the work hours. The team was also limited on designer-power to cover all bases.

Re-design the existing work
It’s always tempting to make tweaks to make your components look like whatever is trending. We curbed our enthusiasm to keep everything vanilla and make basic adjustments to standardise the components.
3
Laying the foundation
Ideas are not worth two cents they say. After the elaborate planning and research phase, it was time to put it all to practice. The design system was called Harmony. Its musical reference feels right for a music app. It captures the aspiration we have with the design system, it’s supposed to keep every pixel in sync, every screen in sync, every designer in sync and every team in sync. Everything in ‘harmony’. It was now time to build the system. *cue the music*
Principles for the system
Building a design system is a daunting task. Especially if you don’t have enough resources by your side. We had a few limitations while executing this project.

Consistency
Every component needed to share the same ancestors (read tokens). A common thread running across the components. We merged components and removed any deviants from thee system. This would ultimately reflect in the screen we produce from out design shop.

Speed
Deploying new project quickly was important. Wynk Music had ambitious plans in its roadmap and we had to keep pace. With a larger ambition of having a Sprint system in place, we could be making components from scratch each time and waste hours.

80% agnostic. 20% native.
We’d love to spend hours crafting and fine tuning our screens. Make sure every components follows our design language to the tee. That just isn’t practical. We decided to keep OS level components native to iOS and Android. This also keep a sense of familiarity for users. No one wants to a new share sheet every time they use a new app (reminds you of Jakob’s Law maybe?).
A world of token and atoms

Colour
Select a colour palette with the brand colours, neutrals, and gradients. The colour palette was not holistic and there was some filling in the blanks needed. Then there was also the task of expanding the colour palette for dark mode.

Type
We kept the font selection native. This simplifies the aspect around font scaling on the device. Certain Android phones also allow custom fonts. Keeping thee fonts native would also mean we do not mess around with the user’s settings. Wynk also did not have a strong brand language that we could link with the typeface. So, we felt this is something we don’t need to define. We kept our inputs till the type scaling and usage.

Icons
Icons on Wynk were inconsistent with each other in their weight and kind. We had to design over 100 icons from scratch for the app. All icons were custom made on a 32px grid for convenient scaling to 2x and 3x resolutions. Each is made with a 2pt stroke and consistent radii and margins. This small reform made the app look much better.


Elevation, Spacing and Grids
We referred to Material Designs guidelines for the elevation. Our app had minimal use of elevation. We kept this sweet and simple.
Spacing was done using a 4pt grid system. Using a 4pt grid system kept things uniform and even. Any deviation here would also allow a developer to judge the right spacing.
The grid was set up to define the safe zones on a screen. Apple’s HIG has guidelines around these. We referred to those and extended it to Android too.

4
Impact
After the initial hesitation of shifting to Figma, everyone was eventually delighted to have made the shift. Teams across the organisation were using Figma daily for collaborating on new projects. The stakeholders never felt more involved in the design process. Remote work became a lot easier and teams were thankful that we made the shift early on.
800+
Weekly use of the library
across the organisation
100+
Design systems were created across the org
80%
Coverage of all the components
52%
The design system helped save time for all the designer
5
Final words
The project helped us get a macro view of Wynk Music and the building blocks of it. The system laid the foundation for us to bring iterative change to Wynk faster. The documentation of the system also allows us gauge the breadth of work that we’ll need to put in while making changes to the system. While we never had the organisation go ahead for the project, the speed and consistency that it promises, we plan to go all the way and code our design system soon. This was a milestone for the team. One that shows an improved maturity and the goal to deliver quality. There are, however, still things to be done.

Code the system
Inform our listeners about the introduction of podcast as something new on the platform. We also guide them to the right section where they can find the new content.

Web design system
We tell our listeners what they can find here. We then try to capture the taste of our listeners and their prefrences so we can present only the relevant content to help with discovery.

Figma updates
Once the listener is active, we give them features to improve their listening experience, history, playback controls, etc.
Learnings from the project
Never having worked in such a large team, I did not know about the challenges that arise. Few months into the job, and I could see faults in the ways of working. What was a casual discussion with my manager about how we function turned into my first ever design ops project.

Systems thinking
Figma was a blessing here. We tested multiple flows and screen variations to get as much feedback as possible. This helped our design decisions immensely.

Working at scale
Different content forms need different interaction patterns. Seeing how we could mould our exisiting designs to meet our new needs.

Operational work
The project forced me to work with all the red tape in an organisation as large as Airtel. From reaching out to Figma to seeing the final invoice for it, I got to participate in it all.