So You Wanna Build a Library, Eh?

by:   |  Posted on

Modular Web Design book coverThe following article is an abridged version of Chapter 7 of Nathan Curtis’s 2009 book, Modular Web Design published by New Riders. The book’s first half addresses how to modularly break down your design, build it back up, and communicate in new and interesting ways. With those design techniques in hand, the book then drills into how to organize and build a library, teach it to others, and establish a process for maintaining it for an organization.

Legos are so freakin' awesome!!! Design patterns and modular components are effective techniques for designing and building long-lasting, consistent experiences. You may reach the point where you ask yourself “Is it time to build a library for our team?”

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial. It takes time and effort to get off the ground, can trigger significant and uncomfortable organizational change, and comes with an ongoing maintenance cost. In some cases, libraries are not the answer and yes, sometimes libraries fail. Nobody wants to invest the time, effort, and personal capital only to have nothing to show for it.

Therefore, precede any kind of library build out with a period of discernment. Before you dive, ask yourself and your teammates the following eight questions to gauge whether a library is right for you.

1. Why Do You Want Create a Library?

What is your primary rationale for building a library? What motivates you?
At the top of nearly everyone’s list is usually one of two benefits: efficiency or consistency. Some value speed through reuse: get design done faster, be more productive, save time, save money! Others see opportunities for governance and consistency, using the library as a baseline to sustain a design system over time.

Many teams have realized incredible efficiencies, savings, and better design through design libraries and related standards. However, building a library isn’t trivial.

Beyond efficiency and consistency, other benefits that drive teams include:

Memory: A destination to record and refer to all the design decisions made in creating a large-scale experience.

Portability: Designers come and go. Project priorities change. A library should make you more nimble in shifting resourcing and focus.

Vocabulary: Establish and promote common understanding that includes terms you use for items, page types, and even deliverables.

Authority: Provide a more credible resource on which to make design decisions, prioritize efforts, and easily refer to conventions.

Predictability: Have a foundation to discuss and more closely approximate the impact of a design decision.

Collaboration: Amp up collaboration in your organization to trigger conversations, share knowledge, and learn together.

2. Are You Building the Right Kind of Library?

When it comes to libraries, teams usually find themselves choosing between a library of patterns or components.

A design pattern is a solution to a recurring problem. Patterns offer principles to follow and avoid specifics like style, editorial guidelines, page location, and finalized code. Libraries of design patterns are ideal for teams that design many experiences, such as Yahoo’s team that designs products with unique visual systems that adhere to a larger, common brand.

A component is a chunk of a page design. Experiences can reuse components for navigation (such as header, footer, and local nav), content (such as video players and page titles), and more. A component library is ideal for organizations that have built a system of modular HTML and CSS, and these teams can complement the code library with a collection of reusable design assets for wireframes or comps.

Choosing between patterns and components may not be an either / or question. In fact, one team built libraries for both patterns (for example, Tabs) as well as components (for example, tabbed product details, tabbed content module, tabbed search results, and so on). Other teams have hedged their bets by embedding aspects of one approach into the guidelines and spirit of the other, most commonly via pattern-like guidelines incorporated into the more specific component definitions.

Consider a pattern library if your team has:

  • Many design systems that are intentionally different or will not be reconciled into a single component library.
  • Capability to document patterns more specific than public libraries like Yahoo Design Patterns,, and
  • Known opposition to prescriptive approaches, but a willingness to use common guidelines.

Consider a component library if your team has:

  • A specific visual design system, including grid(s), layout, color palettes and typography.
  • Many reusable components (page “chunks”) within that system.
  • Diverse groups across an organization that must work together using that system.
  • Interest in and capability of sustaining that design and code system across groups, projects and time.
  • Strong, centralized influence to create, deploy, and maintain a library (or plans to centralize influence via a library).
A comprehensive library of design standards doesn’t end with design patterns and modular components. A team could consider … include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

