Today is a very popular toolkit for companies to unify their user experience of the software ecosystem. Many companies have already started their own journey to develop such a , or on the way to enhance it for adapting to their situation better.

Today design system is a very popular toolkit for companies to unify their user experience of the software ecosystem. Many companies have already started their own journey to develop such a system, or on the way to enhance it for adapting to their situation better.

I am working for a large B2B company and maintaining the design system for 2 years. Here is what I have in the journey.

The Context

I am in the core team of our design system project. The team is composed of three people: One manager, one frontend developer and me, the designer. We kicked off the project with a top design agency for the MVP stage. After it, we gradually enhanced the system with more features, and iterate the MVP in versions. So far there are 20+ projects and 200+ users consuming the design system.

What is a design system?

From a business perspective, a design system serves as a strategy of increasing productivity by avoiding redesign and redevelopment. It’s a set of toolkit used for facilitating customer-oriented development to meet business requirement. On the product side, a design system unifies the product experience by providing company-specific visual standards and pixel-perfect patterns in live code. So that during the software development cycle, the design system is a final guide to visualize your product with best user-centered practices.

Design system is not equal to visual guidelines

It is not easy to build a design system from scratch. When I was in my previous company, a startup, I started my journey with identifying the visual guidelines firstly. The reason is obvious. Visual guidelines are much more easier to be composed, as well as sufficient enough to support the development of a small team. Meanwhile, it doesn’t cost too much labor work if the designer is experienced enough. I iterated the guidelines after reviewing them with product managers and frontend team to make sure everything is validated before the implementation.

Differ from composing the visual guidelines, building a design system needs a great deal of efforts at the beginning of the process. We kicked off the project with a MVP product. During the MVP stage, make a specific plan is very important. What should be included in the scope? What’s the sequence? How many components to be built in the first release? Which development framework will the users prefer? Many of questions should be addressed firstly before execution. After the MVP, we launched the product, and invite people to use it. Meantime, we keep iterating the design system with feedback and evaluation.

Visual Guidelines vs. Design System

No matter building a design system or the visual guidelines for a company, it’s easier to have already been familiar with their culture, business direction, target audience, product strategy and fundamental architecture. What’s better is, you’ve already participated in their product development for a while and delivered several products. When I started to write the guidelines for the startup, I’ve been involved in the development of three products for one and a half years. It’s very easy for me to get the hang of the work. However, for the design system, it’s another story. I started to work on it right after joining the company. That means amount of research should be conducted ahead to get the picture of the company and the products before chopping the steak.

Design system is group work of the professionals

I’ve soaked in the design industry for many years. With years of experience, I’ve seen how this industry being iterated along with the development of information technology. And how designers refresh their skill sets to adapt to the changes. So I am not surprised by the boom of design systems: it is an outcome of the development of the industry, as well as an indicator of the maturity of industrialization.

But the problem is, the design system is hard to be driven if you don’t have enough knowledge from business to visuals. I sound alarmist, but it is the fact. For my case, one third of my time is used for IT support: questions keep popping up daily from the project teams. There are three types of questions:

  1. The newbies of a design system. Their questions are mostly about how to use the system and how to access resources. To address such questions, we built a Getting Started section with instructions in text and videos.
  2. A specific question regarding the project-related UI problems. Such a question is always asked by the project designer or developer. He/She probably meets the challenge when illustrating a project interface. A question like “Do we have guidelines about how to dismiss double scrollbars for best user experience?” falls into the category. The answer of the question, is not simply “Yes” or “No”. Most time we will dive into the details about 1) Why does the double scrollbars happen? 2)Is it a problem? 3) If yes, how to deal with the embarrassment? 4) Will the solution be able to contribute back to our design system and benefit the other teams?
  3. Review their UI design systematically. Since the project teams are asked to align their UI with the standards in the design system, I often receive requests to walk through a project interface design and give feedback. Facing with the problem, the first action to take is to learn its story and understand the full picture of the project; and then comment on the design, no matter interaction or visuals. The reason is obvious: if a fundamental issue exists, it’s meaningless to move to a further step.

Some of the questions are well-thought-out. We had a long discussion about the philosophy behind a text button and a link; and we are still on the way to define color usage for the components’ interactive states. Many users hate the table design from the MVP, and accuses its useless and unreasonable. So that we designed a new version to adapt to their needs better. These conversations definitely increase the depth of the design system, and massage the guidelines and components to make them fit into the scenarios better.

Meanwhile, many design system users, no matter designers or developers, they are willing to contribute their iterations back to the system. Some of them would like taking on leadership roles for certain topics. We build trust by providing knowledge to the community, and the community gives back their knowledge and experience to make the system robust. In this sense, a design system is group work. You lead the project, but also it’s important for you to listen to the users, and empower them to drive the direction in some respects. What should be paid attention to is, as the captain of the ship, you definitely need to know the contributors’ strengths before assigning a specific tasks to him/her. Ask the right people do the right thing.

Design system should target the brand at the earliest

Differ from the startups, our company has already had almost 100 years of history. Unfortunately we were not very successful to associate the design system with the brand at the MVP stage.

A good design system should reflect the brand, while building the consistency. However, not all people are aware of it, and not all of them are able to raise the awareness. Meanwhile, without associating with the brand, our design system still runs well, at least people are still using it as reference. But the problems will emerge from the water after the projects that consuming the system are full-fledged. At that moment, the project teams will ask: “Why are we using this color for the navigation?”, “I don’t think the graphics on 404 page represent our industry well.”, “What’s the relationship between the typography recommended in the design system and our branding typography for marketing?”

To answer the questions, you should rethink about the system from the perspective of product strategy, and then iterate it to clarify yourself better. Actually the iteration can be avoided by targeting the brand at the beginning of the project, if possible.

XiLiGe (Brother Sharp) vs. Autumn/Winter 2010 Collection (photo source: Internet)

What’s the next?

Building a design system is an endless job. The ecosystem will be optimized version by version as time goes on. Our own system will celebrate its second birthday in this September. I know it is still a toddler, and still has many aspects to be improved, but we’ve already set up the anchors to envision its future and facilitate the next execution. Plan the future as early as possible is important, and plan it with your users’ requirements and expectations.

All in all, a designs system is a tool to engage the best user experience of your product, as well as a strategy to increase efficiency of product development. Running such a tool is not only about looking after the guidelines and the codes, but also about taking care of all projects and products that are consuming it. Think and act for your users is the key in the process.



Source link https://blog.prototypr.io/what-i-have-learned-from-running-a-design-system-at--2bb9edc1cef7?source=rss—-eb297ea1161a—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here