The Evolution of the Design System (Designer)

We often hear about the evolution of design systems and how they have grown and changed, but what about the designers who create them?

About a year and a half ago, I came back to work from maternity leave and found myself in a new role. Not just as a second-time mama, but as the *lone designer on the Design System team.
*with the help of contractors and product team designers that contribute back

As a UX or Experience Designer, you need to have a unique skill set. You need empathy, listening skills, research techniques, and problem-solving methods.

But what does it take to transition from an Experience Designer to a Design System Designer? It is so much more than just building a Sketch Library. Here are just some of the ways that this evolution has changed me…

Perspective

Our design system currently serves 5+ different teams within our organization. The Design System Team is literally setting the standards for the entire UI of our software. We take existing products, identify their needs, and design components to solve their problems. I am still operating as an Experience Designer in that I keep the end user in mind, but now also need to think of a secondary user, the hundreds of developers that will be eventually using these components.

In this role, it’s critical to keep the larger picture in mind. I have to think about the way 1 “small” change in typography size will affect designers, developers, and end users alike. When we are gathering requirements for a component, we need to consider all products (and personae) so that we don’t finish development only to realize that we haven’t thought about a particular use case. We try to fail fast and iterate as we go, but major issues can be avoided by keeping a broad mindset from the beginning.

Start small to build something great.

It’s also important to also to keep the reigns on the scope of the work we do. We work in such small parts, that it’s easy to get anxious and want to design & build ALL THE THINGS at once. But everything good in moderation. We just chip away at the list and try to ignore the fact that our backlog has 300 things in it.

Balance

Part of my role in designing components is following industry trends and the latest UX recommendations. For each individual component, we do a competitive analysis of sorts to see what already exists within other design systems, and what trends might be happening. But it’s not all about a posh design. We also do extensive research on accessibility and consider the inclusivity of our users. This has separated me a bit from the “blue sky” creative work that I have previously done.

When we face a design decision that we can’t seem to find alignment on, we ask ourselves which is the most accessible choice. We are building world-class software, but we start with the users. We have to make hard calls sometimes… like with text links. After much deliberation, we decided that our text links (with the exception of navigation) would have an underline. Does it add visual clutter when you look at a page with a lot of links? Yes. But is it the most compassionate thing to do for the usability of all people? Yes.

Sometimes it’s okay to sacrifice a beautiful design for usability. 😱

Detail

I have always had keen attention to detail and am a bit of a perfectionist in my own right. But now it’s like my eyes have become microscopes. We will be reviewing a workflow and I tune out the conversation and notice a mis-spelling, capitalization issue, wrong space token, or incorrect color.

When designing a component, I need to be sure that I have accounted for the right typography, color, spacing, etc. If something goes unchecked and gets developed, it won’t just be wrong in one place, but in every product. No pressure. On top of actually designing the components, we also write the documentation that accompanies each one. We have to do this thoughtfully so that designers and developers can easily make decisions on how to use the components within their own products. Okay, we have the thing… now, how do we use it?

Documentation is as critical as the design.

I referred to my role as the Team Librarian in this post. With all of the details of each component stored somewhere in my brain, I’ve become the person that everyone comes to with questions. Do we have this component yet? If not, when will it be developed? How much space should we have under headers? Is there a standard height for dialogs? Where are the requirements for dropdowns? If I don’t know the answers, I need to be able to find them. My memory has become much sharper (even though those 2 kids are challenging that every day).

This comes with responsibility, as I need to deliver the correct information in a timely manner. Example: We went back and forth for a long time about the previously mentioned links. We made the final decision to underline them and I updated the documentation and designs accordingly. But when asked by a designer weeks later what the right call was, I gave them the wrong answer. Twice. That’s why it’s nice to have a supportive team around you, to help you brush off those mistakes and keep pushing forward.

Governance

“There is a standard for that… and you should use it.” When you help create the rules, you also have to enforce them. One major shift for me is learning how to govern the designs of our 10+ designers in a thoughtful way. We work FAST and there are special use cases that pop up in every product. So I need to be able to understand the products, and where our standards should be applied. But also know when to back off, leave it alone, and allow that product to have it’s own “thing.”

We are always evolving our governance process. We host design review meetings weekly and share mockups back and forth, but we still don’t catch all of the work being done by our amazingly speedy designers. They are sprinting quickly to meet product deadlines, and we need to be sure that we can keep up and step in to help with governance when we can.

Governance can make or break your design system.

What is the point of creating a standard that no one is using? We have faced this issue in the past where each product starts to create variations and all of a sudden, we have a mix-match of software. We try to work very closely with our product teams to not just hand over components, but create a partnership with them where we can have this open communication and reliance on each other.

I am grateful for this unique opportunity to learn and grow… to stretch my capabilities and my expectations as a (design system) designer.

// Katie