In a design process that documents a digital user experience, documentation can be modularized to varying degrees based on a design hierarchy. Such modularity results in independent files for components, views, and flows that are all systematically unified into published deliverables.

The design hierarchy provides a foundation to conceptualize and execute this approach. As a result, a design process can result in deliverables that are increasingly consistent, scalable, portable across designers, and efficiently produced.

Elements

An bottom-up explanation of the design hierarchy starts with an element, which is a single item such as:

• text
• button
• image
• radio button & label

You can’t break elements down into anything more granular, and you would never annotate anything more specific in a design documents.

Components

Components emerge from two or more elements that are combined to result in a structure that is standalone, reusable, and uniquely purposeful. Examples include:

• Search (with a label, text box, submit button, advanced search link, and help link)
• Header Navigation Bar (a box with numerous links, each with a dynamic drop-down of sublinks)
• Promo List (a labeled group of three items, each with a thumbnail, title, abstract, and buy now link)
• Tabbed Navigation (a series of tabs that create a collection of views)
• Related Links Sidebar (a labeled group of 3 to 5 links)
• Content List (a section header, descriptive text, and 3-5 bulleted points each up to 2 lines)

Components are vital for modularity, for they represent the key reusable chunks that can be repeated across two, many, or even every view of the experience. As your documentation expands, it becomes critical to abstract a component so you can (a) document it in a central, single location, (b) reuse it easily again and again, and (c) update it quickly across all instances throughout your documentation.

Composites

A combination of components that are used frequently together, but do not represent an entire view

• Header (logo + search + navigation bar + breadcrumbs)
• Footer (footer navigation + legal copy + rate this page + contact us)
• Tabbed Structure (tabs + subtabs + content container under the tabs + common content components in that container)
• List Filters (search + category list(s) + existing filter description)

Views

A point-in-time display within a application window - commonly a browser’s page - that’s composed by a combination of composites, components, and elements.

Why Not Just Call It A Page?

In modern web development, where AJAX interactions enable very sophisticated “in page” interactions, it’s more useful to refer to views because the page paradigm - at least how most folks need to understand it - has died away. Additionally, such nomenclature extends very well to desktop apps, widgets, smaller device UIs, and a range of other applications.

Well known examples include:

• Microsoft’s Web Outlook default view (folders, toolbar, inbox, etc)
• Amazon’s Shopping Cart page
• Google Search Results page
• Google Map’s Directions view, with turn-by-turn directions on the left, global navigation and search on top, and map on the lower right
• A UMPC’s Connection Manager “Connection List”
• Microsoft Word’s default document, with ribbon, menu bar, document viewer, and more

Collections

A series of views related by a unifying concept. Examples include:

• Page suite (such as a product’s overview, features, gallery, and tech specs)
• Flow (such as checkout’s billing, shipping, customer info, and order review steps)
• Site section, such as product landing, category, and detailed pages

What’s Next?

The design hierarchy provides a good foundation to modularize user experience documentation. Coming up, I’ll be taking you through a series of modular techniques, each with it’s own purpose, approach, benefits, how-tos, and gotchas. While the following list may grow and evolve, topics will include:

• Why modularity matters
• Choosing your toolset
• Creating views from elements
• Breaking down views into components
• Component variations
• Components in views
• View variations
• Views in flows
• Architecting a modular deliverable
• Flows & concepts in a deliverable
• Views in a deliverable
• Components in a deliverable
• When to create composites