Life After Design Systems

Design systems are valuable not in and of themselves but as a means to an end: freeing up time for work that’s more interesting and (hopefully) more valuable—both to us and to the end user.

Design systems are so hot right now—but hey, I don’t have to tell you that: you already have one! It took some serious time, effort, and cross-team collaboration, but now you can put your feet up, sit back and reap the benefits … right?

Much of the content around design systems is (rightfully) focused on getting a design system started: getting buy-in, building components, organizing Figma files, etc. What there’s less of is information on “what’s next”—life after the design system kickoff.

In fact, some devs and designers even worry that the creation of a design system will actually make their jobs worse by taking away the kind of work they currently do. While there’s a very small grain of truth in that, I firmly believe that design systems only remove the repetitive and tedious work from your workload, freeing you up to do the more interesting, engaging work. Let’s take a look at what that work could look like.

Design System Upgrades and Maintenance

OK, we are admittedly starting out with the most boring one here by far, but we have to get it out of the way. Design systems are not one-and-done; they should evolve with your team and the work you’re doing. While there is quite a bit that can stay static (hopefully your brand colors aren’t changing every year), things like components, patterns and documentation (to name a few) should be updated regularly. As your application or website grows and expands, you’ll have new things to add to the design system.

Thankfully, this is significantly less work than creating the design system; it won’t take nearly the same time or effort to maintain as it did to get off the ground. I’ve found that the best approach here is to build in some time for a tune-up each cycle, whatever a “cycle” looks like for you. Maybe that means once a quarter, once every other sprint, once after each release—pick whatever makes the most sense for your team and will fit most naturally into your regular flow. Ideally, this shouldn’t take more than a day or so; if things are changing more rapidly than that, you might need to take a step back and look at how the design system is (or isn’t) being used.

Obviously, the specific work will depend on what’s included in your design system, but here’s a general checklist to give an idea of what “maintenance” might look like:

• Were any new patterns established? Add them to the library.
• Were any new components created or new features added to existing components? Add them to the library and document.
• Did you use an existing component in a new way? Update the documentation.
• Did brand content (colors, fonts, logos, etc.) change? Update the library.
• Did you get any feedback about the design system (either internal feedback about design system usage or external user feedback about the design)? Now’s the time to address it.
• Is the design system being used? If not, speak to folks about what could be improved.
• Are the technical elements of the design system (Figma files, third-party libraries, etc.) using the latest version? If not, time for updates.

User Research & Testing

Having that extra time back means that now we get the opportunity to re-prioritize some of the important work that often gets cut because it’s not a shippable feature—and one of the most common things on the chopping block is (unfortunately) user research and testing.

Talking to users is time-consuming, but highly rewarding. With a little extra wiggle room in your schedule, you can start thinking about things like user surveys, one-on-one interviews, focus groups and observation sessions. There are a wide variety of ways in which you can learn more about your users’ goals, processes, workflows and opinions—which one you pick will depend on what you’re trying to learn and what you plan to do with the data. For example, surveys are great for high-level data comparison and analytics, while interviews can help you dive deep into a specific use case or pattern. Hey, maybe you can even put together some personas.

While user research is focused on getting to know the user, themselves, usability testing is great for getting to know your own product a little better. Sounds backward, right? After all, who would know a product more than the people who built it? In fact, you might be surprised what you can learn about your application by observing and talking with the people who use it. Whether you’re testing new or experienced users, there’s a ton to uncover by doing some good old fashioned usability testing. Consider testing areas where you know there are pain points so that you can invest some time in cleaning them up—or new features, even while they’re still in the earlier design stages.

Architecture & User Flow

Legacy software often develops a life of its own, in many ways. As goals and user requirements change, new features are added on wherever they fit in the existing structure while old features get de-prioritized and left to rust. The flows, patterns, menus and architectural choices that made sense when the app was new may not be the right fit for the product in its current state.

Every now and again, it’s important to take a step back and look at the application as a whole—but that’s often work that’s set aside in favor of shipping the next hot new thing. With the time you have now, it might be a good idea to look at the overall architecture of your app and think about whether the structure right now makes the most sense for what your users are trying to achieve with it. Not sure what the users are trying to achieve? Good news—that’s where all that user research and testing will help fill in any knowledge gaps.

Accessibility

Of course, in an ideal world, accessibility would be a natural and fully integrated part of the design and development process. I’m a huge advocate for accessibility first—making sure that accessibility is considered as part of the minimum viable product.

However, for a variety of reasons, that’s not always what happens. Maybe, despite your best efforts, you were overruled and something had to be launched without the level of accessibility testing you would have liked. Maybe your team is doing a great job with accessibility in new features, but haven’t looked at some of the older stuff. Maybe you’ve just never had the time to do a full accessibility audit. Maybe a feature was in compliance when it was built, but standards or laws have changed since then. Maybe you’ve achieved WCAG A-level compliance but would really like to kick it up to AAA.

Whatever the reasons may be, if you have parts of your product that you know are lagging a little in the accessibility category, those are great places to focus your attention. We already know that design systems can offer significant help in implementing accessibility: when the building blocks are all accessible, it’s a lot easier to create a finished product that’s also accessible. However, “easier” doesn’t mean “automatic”; even if every individual piece is accessible on its own, it’s still very possible to use those pieces to create something that’s not accessible as a whole.

Accessibility isn’t a trend and it’s certainly not going away—this is a great place to invest that extra time and effort to level up the user experience of your app for all your users.

Innovation

This is the big one: the main goal of most teams creating a design system. They want to free up all that time and refocus it on new ideas—brainstorming, building new things. After all, this is what got most of us into the game in the first place, right? At least speaking for myself, this was the addicting part; the feeling of connecting the dots, solving problems and creating something from nothing. It’s the part that scratches the itch, makes the long days and weird client feedback all feel worth it. Unfortunately, it’s also often the first thing to go when you’re slogged down with the day-to-day work of maintaining a website or application.

Design systems give us the freedom back to think big. Not only is there time saved on that regular maintenance work, but also time saved on implementing future features, pages and ideas. Design systems make work faster, which lowers the stakes on trying something a little different. If it’s not right the first time (and let’s be honest, when is it), iteration is faster. And if it’s just not working at all, the investment of time and effort was lower and having it be “wasted” stings less. Of course, I’d argue that if you learned something, the effort wasn’t wasted … but that’s another article, entirely.

Time to Get to Work!

Design systems are valuable not in and of themselves but as a means to an end: freeing up time for work that’s more interesting and (hopefully) more valuable—both to us and to the end user. While some may argue that design systems reduce creativity, I actually say it’s just the opposite: they enable creativity by reducing the risk level and time investment of trying something new.

Whether “new” for you looks like adding fresh components to your component library, scheduling some user feedback sessions, re-working the application nav structure, increasing your WCAG compliance level or brainstorming a big new feature—it’s all important work that can now come to the forefront because you don’t have spend time building that 6th login widget. I don’t know about you, but that sounds like seriously good news to me.