Finally, a comprehensive library of design standards doesn’t end with design patterns and modular components. Instead, a team could consider expanding their repertoire to include the design frameworks espoused by Robert Hoekman as well as common standards like page types/templates, editorial standards, a style guide, and more.

3. Is Your Experience Ready for a Library?

Ok, so you’ve got dreams of efficiencies, consistency, standards, and more. However, just because you’ve built a website, that doesn’t automatically imply that you should build a library. In fact, there are plenty of websites for which a library won’t net any benefit. You should take a long, hard look at your design system to ensure it warrants a library.

Scale: Libraries can be invaluable to large, distributed teams supporting many products or a site with thousands – or millions – of pages. On the other hand, if you are a small and tight-knit team constantly communicating across cube walls, then there’s no need to codify standards. Heck, there’s no need to document anything at all – just get real and build stuff.

Relevance: Rarely do experiences of any scale contain no reusable elements. However, some site areas – like an e-commerce checkout or an account management portal – may be unique, built once, and not duplicated again short of a redesign. Why standardize something that’s never reused?

Stability: Be careful not to standardize an experience too soon. A design system should stabilize before you invest in codifying layouts, grids, typography, patterns, and components.

Disparity: Instead of one simple set of grids, styles, and reusable chunks, you may have multiple, distinct design systems. Do you merge them into one library? If now, is it worth it to create distinct and potentially overlapping libraries?

4. Is Someone Ready to be a Librarian?

Just because you’ve built a website, that doesn’t automatically imply that you should build a library.

Building and sustaining a component library takes an evangelizing advocate. That person may be you, or someone you manage or work with. Almost always, the librarian wears many hats:

Leader: You’ll promote a new way of thinking, shepherding participants into common practice and evangelizing the techniques, benefits, and spirit of the library.

Target: You’ll be a lightning rod for the library, and even the cause of controversy in a design organization. Others may point to you as the standards police that constrains them from being creative.

Writer: You’ll be an author, or at least a contributor and reviewer of other’s contributions, for items like guidelines, library cheat sheets, and blog posts.

Teacher: You’ll teach principles and basic fundamentals about what’s where and how to use it. Help requests can be disruptive, and you’ll have to be patient, determined, and flexible.

5. Is Your Design Team Ready for a Library?

A library can transform how a team operates. Gone are the days where every project is a blank canvas where a designer creates a creative and original work of art. Instead, designers are equipped with helpful starting points as a framework in which to operate. Those constraints can be simultaneously welcome and controversial.

Above all, your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel. Templates with grids, libraries, styles, and pre-made page chunks don’t turn designers into robotic automatons. But designers often react that way. You’ll have to convince designers that library starting points can focus creativity.

Other team attributes that influence library readiness include:

Size: How big is your design team? The larger the team, the more likely techniques, styles and deliverables vary. Libraries and templates can get your team synched up and communicating more consistently.

Overlap: How much do designs contain overlapping patterns and components? If your team is designing towards a common experience, a library can be a key part of a holistic strategy.

Distribution: Is your team spread out geographically? Standard design assets can mitigate impacts of reduced face-to-face collaboration.

Adaptability: Will your team be able to adapt to design practices that involve a library?

Stability: How stable is your team? Do designers come and go often? Learning library details is an investment with a return that increases the longer each designer uses it.

Advocacy: Do you have team members that are jazzed about or knowledgeable of reuse? Are they willing to be partners or champions?

6. Is Your Organization Ready for a Library?

Your team will have to overcome the misconception that a library is about constraining innovation. You want to – you need to – stop reinventing the wheel.

You’ll need to have a pitch that explains the library in simple and concrete terms. What is it? How does it work? What does it mean to me? These questions hint at the profound impacts a library can have:

Workflow: Design libraries impact at least two critical workflows: how you produce a solution for each project and how you maintain assets, guidelines, and documentation across projects.

