There’s a lot of talk about how to create design systems and what steps are needed to get there – but what happens afterwards? How is life after the design system is in production?
So you finally have your design system up and running and connected to production. What happens after that? Is it just smooth sailing from now on? Let’s take a look at new things that it creates and affects.
Design Systems Team
There probably was a project team to create the design system…and now you notice you need a brand new team to maintain it. The core team might be a bit smaller compared to the original project team, but you will need it anyway. It is a matter of resources and scope of the system of course, but it would be a good idea to have a formally nominated person to be responsible for it and allocate work time to it. Pair of developer-designer is a natural fit for the position.
It is also a good idea to get DevOps involved to make the use and deploying of the system as easy as possible.
You need a brand new team to maintain it.
The great question is of course how much resources is the right amount for this team? When the system has been launched recently, there might be no urgent needs to update it – on the other hand, over time it gets easily out-of-date if the responsibilities are not clear and there is just virtual loose team responsible for it.
Design Process
One of the main principles of component-based design system should largely remove the pain of closing the design-development gap and provide an easy, consistent and fast way to implement pixel-perfect user flows. If done correctly, the design system also provides tools how those components are positioned compared to each other, meaning spacing and grid.
For small changes, this might be true. You don’t even need a static design, rather just a drawing with pen and paper, what components to use and where. Sometimes the designer’s job is transformed to act as a communicator and providing timely “clipboard designs” for the interface.
One of the main principles of component-based design system should largely remove the pain of closing the design-development gap.
In larger features, there are more stakeholders involved and communication needed – all the stakeholders might not have access to tools that are used to create interfaces. That’s why there is still a need for static designs, that can be easily shared to get a good overall picture of what is going on.
Luckily, new tools like Figma make it possible to both componentize designs and share them online. The downside is, that you have to maintain two systems instead of one, one in code and one in Figma. There have been efforts to close this gap as well, but needless to say, it demands labour with extraordinary skillsets and strictly organised approach to the system.
The question is when to use custom design if you are running a design system? Some elements, like banners, try to disrupt and grab attention by nature. No matter how good of a banner you design, you might need something else next time.
Sometimes an element needs to be “more significant” than usual. For example, if you are making an important choice with a plain radio button, that might not be enough to communicate its significance. That’s why there might be a need for making different variations (size, contrast, images) for controls that do the same thing. Of course, these variations can be implemented in the design system, but it might be an overkill.
The question is when to use custom design if you are running a design system?
You one year ago might think differently than you now. However, the founding principle of any design system is consistency – so if the current design does its job well, there is often no upside to do redesign “just because you feel like it” or whatever you learned last week. Design system sets a bar for designers to design with quality, consistency and longevity.
Static Designs
When brainstorming a new feature or product, static designs still have their place. They are fairly quick to make and modify when the level of detail is not yet covering all the possible use cases. Most of all, they are very easy to share to different mediums. By static designs I mean views, that are not responsible or don’t have advanced interactivity. Skill sets and tools designers use might vary, but most of them are very familiar with these tools – so they do not exclude design people in larger organizations.
When brainstorming a new feature or product, static designs still have their place.
One could argue that “there is no need for static designs after design system is in production”, but it depends on what tools people use and are willing to use. It helps, if product managers and give input directly in the form of copywriting or commenting. While design tools are nowhere near perfect yet, there is a place for tools that are easy to adopt by different stakeholders.
The downside is of course double workload – when the product is out and is being improved, it is a tedious task to update the static designs to match what’s in production. As a sole designer, there is not much point in that either. But in case you have to hand off a product to another designer with a slightly different background and skill set, the static designs might help to get on the moving train.
Things are not usually black and white. So it might be a good idea to have some static designs with the design system – reaching the level 100% might be too much work and make things too fixed, ditching all static designs might harm communication.
Deprecated components
When the system has run for a while, you will notice some components have…old style. Or they are not used anymore. Before you ditch them you should be able to track them down. That might sound like an easy job, but depending on how large is your app or does it include several apps, it might be surprisingly tedious. When you track down the usage, you might want to redesign those views as a whole.
Deprecating an element might not be the most important or urgent thing by its nature anyway, so you will be left with a question:
- To redesign the component
- To “kill the component softly” by with threats and deprecated tag
- To just kill it (and possibly watch the app burn)
Because it’s good to have good manners and not break the app, it rules away number three. Number two can be done easily, but it is just altering documentation. Number one remains the only option…but it takes the most time. Also, it just might not break your prioritization list for the week. We can always deprecate it next week.
In the world of design systems, you can find yourself redesigning a component already before the system is applied to all parts of the app. It just means that a design system is a tool, not a solution. Tools involve multiple designers and they all have their preferences what components to use to solve a problem.
Documentation and training
Documentation helps you to leverage the system organization-wide. While it might not be the sexiest part of the project, not doing it will hurt you later on. Luckily, there are really good tools for documentation out there nowadays.
Documentation helps you to leverage the system organization-wide.
The design system might be used the most by the core team, but many developers might use it occasionally. There is a rare breed of developers that proactively ask design-related questions, but it is a good idea to have design systems training for all the new developers joining the company. Same goes with Product managers and people related to those positions.
It is also a great way of making your work more transparent to the whole organisation.
Version control and publishing
If you are working with design systems and have a DevOps in your organization, have a chat with them how to make the system as appealing as possible for developers and how to increase the transparency of the changelog to all the stakeholders.
Versioning the design system, making deployment easy and tracking changes is crucial to increase the popularity of a system among developers. Also, you want to be able to answer the question “when are / when were the changes visible in the product and who pushed them”.
Refactoring
In the world of frontend engineering, everything might change in two years. In the world of business, you might not get the most value by rewriting your whole app every two years. These are the two facts that many companies deal with every day. While the new startup always uses the latest and the most developer-friendly technologies, if successful, they eventually grow larger and have to update their tech stack at some point.
For designers, it might mean that the design system is not operating in all areas or all apps the organisation is using. It also might be a consequence of design systems team being too small or some other resourcing related decision. On the other hand, there always seem to be an organisation that has been able to pull it off. The underlying reason might come to valuing design, company culture, speed or anything in between.
In the world of frontend engineering, everything might change in two years.
What is for real is that if your UX team can to directly contribute to the codebase of the product, you will have more respect and influence among developers. It might not be the UX team rewriting the whole app, but contributing to some parts can make it easier to let your team have a voice among developers – and it can also inspire them.
While refactoring the app might not provide immediate value, it might improve the overall UX, designer and developer experience and in the end, speed up innovations and developments cycles. But of course, make sure that your product-market fit is there, in case you are a startup.
State of mind: Be consistent, maintain creativity.
Design systems are there to bring clarity and speed for design and development. It is also important to maintain creativity and not take the system as religion. System can always be changed or custom design used, if that is what serves the purpose.
Be consistent, maintain creativity.