It’s not that I was dreading writing an article about creating a UI standards library, it’s that I wasn’t sure where to start. It’s a big topic that spans years of effort on my part and the part of my colleagues. While I was beginning to outline some of the critical points I wanted to cover, I came across an article on Boxes and Arrows website that is an excerpt from Nathan Curtis’s 2009 book Module Web Design. In it he lists and defines the questions that an organization should ask before endeavoring to create a UX-related library. It is essentially a summarized version of the same one-question-at-a-time process that was used to help my organization build our existing standards library so I thought it made sense to follow his lead.
He starts by asking “Why Do You Want to Create a Library?” What seems like a very obvious question with what might seem like a very obvious answer it should actually be given a healthy dose of consideration. Creating a library is not a trivial undertaking, so ensuring that the goal of the library is clearly defined is imperative. The answer to this question will be the catalyst for creating the foundation of the library itself. But I do think that in most cases, even in small organizations, it’s a very good idea to have a library that provides in the very least a centralized location that every interested person can have visibility to.
So, the first question was a no-brainer. For our very large enterprise we were doing ourselves a disservice by not having an authoritative repository of UI standards. I think that it’s a great idea in and of itself but it was necessary in helping to address a fundamental goal in our IS department of providing our users a seamless experience. Without centrally published standards and well defined unilateral approach I don’t see how our organization—with dozens of independent applications spanning several business disciplines—would ever meet this goal. Because of this we had already successfully answered the other questions Curtis poses regarding business stakeholder and design team buy-in. Our enterprise is enormous so in our minds there was no question that a library was necessary to the success of meeting our goals.
Once we had solidified our goal and determined that creating the library was a worthwhile endeavor we began the arduous task of building the information architecture, layout, and overall presentation the library would need to successfully communicate the vast amount information that would finally be published.
Curtis mentions at least two fundamental types of libraries, one for components and one for patterns. Although he seems to treat them as mutually exclusive entities, which is something that I don’t quite agree with, the overarching question gets at the heart of the most fundamental question: “are you building the right kind of library?” Indeed. And while this question is valid as is, for our needs I think that a more appropriate question is “are we building an effective library?” To me the distinction between pattern and components is insignificant. The guts are more important.
To begin answering the question “are we building an effective library” we had to keep in mind our original goal: providing our enterprise a seamless user experience. We knew that eventually the library would include both components and patterns but I didn’t think that we needed to worry too much about the difference between them. What mattered was capturing the right level of detail. So, we asked ourselves, what is it that our teams need from this thing? As it turns out what they really wanted most were working examples. If we couldn’t provide a working example then a picture would do. The old adage of a picture is worth a thousand words was never truer. So, we focused on the solutions first.
Luckily we weren’t starting entirely from scratch. Over the preceding months I had been working with our designers to create a master feature list of components, patterns and other UI behaviors they thought were critical for creating enterprise-scale applications. If you don’t have a list already worked up, this is the most logical place to start. It may take time, but it’s the best way to articulate the need and value of each item which in turn will help you determine what to work on first. Eventually, we had a list of about 60 items. The items were mostly components as opposed to strictly patterns or behaviors, so it seemed reasonable—at least for the first version—that the library be tailored to describing the proper use and implementation of components.
Working with a small team I began creating the structure and content of the library. To get a good idea of category names I created and conducted a card sorting exercise sending it out to a group consisting of business analysts, business experts, developers, and other UI designers. The feedback that I received allowed me to create the initial categories.
- Form Controls & User Input
- Data Management & Display
- Page Layout & Organization
- Messaging & Feedback
We then set out to determine the level of information that would be appropriate for the same diverse audience that had taken the survey. In the very least we determined that we needed to include an overview and a working example (or sample image) of each standard.
The library needed to cover the following:
- Name of the standard
- Description of the standard
- Problem the standard is meant to solve
- List of appropriate and inappropriate use
- Best practices
- Example of what it looks like
If you’re a smarty-pants:
- As many working examples of the standard that seem necessary
- The ability for developers to see the mark-up that created the solution
If you are able to provide a working example and display the mark-up you will provide a huge service to your teams. This is the most looked at information in our library and it normally takes the least amount of time to create! In fact, if you are short on time starting with providing a working example with code and implementation details is enough. The other content (description, problem, when to use) is important but since our teams include a UI designer who was involved in the creation of the master feature list, the team can have the designer fill in the blanks until the remaining content gets created and published.
Curtis asks two important questions regarding buy-in, “is your organization ready for a library?” and “is management ready to support a library?” These are about selling the idea that having a library is better for everyone than not having one. Working up your pitch, as Curtis mentions, is important. I don’t fancy myself much of a salesman but I am passionate about UX design. I normally tell the skeptics in my office that this is our way of meeting the goal of creating a seamless user experience. This usually shuts them up. Although we experienced some resistance from several business stakeholders who saw us as more of a hindrance than a help, the support that we received from upper management was critical to our success.
We were given the time required to create a fully realized, albeit first version of a UI standards library. This was the best sales tool we could ask for. You can talk all you want about how great a Porsche is, but no one wants to hear about a Porsche. They want to see it, feel it, and most of all drive it. This is no different with a UI library. It needs to bring immediate value and this is most easily achieved with something that works and can be taken for a spin. A Porsche with no engine is only interesting to a point. I’m harping on this point for a reason. In my experience, just having a library that talks about standards is not compelling enough to gain favor from your intended audience.
And just like the Porsche, not only should the library offer working examples and something immediately usable, but it should look good. The library itself ought to be a place that people will want to see because it looks and functions great as well as offers a great service. I used our existing application branding assets and relied on our front-end technology package to provide the right amount of look and feel. It’s important to maintain the same style or at least the spirit of the style that the library is proposing. In other words, practice what you preach and eat your own dog food. There are some aspects of the library that don’t fully conform to its own content but we maintain the general spirit of the standards.
Enough babbling for now. Let’s take a look at some examples.
Show and tell
Curtis has a terrific diagram that shows what goes into creating a design library. I suggest taking a look at this and reading the article that I reference in this post.
In the meantime, here are some images of the library that I helped create. I think they provide the best means of describing what I have spent so much time on these past few years. I would be remiss if I didn’t provide some examples!
Left-side navigation menu
Each category expands to display each standard entry. A star indicates that the standard has changed or is new since the last version. A tool-tip gives more details about the specific changes.
Each standard shares the same set of sections broken up into a tab set. The last two tabs Performance Data and Audit Checklist support our own unique development process and are not required for a typical library. (click to view full page example)