Design Toolkits are an extension of a design system. It takes what is expressed in the system and creates a library of assets and detailed guidance to help teams turn that system into real world comps and prototypes quickly. The process I recommend to clients and co-workers ends up using many of the concepts from Atomic Design theory.
I’ve created several of these for different teams with varying degrees of interactivity, typically it involves most of the following steps and pieces. Some have been pdfs or other static documents, others have been living style guides, normally contained on a website. Because many of these contain pieces that are covered under NDA I've created scrubbed graphics and will speak to the process of creating toolkits I've used.
Component Library
One of the early steps in creating a design system for an enterprise level client involves auditing what components are already at play in a company’s design ecosystem. This involves a fair amount of intra-company comparative analysis. At the most basic level it involves asking questions like this: “It looks like this group’s button is blue with a beveled edge, and ours is green and flat. Which of these more closely aligns to the design system that has been set up?”
Once the “as-is” state of the components has been determined I move on to the “to-be.” This will involve answering questions like “How much of what exists do we keep?” “Which version of a particular component is best?” “What components did we not see that we need to create?” Going through this exercise provides you with your basic building blocks that you’ll be creating and codifying, it then becomes a matter of prioritizing the components. In the event the team I was working with was starting from nothing we could skip straight to this point in the process.
Design exploration on the most basic elements happens now, and this is the point where questions like “Is this a delightful micro-interaction?” “Is this ADA compliant?” “Does this work on phone and desktop? What about TV?” “What does our type ramp need to be?”
Once the components are designed and agreed to by the team and stakeholders I take them and “operationalize” them in the program that we are using to create mockups and wireframes. I tend to lean towards programs that have symbol functionality (meaning we can change the component in one place and it will affect the entire document) and some amount of interactive ability, so that we can easily show stakeholders and test participants a more real prototype without having to put weeks of work into it. Programs like InDesign, Sketch or similar are typically good places to start, but a key factor is always “What program is the team using and can people quickly come up to speed on?”
A component library will also typically have specifications added at some point, usually after page patterns are determined. The goal here is to create documentation so that both designers and developers know how to build pages and flows. Sometimes these specs are part of the source file other times they are part of an interactive style guide website or portal.
Page Patterns
Once components have been determined toolkits have benefit from standard page pattern explorations. Many products I’ve worked on have similar page pattern types. For example, search results, product landing page, home pages, and account history pages. The goal here isn’t to create every page a team will ever need, but to get the basics covered.
Using the components created the exploration of how the pieces fit together begins. Questions like “How do we want to treat hero shots?” “How far should buttons and form fields be from each other?” “How do we group together form fields to make a block of text?” “What if someone views this page on their TV?” A similar design exploration phase to the components happens here, sometimes concurrently with the component discovery phase.
A simplified Product Detail Page on desktop using predefined components.
Phone view of the same page, using the same components.
Refine and Iterate
One of the most important aspects of creating a design toolkit is to define what the minimum viable product is. Today’s design tools are quite powerful and can give a lot of options for creating prototype. However, not every user on a toolkit is an advanced feature user, and even those that are sometimes don’t end up needing some of the power user tools that the programs provide. There have been several projects I’ve worked on where we created something really cool that didn’t end up getting used in the day to day world of designing. Much like any UX project user observation becomes key here, asking co-workers “What works for you?” “What do you wish it did?” provides direction for future releases.
Why do create a design toolkit?
There are a lot of reasons to go through this process for your team or company, but the three main ones I’ve found are the following:
Critique the Right Things
An important part of the design process is the ever-present critique. Having a design toolkit (especially with specifications for the components and page patterns) helps focus the conversation on the big ideas that are being explored like “Does this flow work?” instead of smaller, but still important, questions like “Should that button be 2 columns wide or 3 columns?” Good critique meetings are powerful tools to help good design teams become great design teams.
Fair warning: Sometimes you’ll find a hole in your design toolkit in critique meetings, always be ready for that.
Faster Prototypes and Mockups
In the agile, rapid prototype world that design now inhabits being able to show business stakeholders something quickly becomes more important than ever. Earlier I mentioned building basic interactivity into buttons, even little steps like that can help sell an experience to non-practitioners.
Faster prototypes also help you get better data from usability studies. Using a toolkit I created, myself and a researcher put together a prototype in a few days and then put it in front of our users. Because the interactions were built into the components already, we built something that felt real in the same amount of time as static comps. Since we had a real feeling prototype we could determine that we had cut the time on a particular task from 90 minutes down to less than 15 minutes.
Quicker Redlines and Specifications
Creating specifications so that development partners can build what has been designed has rarely been at the top of the list of “fun tasks”, but it is important. A design toolkit that has the components specified on an interactive site can save time in the creation of these final documents. Instead of having to spec every component like this:
You can take a lighter approach in final documents closer to this:
A team can point development partners to the master site or guide (which sometimes in more advanced toolkits even have code snippets) so that they have a single source of truth. If a component gets updated it only needs to be changed on the site, rather than all the redline documents in the pipeline.
