Design Systems: Goldmine for High Growth Brands

If you are a design focussed business (or brand), these are your atoms & molecules for scaling up.

Hey You,

It’s the beginning of a new month, new quarter and new opportunities. So well, things start to stir up from here on, in the newsletter too. If you’re someone who likes to write through experience, I’m up for collaborating with you on interesting topics out here 🎯

I’m sure you’ve enjoyed reading these newsletters so far. I’d love for you to send them to the right people in your network. It’s been my endeavour to spread these to the right people. Here’s a link to sign up for MY NEWSLETTER SUBSCRIPTION.

I recently dropped the last episode of Design Grid with Rahul Saini, Head of Product at Paytm. The episode is a breeze given Rahul’s candour & humour throughout. It dives into how they use their internal systems to turn-around new product strategies, overnight. And yes, we do talk about the big one: Paytm & Demonetisation in India. Check it out.

Today’s newsletter is a 7 minute read.

Today we’re diving into a topic that’s a must-know and definitely a must-do for every high-growth brand: start to build your own DESIGN SYSTEM.

I often get this comment, “But Saksham, I’m not a designer. I’m a marketeer. Why do I need to understand Design Systems” Well, this one right here might be your answer👇

So how should you model design systems for a high-growth brand?

I’m sure you’ve stumbled upon this several times, through different approaches: from treating it as a one-off project (while redesigning your website) to having a dedicated design team and lots of things in between.

In the early days of any brand, there’s no design system—you build everything for the first time. And then when you launch the mobile app or choose to build your own e-commerce store (breaking away from Amazon), you definitely need a few standards & shared patterns in place. Or else your customer experience (CX) will start to get increasingly inconsistent.

(It’s best to give names to your design system: every module as well the whole of it. Spotify calls it ‘Encore’, Netflix calls it ‘Hawkins’ and so on). I usually model DS’ for brands around a mix of a few models, but customise them for the brand in discussion.

1. At the center, have a Core Foundation: It’s where you would keep things like color, type styles, motion, spacing, plus guidelines for writing and accessibility. It’s also where your design tokens could live. These are things everyone in and around the product should use—it gives your brand a sense of personalisation.
2. At the center, have a Core Foundation: It’s where you would keep things like color, type styles, motion, spacing, plus guidelines for writing and accessibility. It’s also where your design tokens could live. These are things everyone in and around the product should use—it gives your brand a sense of personalisation.
3. Right alongside, you extend the Website Glossary to the Mobile Base: Similar to the website glossary, this should become a place for common components that are shared across your mobile application(s).
4. And lastly, if you’re a business that has different interfaces or accesses for different stakeholders or types of customers (Eg: Zomato having a separate log-in for restaurant owners or Spotify having an Artists’ log in), extend the your design system to incorporate ‘Personalised Fields’ for these interfaces.

Now once you’ve made the classification for your DS, here are a few check points you must adhere to: Your DS must:

• Provide design assets, code, and documentation.
• Make it scalable across different interfaces and platforms (apps, websites, third-party landing pages, devices and so on)
• Actively maintain (and scale it) with a dedicated team and should be available to all brand & design teams in one place.
• Have a defined interface for engineers to work with (documentation and even granular codes for interactions)

And two things that brands usually neglect are :

1. For a design system to work, it needs to embrace the company’s characteristics and peculiarities

While constructing a DS or even scaling one as you grow, designers and different stakeholders would come with their own set of opinions. Ones that would be nothing more than a fad or an ongoing trend in design. But your DS should be timeless. So build your design ideologies on your company culture. They could be (for instance):

a) Content First (b) Pragmatism (c) Relatable (d) Minimal (e) Authentic (f) Inclusive

Now if anyone’s scaling your DS, let them run the new designs by these core ideologies. What really makes the ideologies work, is if you tailor them to your sector (say sustainability or fitness or fintech) and tie them back to your business goals, in terms that would resonate with non-designers.

Throughout this entire process, you should ideally partner with UX writers to craft the best practices, definitions, and core interactions around your DS. It would help a new designer just starting to learn more about what you offer, to a developer (freelance or in-house) looking to understand how your brand differentiates between layouts and gradients. As a bonus, the process of documenting can help designers further clarify their thinking with regards to the component itself and how it should be used, rather than leave it to interpretation.

And finally here’s what comprises a Design System:

Three layers that a DS must have: style guide, a component library, and a pattern library.

I) Style Guides should contain specific implementation guidelines, visual references and design principles for creating interfaces or other design deliverables. It should dive deeper into branding (palette, typography, illustrations, logos). Further, style guides should also (ideally) offer direction on content (tone of voice and values) and visual- and interaction-design standards (a.k.a. front-end style guides).

II) Component Libraries (also known as design libraries) would be the crux of your DS: they should consist of predetermined, reusable UI elements and serve as the single source of truth for designers and developers alike to learn about and implement specific UI elements. Some examples of what a component library could document would be:

• Component names: to avoid miscommunication between designers and developers
• Descriptions: details on dos & don'ts and how to use specific elements
• Attributes: how variable could your color, size, shape, copy be across different elements
• State: defaults & customisations possible in appearance
• Code snippets: the actual code excerpt for the element
• Front-end & backend frameworks to implement the library (if applicable), to avoid painful and unnecessary debugging

As an extension of your Component Library, it’s wiser to classify the patterns & layouts here. They should typically feature content structures, layouts, and/or templates. Including documentation on their adaptability.

Representation of Spotify's Design System

Well, that’s it for now. Write to me in case you struggle with any aspect or need to talk more about them. I love feedback and even more constructive conversations on growth.

Until next time,

With Gratitude,

Sak