Collaboration: Do key team members – such as engineers and designers – have a common foundation to communicate on?

Documentation: You got to make it easy for people to refer to, find, learn, and integrate reusable assets into their own practices, whether via a component ID annotation on a wireframe, a PDF’s link to online documentation, or consistent HTML comments in your code.

Timing: When change is in the air, there may be opportunity to insert a library into the discussion and approach. Can you time the expansion of your library to dovetail with when your experience are already undergoing significant change?

7. Is Management Ready to Support a Library?

None of your planning and efforts will matter if you lack management support. They must vocalize a public belief in your effort as well as pony up time, money, and resources. It’s your duty to communicate a plan – and the return on that investment – to sell your management on why a library matters.

Unfortunately, even when the library is otherwise a good idea, management support sometimes wavers in instances like:

Lack of Priority: It can happen to the best of teams. You get your top talent together, you start roughing out a framework, and then projects hit. You get distracted. It’s up to management to carve out sufficient time for you, or else the library becomes stale and ineffective.

Insufficient Hardware and Software: It’s up to managers to ensure that designers have the right hardware and software installed so they can use the design assets. My confusion turned into empathy when I sat at a designer’s desk and watched for TEN MINUTES as the software tool launched on his out-of-date laptop. My query of “This is unacceptable. Haven’t you asked for an update?” was met with “You can only ask so many times” and a shrug.

Leadership and Evangelism: Ensure management is on message. Prep them with simple ways to communicate library value and help them avoid undermining you with explanations like “the library is another good idea, but if it doesn’t work for you, shouldn’t disrupt your own personal approach if you feel your way is more effective.”

Background Support: Public declarations are important, but so are the back-channel efforts. Your managers need to open doors to connect you with key players and partners. Knowing what doors to open is a two-way street, so help your managers understand the obstacles and why you need help.

8. So, Are You Really Ready to Build a Library?

Take a deep breath, because you’ve got a fun ride ahead.

So, your design system is stable, you’ve got some champions backing you up, and you know just what your organization needs. You are ready to put yourself on the line. You believe.

Then take a deep breath, because you’ve got a fun ride ahead.

Creating a UX library diagram
Diagram of How to Create a UX Design Library (PDF)

Up next, you’ll want craft a plan and read all you can from all the best authors and online resources. You then discover, organize, and prioritize what goes in your library. You’ll setup a platform for managing your catalog and publishing your standards. You may even equip one or more software tools with a library of reusable assets so that your team can create better design and deliverables, faster.

It’s time to build a library.

Know Your Place

by:   |  Posted on
“As IAs, it is important that we grow our capabilities to communicate more complex structures and interactions so that colleagues can comprehend, visualize, and ultimately build the experiences we envision.”

Web standards, browser support, and continued creativity are resulting in increasingly sophisticated web-based experiences. As information architects (IAs), it is important that we grow our capabilities to communicate more complex structures and interactions so that colleagues can comprehend, visualize, and ultimately build the experiences we envision.

As such, conversations about how to evolve our tried-and-true approach of wireframing are rampant. Some argue eloquently that we should move away from wireframing altogether and instead prototype a living, functionally evolving target experience (such as Garret Dimon’s “AJAX & DOM Scripting: Just Build It”). That’s also the direction espoused recently in “Getting Real” by 37signals. Others have demonstrated techniques to enrich wireframes by simulating in-page interactions via interactive storyboards (such as Bill Scott’s “Storyboarding Rich Internet Applications with Visio”).

However, IAs may be unable (lacking technical know-how) or unwilling (because of time, culture, or other constraints) to illustrate design solutions with such technically demanding methods. So, in keeping it old school, many will continue to focus on improving wireframing techniques. One improvement is to illustrate and document a design’s modular framework via efficient reuse of a similarly modular set of artifacts.

