I recently completed work on an enterprise design system. The story was a familiar one: our client had both built and acquired many products over the years, and they all looked and behaved differently. And not in good ways.
This was my first time on a design system project. I have of course designed style guides, pattern libraries, and sticker sheets in the past, but these deliverables are different in that they are typically created after the fact. This time, the design system work began well in advance of product redesign and development work.
I learned (and even re-learned) some things. Maybe you’ll find them useful.
A design system is an expansive undertaking, and our client’s first concern was what it should look like. That’s natural; one of the more obvious benefits of a design system is a cohesive style. It’s a highly attractive feature, especially if there is a lot of inconsistency in the current product.
Everyone has a different level of experience with design; one client may be able to look at something generalized or abstract — like style tiles or element collages — and easily fill in the blanks. Another client may require something more literal, like seeing full mockups of a few of their existing screens before they feel okay with signing off on a stylistic direction. It’s important to have a conversation with the client, show them examples of what you can do for them to establish the visual direction, and pick the approach that fits their needs.
I didn’t have a conversation with my client about this, which was super dumb of me. I simply told the client I would be creating element collages, and showed them some examples of what they were. I didn’t give them a choice, assuming the output would be just what we needed given the time we had. We were under pressure to quickly move into component creation (but when is design not pushed to go faster, amirite?), and I figured that collages would allow for an acceptable degree of stylistic exploration in a short amount of time. Upon presenting the collages, the client responded positively but was a little wary of charging full speed ahead based on such limited, abstract selection of visuals.
I won’t make decisions for the client next time. In retrospect I should have presented all options, explained their strengths and weaknesses, and followed my gut by recommending full screen mockups. It’s much more effort up front, but the representation of a familiar screen would have made the stylistic direction much more real. Based on the client’s design maturity, I think that would have been more effective and started the entire project with a higher level of confidence.
In general, there is a logical order in which design system components are constructed. Complex components are built from smaller ones. Forms, for instance, are made up of various inputs and buttons. The production of components should be organized in such a way that they can be continually used to construct larger elements. Toward the beginning of the project, these larger elements might be forms. Further along in the project, the larger elements might be whole pages.
I think we got this right, for the most part. We started by selecting typefaces, icons, and documenting a basic color palette, and then moved into foundational elements like buttons, links, textfields, dropdowns, etc. The one thing I overlooked in the beginning was defining the base unit — a rem value by which we would size everything in the system. Clearly, I would define this early on next time, as not defining on it from the beginning caused us to have to adjust some component sizing in code later on. It wasn’t a huge deal, but it would given us cleaner design throughput and parity between our Sketch files and coded components.
(Bee tee dubs, we arrived at 8pts = 1 rem. It multiplies well and dovetails nicely with 8-point grid systems.)
I found that the worst way to a approach a design system is in the way that it’s often pitched to the client: as a collection of discrete components that can be put together in a million different combinations, like Lego bricks. That may be a good way to think about a design system when it’s completed, but not when it’s being designed. The relationships between components is critical, and if components are designed in isolation those contextual relationships will be missed.
This was something we did not have planned out to do, though I intuitively did this as I went along. However, having to steal time for these exercises was not optimal, and it would have been much better to have proper stories in the backlog that ensured there was time for these activities. These stories — whether they are for components, sections, pages, or whatnot — dedicate time & thought toward continually zooming out and assessing how all the components play together.
Components need documentation. The more complex the component, the more lengthy the documentation (generally). The website we created for the design system needed copy to describe components, patterns, guidelines, principles, code, and more. We definitely underestimated the amount of time it would take to sit down and write all of this content, even with all the “starter” content we could reference on other design system websites. I don’t have a magic solution for the next time I do this, like “add 20% more time to every story”, but I’ll definitely look more closely at each element’s expected functionality and consider what effort it will take to fully explain its usage.
Lastly, a Design System ≠ a Designer
While it’s true that a design system can include complex solutions and describe very complete patterns, it is still a tool that needs a human mind to utilize. I think that large organizations may get over-excited at the prospect of a design system because they think it will remove all their UX problems in one fell swoop, or allow their engineers to be the designers. Nope. Here, I think we did the best job we could to delicately set proper expectations so that the incredible value of the design system was maintained while also encouraging the in-house design organization to keep growing.
Design systems are fun! Knowing more about how it all works will make it even better the next time around.