Published: Sep 14, 2010
A design library is a collection of guidelines & standards that describe a design system and maybe template assets to go with it. Creating a library for an experience of any scale is no trivial matter. It's not like you open up a code editor, chop things up, throw a ZIP file to some marketer and say "Here you go. Enjoy!" You've got to have a plan.
So, let's assume you've done due diligence: your design system is stable and mature, and you've answered all the right questions to justify the effort. You are ready to get started.
The process of creating a library involves many different activities across four sequential phases:
Once you've broken down the plan into four chunks, it's easier to zero conversation in on specifics: individual activities that may be obvious (documenting guidelines) and what's not (oh, yeah, you're right, I need a communications plan!).
The Creating a UX Design Library diagram (downloadable as a tabloid-sized PDF resizable for poster printing) illuminates all of these activities and relationships, and even provides useful rationales for key parts.
With this scaffolding in place, you can establish an approach and also drill into who's involved, how long it lasts, and how much it'll cost.
Every library is supported by a librarian (sometimes, two) that coordinates activities, leads meetings, engages others, and does a lot of the dirty work. Depending on scale, the librarian may be augmented by one or more contributors to create assets (HTML, Wireframes, Comps), guidelines, training materials, and helpful tools (like a copy deck).
However, you can't build a library in a vacuum. Depending on your objectives, inputs may come from a few or from seemingly everyone: product management, engineering, training, design technologists, writers, other designers on your team, vendors, and on and on. These folks are probably prime candidates to consume the library too, whether to understand how it works or get their hands dirty and actually use it.
The time it takes to build a library varies but is usually measured in months. Typical projects that transform an existing, stable design system into reusable design assets for wireframing and comps takes 2-3 months. Setting up a deeper library of code, a moderate amount of guidelines, and web-based platform for documentation & collaboration expands a timeline to 3-6 months or longer.
The three primary dials that tune how long it takes to assemble a library are:
Cost is always a tough nut to crack, and you often don't know the precise cost until you even complete a first cycle. That said, you can guide discussions of cost using three questions: how big is it, what's most important (such as HTML/CSS assets over Comp assets), and what hidden costs does the sponsor not value or understand?
The more you plan and organize at the beginning, the more you don't waste time and effort later on. Getting the library's plan and organization correct is crucial. So don't avoid investing in solving the very influential impacts around how you are going to roll it out and what you build when. Get organized first. Don't just dive in!
However, the most important spending you need to plan for isn't even the build itself. Libraries evolve, and looking at the effort like it's a one-and-done investment is foolhardy. Instead, you must also be ready to align interests, funds, and allocated people to administer and version a library over time too.
Every conversation with Nathan is eye opening and amazing. That's why we eagerly agreed to work with him again on a new virtual seminar, Start Full Screen: Organize, Communicate, & Annotate HTML Prototypes. We loved Nathan's thought process around libraries, and we're sure his thinking on HTML prototypes will be enlightening.
As always, I want to hear your thoughts on this topic. Join the discussion about this week's topic on UIE's Brain Sparks blog
Read related articles: