Design System
Role: Design Lead
Introduction
There's something to be said for ignorance.
If I had known, when I started, how hard this project would be I'm not sure I would have decided to do it. Knowing what I know now, that whole departments and crews of people create, maintain, and evolve design systems, I don't know if I would have started with myself, a fellow coworker, and my boss's cautious go-ahead. I think, on some level, I had an inkling of how difficult it would be, but the challenge seemed too interesting and exciting to pass on.
The main problem was one I'm sure many companies have: we had many different designers across many different departments and each used their own methods, graphics, and layouts to accomplish their goals. Even within our own department, we each did the same things slightly differently, which in the small-scale isn't that big of a deal. But over time and at scale, these small differences accrue into really big discrepancies. As is often the case, small UX problems can get passed around, and then there's lots of big, entrenched UX problems. Our site looked like what it was: each section designed by each designer, with very little overlap in process, aesthetics, or structure.
The effect was that our site kinda sorta followed some basic guidelines, but user's couldn't rely on any learned methods or procedures to accomplish tasks. Everything was different, and ultimately, frustrating. Why does one button do this but the same one on a different page does something else? It was hard to learn, hard to use, and generally annoying.
I set out to audit, design, and then codify a process on how to think, make, and style our digital products.
Research
This was the result of many, many page audits. I looked for common elements we currently used, adding one's we needed for the future.
The design system was a collection of elements, but it also serves as an educational tool. I wrote a brief UX explainer at the top of every section.
To stay on track, I wrote and rewrote our design philosophy. How do we approach things? What should we consider, beyond the page contents?
This was the result of many, many page audits. I looked for common elements we currently used, adding one's we needed for the future.
From my academic background, research is one of my strengths. I relied on that skill heavily throughout this phase. My initial research started with a competitive audit, looking at maybe 15-20 different design systems. I was searching for common elements as well as approaches on how to persuasively present information. Chances are if there's a design system article that's in any way decent, I've read it. That is not an exaggeration or hyperbole. My initial research phase was approximately 3 months, and from that research I created a few things.
First, I gathered a list of items we would want in our design system. Bootstrap was a useful guide here, as I (rightfully) assumed we would be using it for our final codebase. I catalogued each element in Axure, adding in any company and website specific interactions we wanted to continue.
Next, I tackled each element individually, thinking through each specific interaction on a granular level. What's the best way to show a date in a date picker? What type of iconography would work equally well in a carousel as well as a top-level navigation? Through this process, I was able to learn dependencies between and across elements, as well as starting to arrange disparate pieces together into a cohesive whole. For example, modals and cards can use and contain lots of different elements. A button, icon, and header need to work between elements, as well as internally within the element itself.
Finally, I wrote a design philosophy. How should users feel when they use our site? Why are we even doing this? What problems does a design system solve, and is it even worth our time, effort, and money? How do we get people to buy in, understand, and then adopt and use our design system?
This is a big change; how do I persuade folks it's worthwhile?
Presentation
An important part of the presentation was to educate, to give people a solid concept to understand before moving to specifics/complexity.
This is a crucial slide, offering the value proposition from the business perspective.
The goal here is to show how instead of limiting, the design system is actually a moment for cohesion and creativity.
An important part of the presentation was to educate, to give people a solid concept to understand before moving to specifics/complexity.
For such a wide-reaching project, stakeholder buy-in from almost every department was necessary. We started internally, working out our pitch, adding and subtracting slides as needed. Some groups cared about implementation; others about how it fit with their current way of working. We presented to every level within the organization, from a small group of front-end developers all the way up to the head of the entire division.
I tailored each message to that specific group, speaking to their concerns and answering their specific questions. I often view design this way. Every game I play is an away game. I have to meet my user's where they are, understand them, and then figure out a way to address their needs.
Visual Design, Testing
As part of our presentation, we showed an Adobe XD file modeling what a future, comprehensive website might look like. We performed user surveys and interviews. We iterated constantly. If I had to ballpark how many medium to full iterations I did, I'd probably put that number around 15-20, all based on user feedback.
The system was interlocked, so a change to a button impacted a great many places. But that's the value of a mockup and the immense value in testing. An hour change on my end saves countless development hours.
I continued stress testing the design system for about six months on real-world projects, tweaking and making now minor adjustments as we went. The design system is currently developed and in use. It works really well.
The final product is a website, where users can toggle the view of individual elements between designer and developer views. Designers can pull specifications; developers can pull code snippets. All it took was about 18 months of constant work from not only myself, but a great, collaborative team of advisors, designers, and developers.