Tired of cutting and pasting the same page module throughout a myriad of different wireframes? Even more frustrated when, late in the design cycle, it turns out that you need another tab or link in that header that you’ve already cut and paste into 22 wireframes? Ever wondered how you can improve your spec documents to generalize elements repeated across pages by using the same artwork that you’ve used in your wireframes? Do you reuse and centralize the storage of varied design artifacts throughout your process?

Front-end developers have long used “includes,” which are HTML markup snippets that are abstracted from a single page and reused across an entire site via a single code source. Similarly, site styles can be abstracted into linked cascading style sheet files shared by all pages in a site.

Our commonly used wireframing tools, such as Adobe Illustrator and Microsoft Visio, enable us to approach our challenges in illustrating and documenting our UI design within artifacts in a similar, scalable way.

Views and modules
Regardless of what stage of the design process you are in, at some point you’ll begin wireframing one or more views (commonly, web pages) to represent a structured display in a specific, static context.

In all but the most small-scale design processes, modules begin to emerge that are repeated across different views or variations of the same view. A module is an element or meaningful group of elements on a page that, while possibly static and unchanging, typically varies in presentation based on dynamically populated data, display conditions defined by business rules, and changes in state triggered by events and interactions.

Initially, perhaps it’s just a header that contains a tab set and text indicating “You are logged in as John Doe (Log Out).” But eventually, numerous views (or variations of the same view) reuse more and more modules, even if those modules vary only subtly in different scenarios. Common examples of modules include:

  • A product item displayed in search results may be on sale, out-of-stock, also available via auction, or without a thumbnail image
  • A hierarchical tree view or navigation list, such as a structure that includes expandable/collapsible items for Inbox, Sent Items, Trash, and more
  • A context-sensitive bar for common actions like Add, Copy, and Delete
  • An article list, such as a link set generated by an RSS feed

Modules can be far more page- and context-specific (and less like a reusable design pattern), particularly if a single context warrants illustrating a range of instances, such as:

  • A configuration tool for a wireless rate plan that varies based on audience, active promotions, expanded and collapsed elements, and more
  • Shipping method (e.g. overnight) and destination (address) that varies based on prefilled customer options, customized corporate-specific displays, types of items in the order, etc.

If a module is used in more than one illustration, then abstract and manage it in its own file. Once abstracted, you can reuse it in other deliverables such as views, flows, or specs as necessary. For example, if you have a header that’s used in two views, then cut and paste the header into a separate file and place that file in every view that contains a header.

Cut each module from the view and paste it into a new, separate file

Tip: If saving artwork in Adobe Illustrator with the intent to include it in a different file, then ensure you check Create PDF Compatible File in the Illustrator Options dialog during the Save process. That way, not only will the artwork be visible in the document within which you include it, but you can also subsequently view that Illustrator file in various versions of Adobe Acrobat, including the free Adobe Acrobat Reader.

Placing artwork
Inserting a module from a separate file into an illustration can be accomplished via the following commands:

Adobe Illustrator CS2

  • Click File > Place
  • Browse and find the separate .ai file in which you’ve stored the artwork to place
  • Check Link so that the artwork will be linked to the file and subsequent changes to that file will be reflected in this document
  • In the subsequent Place PDF dialog, select Crop to Art and click the OK button.

Note that when you place Illustrator artwork in a separate file, artwork outside the file’s Artboard boundary will not be visible once placed.

Microsoft Visio 2003

  • Click Insert > Object…
  • Select Create From File to toggle the dialog to enable file selection
  • Browse and find the separate .vsd file within which you’ve stored the artwork
  • Check Link to File so that the artwork will be linked to the file and subsequent changes to that file will be reflected in this document
  • Click the OK button

Microsoft Visio’s Insert Object dialog

By following these commands, you should now see the artwork from the included file as an object. You can move, resize, crop, and even edit the module from within the current document. However, since the artwork is linked, the module remains independent and can be reused across other documents. As you change and extend the module over time, updates will propagate automatically to every other document that links to it.

