After two years of working on a design system, there are a few things I’ve learned…

‍

Würth Elektronik is one of Europe's biggest manufacturer of electronic & electromechanical components, printed circuit boards and a specialist in the development and production of system solutions in press-fit technology, for example central electrical systems. We design and build our own internal digital tools to meet our daily business needs and to enable smooth function of our daily operations. ‘WE RED’ is a design system created for these internal business tools.

WE RED as a concept was thought by our director Mr. Harsha Adya, which later he explained how he wanted to have consistent and scalable UI across all the web applications in use. Being the only designer in the company it was my responsibility to design, creative direction and documentation.

Now, let me walk you through my reflections as a solo designer working on design system.

1. Working alone on Design systems is hard

Honestly, it takes a bunch to create and maintain a design system. From the surface, a design system might appear as if a bunch of pixels became pretty components. On the inside, there are real people tirelessly working to make dependable, exciting solutions that solve countless amounts of UI and UX problems. Being a solo designer requires relentless effort, time, collaboration, patience, and energy.Constant communication with stakeholders helped me to define a technique that serves the requirements of the business. Most significantly, a decent working relationship with developers and product managers enabled the design system to succeed with excellent outcomes in a healthy, trustworthy, and agile way.

2. Research, research, research

A design system is the sole “source of truth” by system adopters. Designers and developers will use the system to seek out out how something should be used or applied. They come with an expectation that what they're looking for is credible, timely, tested, and reliable. Every component, pattern, and guideline should be told and validated by research before it's made available to the team.

3. Starting with basics

Understanding what a design system is and the way to get started are often somewhat overwhelming for first-time visitors.  To ease their burdens and to form the system more accessible to everyone, make sure to supply the foremost basic guidelines and resources as a primary step.

Provide foundational information like how to start, where to look for important tools, what code packages to use, and who to reach out to when something goes wrong. This will make it easier for adopters to know why the system is that the way it's. It would sound like a clear initiative but leading with this type of data will help to determine a way of trust. This trust goes an extended way when, at a later stage within the journey, adopters are asked to use components during a prescribed and systematic way.

4. Content is King

It’s my responsibility to offer design solutions to common problems. In the context of digital, tons of these problems occur because, unfortunately, content strategy and copywriting is usually an afterthought. When a component or pattern doesn't address content requirements successfully, they lose effectiveness and scalability.

The bottom line is, content are going to be designed whether there's an expert in place to try to to it effectively or not. Providing appropriate guidance on things like content types, tone of voice, recommended character count, and globalisation requirements will help adopters make better decisions when using the system.

5. Service not a product

A design system isn't a finite library of static components. a real design system should provide end-to-end support to system adopters: from getting started guidelines to UI templates to production-ready code to customer service support and everything in between. A system may be a continuous commitment, one that doesn’t end during a single output.

6. Stay with system

A system helps to form sense out of the many complex and disparate ideas. It enables designers and developers to show those ideas into unified, reusable solutions through thoughtful design and clean code. The result? a uniform user experience across multiple brand touchpoints. But this will only be achieved if users of the system adopt and apply it as intended. So how can adopters use a component or pattern for bespoke or niche use cases that aren't accounted for within the system?

A designer/ design team should hold off on building new solutions at every turn unless research and  feedback indicate the urgency and need. If the core system doesn't cater to an adopters edge case immediately, encourage contributions or feature requests.

7. Iterate

It may seem counter to my previous point, but a design system must be iterated constantly to grow and alter so as to remain relevant. However, a growing system doesn't necessarily mean it must get bigger and more complex. it means that it must mature in terms of its quality of documentation or broaden in terms of its outreach and engagement with adopters. And in fact, over time, its components may require design touch-ups or development refactoring.A designer/ design team must be prepared to take care of, update, and finesse all aspects of the design system if it's to face the test of your time.

8. Documenting

Documenting every design decision, file change, or code update is probably not a realistic goal. But making an effort to do it as often as possible will save a design system team oodles of time and headaches in the long run. Providing a change log keeps both the team and adopters informed of updates. Documenting research questions and findings in a report helps answer stakeholder queries and address adopter concerns. Writing draft guidelines for a component or pattern as the design is nearing final approval — and when the details are fresh in the mind of the creator — is far easier than waiting until it reaches production.The point is, failing to document as you go will result in a backlog that will last an eternity.

‍