When you start developing a new product, many things have to be considered. You have to be clear about the product vision, which target group to address, how the interface should appear, or how to guide and support the user. Typically, these ideas are forged in product management, discussed and decided on a business level, and finally the development teams are in charge of crafting the product. (Forgive me for oversimplifying this process - I am not a product manager 😉.)
On the product development fast lane
As soon as the first considerations are made and the project is started, it seems as if things are going tremendously fast. Before you know it, the backend reached it’s MVP status, the designers made the font and color decisions, the developers selected the library for building the user interface, and UX has the main concepts in their pocket. And when the first prototype is available, everybody does a happy dance. All are enthusiastic about the new product approach, do research, contribute ideas, and take action.
Wind of product change
Let’s be honest with each other: things change over time. New features are requested and need to be implemented, further teams are involved to top up development resources, or new colleagues join to help grow the product. There might also be partners providing external applications to complete the feature set. With all those different resources we still want to deliver a nice and sound product, right? And clients should have a good time using it. But let’s face it: it may also happen that colleagues who know the product like the back of their hand are absent for a longer time or meanwhile have left the company. Who has the overview then? Who knows the details?
Repeated questions
How do all the colleagues that work on the product know about decisions that have been made? I’ve heard people (including myself) discuss stuff like this:
- Why do we use a toggle switch here instead of a checkbox?
- How should we get the message across in the UI?
- Seriously? Is this the way we want to go from UX perspective?
- Can we expect our users to know this?
- How should I style this button?
- Which font do we use and what’s the fallback?
- Do we have a react component for this?
Design system to the rescue
Discussions about the above topics as well as questions that repeatedly come up could be avoided with a design system.
What does that do exactly?
It helps to create a better product design process.
It aims for consistent UI elements in terms of design, usage, and speech.
It supports all involved parties to work efficiently on the product.
It trains new employees on how and when to use certain UI elements, and documents decisions that have been made along the way.
Scope and structure are up to the company’s needs, but the design system should give of course the answers to questions that repeatedly arise during product development.
A design system might cover:
- Target group
- UX directive
- Elements used in the UI (inventory) and their behavior
- Design guidelines for styling UI inventory (colors, fonts, dimensions, padding…)
- Tone of voice
Let’s do this
It’s clear that a design system is not brought by Santa Claus. It involves a huge amount of work and alignment of resources to establish it. Processes need to be implemented on how to best work together crafting a great product, and all involved parties have to be onboarded. In a follow-up post we’ll give you insights on how we made the first small steps towards a design system.
About the author
