Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

How to Create a UX Design Library

by Nathan Curtis
on September 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.

What is the process?

The process of creating a library involves many different activities
across four sequential phases:

  • Analyze: understanding what it is, how it fits into your process,
    and what it’ll contain
  • Assemble: building it, including documentation, template assets, and
    how you’ll publish them
  • Adopt: communicating and getting everyone onboard
  • Adapt: administering & evolving it over time, through successive
    releases

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!).

BBC A-Z index

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.

Who is involved?

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.

How long does it take?

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:

  • Scale: How many items are you formalizing and documenting?
    Creating a library of 10 items is far easier than a rich repository
    of over 500 variations.
  • Design Asset Variation: It takes far less time to create a
    library of wireframe assets than to source, organize, and normalize
    PSD comp starting points. While “perfect” code is produced for
    projects, getting it into repositories and modularized for long term
    sustainability is more complex.
  • Documentation Level of Detail: The bigger the organization, the
    bigger investment you’ll need to make in preparing guidelines and
    instructional material to help them learn and use the system
    independently.

How much does it cost?

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.

Hear more from Nathan

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.

And as a bonus, when you register for the virtual seminar, you’ll get
EightShapes’ CSS & JavaScript library along with a sample HTML
prototype that demonstrates all the concepts covered.

Share Your Thoughts with Us

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

About the Author

Nathan Curtis has been involved in UX since 1996, when he started focusing his creative energies on IA, ID, usability, and front-end development. He’s also an entrepreneur at heart, having founded the renowned EightShapes in Washington, DC. You can follow Nathan on Twitter at @nathanacurtis.