Embracing modularization
Numerous capabilities arise through a modular file approach:

  • Change once and have updates propagate everywhere
  • Nest relationships of modules within each view (and view variation), modules within modules within views, modules within views within flows, etc.
  • Abstract design elements progressively as each module emerges, solidifies, and extends
  • Reuse and share between designers and across projects

Additionally, nomenclature you establish during this process can permeate the team’s discussions and downstream development efforts. Take the advice of Christina Wodkte and Nate Koechley, who point out “If you’re making up a name, make it something we can all use.” Your modular concepts could align with CSS naming conventions, influence the markup, and even suggest core objects built during the development of client-side scripting.

But a module’s usefulness is not limited to reusing a single representation. Within the file, you can create multiple variations of a display, apart from the representation or scenario where the module initially emerged.

Good variations
Module variations are critical in comprehensively depicting behaviors, state, dynamic data, and conditional displays during wireframing.

For example, consider a mini-shopping cart displayed in many views of a shopping experience. Over time, teammates will need clarity on how the mini-cart appears in different states:

  • Empty
  • Contains 1 item
  • Contains 2+ items
  • Transitions when updated in real-time via an interaction to add an item to the cart from elsewhere in the view (without a refresh)
  • Transitions when an item is interactively removed (without a refresh)

A grid of module variations based on display conditions and interactions

The module’s file is an ideal, consolidated location to store and evolve these variations. Within this file, you can quickly illustrate many variations in concert and manage those illustrations simultaneously.

This process frequently yields a grid of variations and enables visualization of patterns and differences across data, display rules, and state. With the consolidated display, teammates can more broadly understand how context influences the flexibility and scalability of the module’s elements. Additionally, if you need to update the module (whether to add a variation, update an element, or even modify copy), you have a single source.

Harvesting your crop
With module variations prepared, you can more quickly prepare many example views and flows. But, as you place a module file into each view, you now have an illustrated grid of instances instead of just one representation. Therefore, you must crop the placed artwork to show only the variation applicable to that view’s context.

Adobe Illustrator CS2
There are many techniques for cropping artwork in Illustrator, including:

1. Create a clipping mask
Regardless of how variations are arranged within a module’s file, you can use a clipping mask to hide all but the variation of interest:

  • Create a path (such as a rectangle with a stroke color but no fill color) surrounding the variation of interest and above the placed artwork
  • Select the path and placed artwork simultaneously
  • Select Object > Clipping Mask > Make (or CTRL-7)
  • Use the Selection tool to arrange the cropped illustration within the view or flow

2. Placement options
If a variation is at the artwork’s edge or corner, avoid the potential maintenance issues of a clipping mask and instead use the Placement Options dialog:

  • Select the placed artwork
  • Click on the artwork’s filename in the Control Palette (displayed via Window > Control Palette), and click on Placement Options in the resulting menu
  • Select to preserve: File Dimensions, select the corner or edge of the variation in the Alignment grid, and check Clip to Bounding Box
  • Click the OK button
  • Drag object handles to hide portions of the placed artwork except the variation of interest
  • Use the Selection tool to arrange the cropped illustration within the view or flow

Microsoft Visio 2003

  • Select the placed artwork
  • Click the Crop tool (if the Picture toolbar is not visible, select View > Toolbars > Picture, which will display the toolbar that includes the Crop tool), or click CTRL-SHIFT-2
  • Drag a selection handle to hide portions of the placed artwork except the variation of interest
  • Select the Pointer tool (or click CTRL-1) to arrange the cropped illustration within your broader view or flow

Cropping or masking a grid to show only the variation of interest

Tip: Module, view, and flow placement is supported by your design tool’s related product for creating documentation, such as Microsoft Word (for Visio-based artwork) or Adobe InDesign CS2 (for Illustrator-based artwork).

