Industry Experience: Few reflections from designing a Design Language System.

👩🏻‍💻 Sharing 2 cents of wisdom, gained by working on the Dunzo design system for almost a year now…

Photo by Jason Goodman on Unsplash

Disclaimer: This article lines up some key learnings one should be aware of while or before stepping onto such a project. I’ll cover the specifics of the creation and migration of the Dunzo Design Language System 2.0 some other time… until then, let’s continue.

Worth the hype?

1. I agree, not begrudgingly agreeing but really agreeing. They’re really powerful. Having a structure helps different teams connect and be on the same page.
2. And yes, it’s okay to spend a lot of time here, as with all the structure and groundwork it’ll pay off in the long run for sure
3. Decide first — if you even need a design system. This article articulates the very basic why and why not around the same. Read & decide🔥

Treat it like a side project you’ll probably fail!

[embed]

“A design system is not a project but a product of its own which services for projects and people” — by Nathan Curtis

Yes, indeed, you can’t just pull off something as huge as this alone and so, like any product requires a system with executives and PMs to hold the group and get things going, it's better to get the support early on here as well.

Speaking of managing stuff…

Involving too many folks can slow momentum. while involving too few can make others feel excluded and resistant to cooperate. You can’t be hasty! Not everyone has all the skills in the world,

and you can’t just say…

[embed]

and move on!

So learning how to deal with people as we onboard more designers and devs on the task is crucial — this is where the practice of documenting things along the way, has helped me a lot. I understand that it can be a bit tricky but I’ve also learnt that this is something we gain with experience :)

When designing things

1. When creating a structure it is better to create a definition for all the specifics like fundamentals, principles, guidelines, assets, and more component libraries, pattern libraries, and more. Knowing where to draw a line between these sections would help in dividing the work between designers and devs.
2. While designing these fundamentals and components can be limited to designers, things like — inclusive design, documentation, and general guidelines are areas that require the entire product team to collaborate on.
3. Nomenclature — assemble your stakeholders team(at Dunzo, devs and designers was it) and develop a common language for all elements in your design system so everyone refers to things in the same way. It can be quite challenging but it’s crucial for communication.

Don’t stop documenting things!

It’s better to create comprehensive documentation while creating your design language system, this will not only help in the ongoing creation, collaboration, and adoption of the system but also pay off in the long run.

[embed]

1. This documentation can include things like — the design principles, how the fundamentals work for all stakeholders, and design guidelines for components or patterns as soon as ideas strike your mind! Always better to jot down fresh thoughts.
2. Other good to-dos include — major design decisions, component/ fundamental design updates, and migration updates (tracking dev front) i.e., updating the change log now and then.

Excellent collaboration! How?

To collaborate better with the devs — once you have pitched the idea, catch the devs who seem most excited about the same. It would be nice to have one from both from all OS and platforms.

Now, befriend them just like the skeleton from he-man!

[embed]

1. Work with them to understand the existing code structure and patterns. Neither you nor the devs want extra work, so try to find a solution for your new requirements and you can re-use existing architecture.
2. There are often several gaps between the different platforms, in our case it was Android and iOS. Work with the devs to bridge the gaps between designs across platforms and implemented products.

Having devs as your companions becomes extra helpful in case you are building a token structure for your new language system, in the sense that it increases the chances of adoption of the system clearly and concisely to developers and designers as well as prevents extra work from now on.

The true success of the system!

If you are considering the job done after the creation and migration of the system, then let me break the news to you. NO.

In reality, this is the part where…

[embed]

1. As soon as your system is created, things will demand change. Again! It could be anything — new tech updates, team members, or even new requirements could chip in. Things are ever-evolving, and nothing you define will remain unbeatable forever.
2. I strongly believe that the team plays a crucial role here. Keeping the system alive requires the entire team to obey the protocols.
3. The least one could do is ensure a feedback loop is in place— weekly or biweekly or whatever the team calls for, but should be recurring. Active channels to keep track of things between the devs and even the product if required.

These small steps assure frequent/regular communication btw stakeholders — making the overall system a success!

Keep an eye out for more episodes on specifics of the creation and migration of Dunzo Design Language System 2.0!

[embed]

I’d love to expand on this🌻 , for any feedback or suggestions, leave a comment or connect on Twitter or Linkedin