UX Workflow — Why the Design System is so often misunderstood
Aloha! Another year has passed, and it’s time for me to share some of my thoughts again. This makes me A) slow and B) inefficient in publishing content, but at least I am consistent in being so! If you are interested in how slow I produce content, feel free to check out the rest of my stories in my profile. Anyway, let’s dive into the topic, shall we?
Firstly, I want to tell you that this story will be most useful for less experienced UX Designers, especially if you come from a very design-centric role and want to take steps into the full scale of user experience. This is also relevant for career changers and anyone who is a stakeholder in the whole UX workflow, such as PMs, POs, everyone with a P probably, and maybe even a C in their job abbreviation. And most importantly, YOU, yes, you DEVELOPER, don’t run away! The best is always mentioned at the end. I want to help fellow designers out to make YOUR life easier in the end. So, if you got baited in here, why don’t you stay with us and read through and maybe share your thoughts?
Secondly, I will be adding a lot of details from my personal experience. So, if you already have an understanding of the actual definition of a Design System, you can also stay and maybe you get another perspective or two! Feel free to share yours too!
There are already great articles on Design System basics out there, distributed for example through leading agencies and professionals like the nngroup, which I highly recommend to check out.
Chapter 0 — We are still evolving
Let me be honest; these won’t be real chapters at all. I just need to roll with the theme that I brought over myself with that opening graphic. So, bear with me ok…
What does this completely philosophical headline even mean?
It’s worth noting that User Experience is still a relatively young profession, which is the reason your role definition as a UX Designer in a project or company can differ significantly. Also, there will be a lot more changes in the coming years, A LOT. We have to be honest; the understanding of an UX Designer was way too broad, and the industry has already changed this abomination of a role over the years. We can split responsibilities now into more specific role definitions, like User Researchers or even Usability Researchers, UX Architects, UX Developers, Interaction Designers, etc.
Why are you telling me this?
Because, I think due to the constant change in our profession, it is more important to understand the toolsets and workflows in UX. It is Key to understand where you are in the Workflow and to what “greater good” you are contributing to the End-Product. There is no problem in specialising in a narrow UX area, but looking over the edge will greatly improve communication, collaboration and in the end the quality and efficiency of the whole product development.
Why am I telling you this?
Because, I think due to the constant change in our profession, it is more important to understand the toolsets and workflows in UX, because it is key to exactly understand where YOU are in the workflow. There is also no problem in specializing in a very narrow UX area, looking over the edge into the fully fledged process will greatly improve communication, collaboration, and, in the end, the quality and efficiency of the whole product team, including you.
Chapter 1 — Common misunderstandings
The main reason why the Design System is often misunderstood is probably due to its origin and the fact that UX/UI designers are typically the lead persons responsible for it. The emphasis on the word “Design” has led to a misconception of the core ingredients and sole purpose of the Design System.
The most common mistake is to solely focus on the Design perspective. A Design System is not just a collection of styles, although having styles set up is certainly helpful in terms of consistency. However, if you only focus on the styleguide and design library you are just designing systematic, this is essentially great but not a Design System.
Feeling lost? Don’t worry, I’m not trying to confuse you (although it may seem that way!). As mentioned earlier, the name “Design System” is somewhat misleading, but not entirely incorrect. It’s important to emphasize the right aspects of it though. We should view the DS (Cool kids call it like this!) as a system that integrates tools to enable more efficient and higher quality design outcomes, but more importantly, it is a communication and automation architecture. Sounds complicated? Well it is, but let’s try to break it down.
You might have guessed from the articles top graphic or you already knew anyway that there is more to a Design System than Design tokens and Component styling. Even if you already understood this, you still might have a slight misconception of the weighting, because the emphasis in Design System weights very VERY heavily, nearly entirely, on the System.
A Design System is an incredible powerful tool for everyone that works on the User Experience, which is in fact nearly everyone in the Company. Yes, you there wake up, don’t sleep in the classroom! Don’t make the mistake to confuse the User Experience with UX Design, I created a whole other short story about this for another time. The short version is: The experience an user has with the product starts way before he actively uses or even bought the product, it may start in marketing and ends in support, or even beyond that in the off-boarding of a user/customer. Yes, a lot of company forget that having an easy, transparent and fair off-boarding experiences, helps in regaining lost customers…Ahem anyhow, so everyone collaborates on building a great experience for the user and/or customer. We all work together, so the idea of a System to improve creative processes and automate parts of the production is a great win for the whole company/project, not only for the Designer.
Using a Design System simply for visual consistency and accelerating the design process is definitely a part of it, but if you only focus on this you undervalue the DS and in many cases it probably is contra productive. the reason for this is that the maintenance of a Design System can be very taxing from only an UI point of view and not using it properly can slow down processes instead.
You may have already noticed from the top graphic of this article, or perhaps you already knew anyway, that a Design System is much more than just design tokens and component styling. However, even if you already understand this, you might still have a slight misconception of the weighting, because the emphasis in Design System weights nearly entirely, on the System.
The Design System is incredibly powerful for everyone involved in creating the User Experience, which, by the way, is nearly everyone in the company. Yes, everyone! Don’t mistake the User Experience for UX Design…but I will save that explanation for another time. Just know that the experience a user has with a product starts well before they even use or purchase it, and it may end long after that as well. This involves marketing, support, and beyond. For example: Companies often forget that providing a transparent and fair off-boarding experience can help regain lost customers later, building a proper UX for this process can be very beneficial. So, building a great experience for the user or customer is an effort of nearly the whole company.
Which means a Design System is a win for the entire company, not just the designer, as it improves creative processes and automates production. Using a Design System for visual consistency and speeding up design processes is just one aspect of it, it greatly undervalues the DS. In fact, relying solely on the DS for UI purposes can lead to actually slowing down the production, as it requires significant maintenance, which only makes sense if we utilize it to the fullest.
Chapter 2 — One system to rule them all
So, what is a good Design System? What is core for the success of our System?
You probably asking this questions now, so let me explain this in more detail. Therefore I improved the title graphic a little and make it bit more technical.
This may seem like a lot to handle, and honestly, it is. Developing a proper Design System requires a dedicated team to manage and maintain it together. It also requires a considerable setup time, but depending on the chosen tools, you can jumpstart much of the process. I may delve into the details of this topic even more in the future. However, aside from all of this, the primary task is to connect all the pieces properly and ensure that the entire product team understands the core assets of the Design System.
The graphic above shows my personal preference for setting up the core modules of a Design System. There can be many additional parts, or even leaner approaches to the process. You can also easily break down some of the components into smaller pieces, you might want to name it atomic design system…NO…please don’t make that a thing, let’s be happy we are mostly through this hype by now *sights in atomic*…Getting back to the topic, the approach above works well as a base structure. Essentially, we draw four lines to the four key ingredients of pretty much every product workflow and build our Design System to improve them.
I will split up the graphic and explain each section in detail, let’s start with the basic but most important component of every product workflow!
Chapter 3 — Improving team communication
I can sense the question mark in your mind, so let me explain. The truth is that as designers, we often exist in a bubble — a magical bubble of UI where we believe that if we make everything look good, people will wake up one day and appreciate our shiny new 10px rounded super anti-aliased button. But this is far from reality. As we move into UX, we soon realize that users won’t appreciate a nice-looking button as much as we would like them to. They really should though. And, more importantly, management doesn’t usually care about creating the smoothest and best-looking UI. The harsh truth is that good UX sometimes even involves designing something ugly.
In general, product management is primarily focused on producing a valuable product, usually a minimum viable product (MVP), that can be sold profitably to customers. This means that excessive UI design takes a back seat to the need for a simple UI with a maximum gain in profit. Therefore, only fellow UX/UI designers will truly appreciate a great looking Design Kit in terms of a product’s quality perspective. While tools to build unique and beautiful interfaces are a great asset, it can be difficult to explain and justify their place in the product development process compared to other priorities and general time management.
So…why should you fight for it? Well communication!
Communication is crucial in any project, and a proper Design Kit is essential for project and product teams to communicate ideas and requirements effectively. This, in turn, benefits time management in the project and provides more leeway to improve the overall quality of the UI. See it is a win win for everyone in the end, we get to add 3 different button variants that look gorgeous and improve the efficiency of the whole process. A good Design Kit is the most powerful weapon for a UX Designer, as a great setup enables them to prototype and wireframe in real-time (Rapid-Prototyping), which in return is one of the biggest assets to have for the conception and requirement engineering phase. Visualization is key to communicating between teams and different hierarchy levels, and aligning the vision of the whole team.
A working Design Kit not only helps the designer work faster but also allows for easy communication of ideas and concepts between teams, while giving designers more power over small adjustments and improving the overall UI quality.
A small Styleguide and library of basic interaction elements is already a big help if set up correctly, but to actually impact the product quality, we need to go one step deeper in the workflow.
Chapter 4 —From Collaboration to Automation
Before discussing what I believe is the best solution for building this part of the Design System, let’s start with the basics and understand the goal we want to achieve here.
Generally, all parts of this process go hand in hand. For example by improving the team communication abilities through a lean design process, we can end up with more time spent collaborating in cross-team product development. Collaboration is amazing, but it requires a lot of effort, so we need to keep this in mind when engaging in it. Apart from setting up structured communication outside of design, for example methodical scoring of requirements or a healthy meeting and workshop setup, we need to build utilities to quickly convert whatever the team comes up with into working prototypes.
The most important part in this process that we need to improve, as nobody will be surprised to hear, is the synchronization between design and development. But how do we achieve this? Through automation!
I think I don’t need to explain why we need to automate processes for any developer who has made it this far in the story, but let me still try to explain.
If we want to truly collaborate, the team needs to be working in sync on the same topic and everyone who has a stake in it needs to be involved, otherwise we loose important perspectives. So we first need to reduce the time for developers working with change requests, having to always manually work on building every small component change wastes a lot of time. This also goes hand in hand with improving communication between design and development teams, as a lot of misunderstandings result from this. You need to understand that a couple of minor changes in style seem simple, but they lose their importance if they summarize and you have to insert these changes manually every time, so naturally, you might be met with annoyed faces after the third time in a year you change your button’s border-radius (I’m actually not even sure why I’m jabbing at the poor border-radius anymore).
Let’s speak about some more specific details of this process before we jump into the solution I mentioned. While from a process perspective I tend to divide the component library and developer sandbox, there is a tool that combines both, but let me first explain what exactly is my definition of both.
Component Library
So, our component library is the part that needs to be directly synced with the Design Kit before. The initial design tokens must be built into fully-fledged interface components and made ready for the development process. Setting this up can generally work in two different directions. The first and in my opinion faster method, which I believe is faster, I will explain underneath in the developer sandbox section, specifically frameworks.
However, let's clarify what is generally to do, shall we? We want to create a library of patterns for various basic and custom components. For example, our 10px border-radius button is an important part of our Design Kit in combination with specifically the pattern library, to ensure we create beautiful interfaces with consistency. Another important part of a component library are the specifications of our patterns, ideally synced with the actual Frontend framework and providing simple and fast to use code snippets. At the minimum, we want the patterns to be easily usable, so this is the first tightly-knitted process tool to build a bridge from fancy design files into development.
Developer Sandbox
So why do I even separate this part of the DS? Mainly, to avoid mixing up the different emphases on them, but also to visualize how the parts influence the product workflow in detail. While I would always recommend starting by building this environment based on a kickstarting kit, like a fitting and working frontend framework, which can be setup initially from the dev team, the end result should be converting the framework in a cross-team accassible component library lead by a dedicated UI team.
Before I present my personal recommendation, let me define what I mean by a “developer sandbox.” essentially, it is as easy as the name suggests though. We want to have a sandbox for our developers to play in…no sorry I’m joking…we want to have a development ready environment and a backbone for the components based on our design system. Therefore, all rules, starting from design tokens, components, to layout specifications like spacings, and such, must be in place and quickly available for our developers to use. A frontend framework already comes with all this benefits and building on top of it ensures we don’t take years starting our project.
Additionally, we must ensure that all components work correctly, which is often undervalued. Let me go back to the button example…yes again. So let’s say the button is live and looks gorgeous, but what benefit does our user have if the properties that needed to be added don’t work in a specific browser that perhaps 80% of our users use? In the worst case they will see a blank spot, what now? Okay, so I may have dramatized the scenario a bit, but a button is a very simple component, so I had to put a little flavour in the scenario… There are better examples, but I really don’t want to talk about the hell you can go through with things like simple inputs, popover menus, or SCROLLBARS…
Give me a second *trying to stop thinking about scrollbars*…
My go-to recommendation is generally to reverse-engineer your component library based on the framework you select with the development team. In this process, you can work on slight or bigger customization's of the framework, obviously always based on the team and project scale and timeline. Our minimal priority is to build the general structure, so everything can be automated and streamlined for our Design System process afterward, so we can optimize parts of the design system with little to no time effort in the live process.
Storybook
Finally, let’s talk about the solution I mentioned and you probably already spotted in the graphic. Let me explain Storybook a little and why I think it is a genius tool that should be mandatory for every development process that involves a certain level of complexity. The great thing about Storybook is that it combines all the above-mentioned tools into one, allowing you to use the framework you prefer and integrate it into a well-structured Storybook component library. Most well-known frameworks already come with a storybook library, so you just need to install it and you’re good to go from a development perspective (I know I’m oversimplifying, but you get the point! Sorry to every developer that stayed with us till now).
The beauty of Storybook for us UX/UI designers is that it enables us, firstly, to have a clean library overview to build the matching design library (If the framework doesn’t provide a basic kit to start with), and secondly, it enables us to communicate on details and review live components right away. Storybook is perfect for a review processes early and later in the whole workflow surrounding it, as it can be visually accessed and used by almost everyone. The cherry on top is that all component functionalities can be displayed and controlled through an options panel that mimics component panels in design tools like Figma or Sketch. (Sorry Adobe XD, but after investing in Figma I guess they given up on you anyway? So farewell may be more appropriate?)
Which brings me to why I would advise reverse engineering this setup. Storybook makes it easy to clean up the messy and confusing options in the starting framework, and you can use it as a manual to build up (or clean up, if it came with a design file) the design library. Don’t ever skip this process!
Why clean up the framework=? It’s important because UI frameworks are generally made to fit a wide range of use cases, and it’s best to simplify the toolset you will use as much as possible. Every unused component variable is a possibility for errors and inconsistency in the product development, and we don’t want to risk this, right? It’s also important to approach this carefully as a team activity on both sides, designers and dev alike. Unnecessary components should be pushed out completely in the design and development library, collaboration in this process is key to avoid inconsistencies and possible miscommunication later on, which are core issues we want to improve with the Design System to begin with.
Chapter Summary
Did I do this in the other paragraphs? Speaking about consistency and being all over the place myself, let’s just say I try to be consistent in finding a new structure for each paragraph!
Side Note: While we speak about consistency, here is a fun fact, the UX and UI consistency is defined by the rules YOU apply, but at the same time this doesn’t mean the rules are actually a benefit for your users. So you should always check if the rules you apply actually create an experience that your users benefit most from…ahem…user experience research. In theory, like in my bad joke above, you can be consistent in many ways.
Give me one second, let me get my pencil…
Checklist: Getting completely distracted from the actual topic once ✅
Well…lets get back talking about the component library…
Where did I stop? Ah, the summary…Generally, there are a bunch of different ways to set up a proper component library and maintain it, but I think currently, Storybook has far more advantages over other setups. But in the end, the decision is not only up to the UX designer, so you might need to build the technical and design infrastructure differently to meet the teams expectations. However, the key takeaway I want to give you is the importance of a well-structured library setup — it pretty much makes or breaks anything around the design system. As I said in the beginning, you may be fine with a disconnected, only design-oriented small library to make your own work faster, and you certainly will already benefit from this. However, in the end, a component library with deep links into development is what will actually bring your processes to the next level.
Speaking of the next level (Didn’t saw this smooth transition coming?)…
Chapter 5— Documentation, yep…
HEY! ALREADY SLEEPING?! STAY CONCENTRATED!
Sorry, need to make sure you stay awake, I know this topic isn’t the most exciting, but it’s also one of the most critical parts of any process. It really is, without proper documentation we’ll end up in a nightmare trying to maintain the Design System. So let’s fast forward the last two chapters, once we’ve successfully set everything up and combined our design and development assets into a beautiful cohesive library, we end up with two parts of documentation, technical and design. The good news is that they can also be maintained separately.
Let me try to visualise this.
I mentioned that I don’t like this topic either…so I tried to create this as fast as possible, but jokes aside, now is the perfect time to look back at the article and take the time to orient ourselves. See what I did there? A perfect transition again! Because that’s essentially why we need documentation — to be able to remind and orient ourselves in the current process at all times based on basic guidelines, and also through past projects and tasks.
As you can see from the graphic above (or not), the Design System acts as a narrow framework in itself for the core process of product development and brings all the different threads together. This makes the DS so powerful to really empower the collaboration aspect I mentioned earlier. However, every collaboration process has an end, as it cannot transform a developer into a designer or vice versa. What collaboration does is improving the understanding between different stakeholders in the workflow, but maintaining, providing and making all the gathered and build knowledge accessable should be distributed into the appropriate team responsibilities.
Now, you might be wondering what the administration part in the graphics is all about? Well, as I mentioned earlier, we want to improve all aspects of the product workflow, and what comes after all the fun parts setting everything up? Administration. This includes maintenance and the onboarding process for new team member, which is a significant part of running such a system long term.
ATTENTION! STOP DOZING OFF!
…I nearly did myself though…but this is VERY important. While I demonstrated that the workflows split in the end, it does not necessarily mean that everyone needs to work on different sources. What I mean is that it is important to have clear responsibilities for documentation and everyone does their job. Every design documentation is created by the design team, and every technical documentation is produced by the dev team. This does not imply that you need to divide the source of documentation, having a single documentation space that combines technical and design usage will bring you numerous benefits.
I won’t go into too much detail about tools because there are several options available, but as a general recommendation, you should integrate the tools you may already set up. A very good solution is to use Figma and Storybook together. Storybook offers a Figma plugin, so you can create the design documentation in a seperate Figma file or even your main library and insert them into the appropriate pages in Storybook. The downside of this setup is that maintaining the structure generally falls to the dev team, because Storybook currently does not have a real WYSIWYG editor, which makes it challenging for many designers to contribute directly to the code-generated documentation pages. However, this does not mean it is a bad setup. Another recommendation that you might want to consider is Zeroheight, which includes both, a Storybook and Figma integration.
My general advice is, start simple and scale your documentation process later if needed. You can always past your documentation content from tool X to Y, it is far more important to have everything started in the first place.
Summary
Almost done! Let me summarize my thoughts here really quick. So what I wanted to showcase with this explanations above, is that a Design System is more than a tool to make UI better. If you setup a whole cohesive system, you greatly improve the most important assets of the product development workflow.
What you should take away from this, planning and communicating the benefits to your team will help you get away from that little isle where a lot of designers currently sitting. You know cursing “it looked so great in the Screendesign what have you done” out of the ocean, but nobody helps you.
In this regard I want to end this story with a great mentality to learn in my opinion. If you want to achieve something, help out others first and it will greatly help you too. If you want to greatly improve the UI of your product, get everyone connected, make their work as easy as possible, so you have more time doing what is best for you and your users. This is no magic spell, sometimes it won’t work out, but involving yourself in building a very communicative and collaborative workflow will give you a way wider view than just sitting back complaining!
That’s the end…let’s see if I can be a little more active this year, because sharing stories and getting feedback is fun, it’s just a big time investment.
Almost done! Let me quickly summarize the thoughts. I wanted to showcase that a Design System is more than just a UI tool. If you properly set up a cohesive system, you can greatly enhance the most important assets of the product development workflow.
The key takeaway is that planning and communicating the benefits to your team will help you move away from the isolated islands where you might currently sit, cursing and wondering what went wrong with the interface to end up completely different to your imagination. What I wanted you to learn is improving the teams workflow and cohesion is key to a higher product quality. So, to improve the UI of your product, you need to get everyone connected and make their work as easy as possible. If you achieve this, you have more time to focus on what’s best for you and your users.
Sounds good right?
Disclaimer. Keep in mind, there’s no magic spell, and sometimes things won’t work out even if you tried your best, live is hard, yep. But involving yourself in building a communicative and collaborative workflow will give you a broader perspective than just sitting back and complaining. If it doesn’t work out in the end, you have A) a positive feeling, because you tried something and B) a definitive answer to the question you might be wondering all along: Should I move on from this project or company?
In closing this, I’d like to share a, in my opinion, great mentality to build for yourself: If you want to achieve something, stop asking and complaining, help others first, be proactive and it will greatly benefit you too.
That’s it! I hope to be a little more active with creating and sharing stories stories because it is fun…It’s just a big time investment…
Till then!