Spec and flow
Although boxes and arrows may be sufficient to illustrate a sequential experience path, flows that directly incorporate wireframes result in a far more engaging understanding of an experience. With variations of each view in your path (each built upon module variations), you are better positioned to efficiently construct numerous flows. Such storyboards are more compelling and accessible, relative to your audience’s cognitive struggle to map boxes and arrows to wireframes, relate decision points and business rules, and construct the experience in their mind’s eye.

As the design matures, many reach a point where the design must be annotated or thoroughly documented. The existing abstraction and relationships you’ve built significantly ease the documentation process; in fact, a modular structure should directly suggest a design’s decomposition into specification. You can consolidate your modular artifacts (flows, views, and modules) by placing each into this central document and then detailing each to your heart’s content.

Ideally, a spec’s detailed descriptions are layered onto and beside each type of placed artwork. Examples and variation grids are displayed in tandem with referenceable descriptions of dynamic data and attributes, display conditions, and events (including triggers, transitions, and resulting states).

Module placed into a spec document and subsequently annotated

Managing a hierarchy of modularized artifacts
Ultimately, a result of modularization is an interdependent hierarchy of linked files: modules in views and spec, views in flows (to illustrate sequences and storyboards) and spec (to consolidate examples), and flows in spec (for high-level paths and understanding of the experience).

Examples of linked documents: modules in views and spec, views in flows and spec, and flows in spec

An IA can certainly adhere religiously to their own style for managing files and folders. Why not? If it ain’t broke, don’t fix it–especially if it fits your process or model. Up to now, you may not even have worried about this because all of your artwork has been in a single file. However, this modular approach requires that you consider how to store what could end up as many artifacts. One solution is to create directories that mimic your artifact types, such as:

  • /projectName/modules/
  • /projectName/views/
  • /projectName/flows/
  • /projectName/spec/
Tip: Consider an archive subdirectory (such as /projectName/modules/ archive/) where you store older versions to which you can refer or revert. Such a file structure becomes even more important as you share your modular artifacts with a larger team via a network drive or versioned storage system.

Pros and cons
Of course, such an approach has pros and cons:


  • Easier updates throughout
  • Scales well
  • Enables asset sharing for larger projects or multiple projects
  • Engenders analysis to consider more peripheral behaviors and scenarios
  • Triggers discussions of the team’s shared concept of the experience
  • Simplifies design decomposition for documentation


  • Remains only a static representation of an interactive experience
  • Requires discipline and initial effort to abstract modules
  • May need to re-crop artwork as variations are added to a file that has already been placed and cropped
  • Updates require tinkering to cascade through multiple placement levels across files (in InDesign and Illustrator)

Tighten your use
Some additional ideas to enhance your modular approach:

  • Manage your links
    Adobe’s products offer a Links palette for viewing, reloading (because of updates), and editing your linked files of placed artwork. Microsoft Visio offers the Drawing Explorer to identify what artwork has been inserted.

  • Establish size and grids
    Once you break out artwork into separate files, it will be very painful to reuse illustrations and maintain consistency unless you establish standard sizes for elements (headers, boxes, form elements) and a grid for placement. Of course, this assumes you’ve conveyed what your wireframes are meant to depict (and not depict) to your visual design and development staff.

  • Review your artifacts with their audience!
    Seek out visual designers, developers, and quality assurance staff early to ensure your technique produces something they want. The better the spec, the better the questions, and ultimately the better the product.
    Parting thoughts

I’m all for interactive prototypes. In the near future, I look forward to seeing static wireframe and spec artifacts increasingly combine with interactive prototypes via an approach that simultaneously documents and demonstrates our designs in a single presentation.

However, while such interactive prototypes are valuable, the industry (or at least the type of environment where I most often find myself) is far from denying the need for printable, reviewable, versioned, and auditable documentation that details a design. The waterfall development process, for better or worse, is still a world where many of us live. Therefore, in the short term, modularization is but one way to more efficiently, clearly, and comprehensively illustrate a complex design via wireframes.