Do you want a Design System at ACME inc?
If yes, that’s how I would make it happen
In general, a Design System could be loosely defined as a system built to serve teams, to develop and ship features more efficiently to form a more cohesive customer journey across all the applications.Ecosystem quality through consistency.
Product development is our core business. In our world, our software is in a perpetual state of evolution.
Features are added constantly, while our backlog keeps being fed with corrections and updates. The resources are not infinite, engineers and product designers are constantly busy following the roadmaps.
How do we think we will be able to build even another product such as a Design System when we are already almost buried with features to build? We don’t have enough resources or time. We have many features waiting to be built. We cannot stop the Machine to build and implement a Design System now.
Cohesiveness IS a feature
The ultimate goal of our Product Design department is to achieve a Unified User Experience across all our Products. It is important for our business. It’s what the market wants, it’s what customers want, it’s what every employee of the company wants. Guaranteed.
Design Systems has essentially that purpose, to offer a consistent user experience across products. It does it by consolidating a visual language amongst other responsibilities. Maybe your company has already a visual language built by the Design teams although the lack of a system that connects it with developers lead to problems during the development. Also distributed teams and remote offices could interfere by adding some more obstacles to the process. Design Systems promise cohesiveness as the main outcome.
Designers will be definitely happier and more engaged. Designers hate inconsistencies.
We will deliver features quicker
A Design System produces a UI component library and UX patterns. It’s the result of the communication between Designers and Developers through the system’s shared language.
Product Design and Engineering could benefit enormously from this outcome. Product teams will speed up gradually to a new level by ceding small solutions to a shared effort.
PMs will definitely like this.
We will produce better code
Engineers will worry less about the concerns related to the UI aspect of the products and concentrate more on the business logic. And Engineers in general hate that part of the job anyway.
Less time spent on fixing a layout also has the potential of making the process of visual QA much smoother and lean: having an autonomously tested and controlled UI library guarantees automatically the integrity of the UI.
The Component library also helps our software to be more modular and scalable.
Developers would love this.
Will produce less documentation
Shared languages, shared practices, they all help in making the documentation needed for each feature lean and smart.
Who likes to read documentation anyway?
Everyone will participate
Here’s a great thing about Design Systems, they are great for collaboration. Everyone is called to participate. From departments to teams, to individuals.
Every engineer and every designer will be naturally exposed to the UI library in their daily job so the familiarity with it could encourage knowledge sharing and engagement. This is good in our world, given the high turnover and basically never enough time to do onboarding.
It will increase our reputation as a Company
We will hear about Design Systems more and more in the future, as companies are improving a lot towards the goal of having user-centered products and lean processes in the development.
This will help to attract talented professionals that are naturally inclined to stay updated with the latest cutting edge technologies.
We could also attract them by sharing the experience of building a Design System through articles and presentations.
It sounds interesting, now estimate
A Design System is a living, funded product with a roadmap & backlog, serving a larger ecosystem in order to achieve a Unified User Experience. Nathan Curtis, EightShapes
We need a multidisciplinary committed team
A product needs a team. All members are committed at half-time capacity or less, otherwise remaining committed to the other products. The members of the team can rotate/mutate on a per need basis.
Teams won’t work alone. Their job is to involve teams working on products when needed. Think of the system’s team as both builders and researchers.
We need a roadmap
A roadmap reveals a System’s direction.
It enables a design system team to convey:
- commitment to delivering value, justifying their well-defined funding
- transparent priorities, especially critical when serving products and platforms with divergent interests
- reliable cadence that customers depend on
Roadmaps highlight the most important elements of each release, charting the system’s direction without drowning in detail. Organizing that simple story into a a milestone based, columnar roadmap format works wonders.
One of the first assignments of the Design System team will be the definition of a rough, open to modification/extension, prioritized list of tasks.
A responsibility of the team during the execution of this important task will be engaging with the other teams and individuals that contribute to the development of our products.
We need a workflow to design and build components
The System’s team will make most features — visual style, UI components, documentation tooling, UX patterns, and more — by following simple, identified steps of discover, design, build, documentation, and publish
A defined workflow helps a team mutually understand the scope, reviewers, tools, and the definition of done at each step. With a workflow, collaboration tightens, delivery quickens, and the team predictably delivers features.
A QA checklist is also essential. Visual quality, functionality, compatibility are parts of the checklist.
We need a release strategy
It could be quarters, it could be sprints.
The system team will deliver an initial library that can be adopted by a predictable time. Work initially to launch a 1.0 that delivers a strong visual foundation and 12 to 16 UI components.
Those components will be the tools that designers will use to build the experiences. Developers will do the same having those parts ready to be implemented in their codebases.
After 1.0, we need an adoption strategy
The modular nature of the system let the teams adopt it in bits, gradually. We can identify which product could be our beta tester, for example. Or start implement the system incrementally on every product.
We need to wait 1.0 to start adopting the system?
With fast release cycles or continuous integration, it just sounds right to use the time spent on features to gradually build the library, basically while we go.
I see a problem with this approach. Unlike a feature-based release, I think that a Design System has the duty to be a language with an already established grammar and vocabulary even in the early adoption phases. Letters (components) must combine in infinite meaningful ways (interfaces) so then we can build meaningful sentences (products) with them. The language (system) is created and ready to be used.
Conclusion
Having/maintaining a Design Systems is proving a good choice in more and more companies. I think a Design System would be an important and invaluable product in your company. It won’t produce features by itself but it will serve the other products. It will have a cost at the beginning and no tangible returns, yes, in theory. Practically I see benefits from day one: Design and Engineering in the same room producing the product that will allow them to speak one common language.
I didn't write this very recently.
This article was in my drafts section since 2017. Do you think it's still relevant? Let me know!
Thank you for reading
Do you have positive experiences to share?
Hello, my name is Albino Tonnina, I’m a Software Engineer who works in London, you can find me on Twitter or Github or Instagram or around the city.
