Home > Specifications

Specifications

Find here samples of the innumerable specification documents I’ve authored over the course of my career to date. Each belongs to one of the following three categories: Information Architecture, Interaction Design, and Visual Design.

Specification documents are most often referred to informally as “specs.”

Click on any of the three thumbnails to review the full sample document previewed.

Or click the ‘View samples’ link in each category description to review several documents of that type.

What is a spec?

Describing the structural, behavioral, or visual aspects of your software solution in a conceptual way, and in the context of your users’ goals, is the job of the specification document — or “spec” for short. When necessary, the context of your organization’s business goals and technical capability are additionally layered into these documents.

While prototypes and wireframes serve to describe exactly how structure and behavior are incidentally revealed to the user screen-to-screen, a good spec serves to describe the concepts and patterns THAT DRIVE such instances. If wireframes predict the weather, specs describe the climate.

For large and complex software solutions, you cannot afford to not be explicit in such matters. Leading the user to believe one thing about how your solution is structured or behaves in one case, only to have that belief confounded in another, is UX poison.

What makes a good spec

Specifications, like wireframes are usually INTERNAL documents, intended to be consumed by your team. And typically your team won’t care what these documents look like as long as they get the message across. Also the relevance of such documents is often very short-lived. So I apply a very pragmatic criteria to specs I author: If it was appropriately descriptive, clear, thorough, and delivered in time to be useful, it did its job.

OCCASIONALLY, specs must be presented to powerful stakeholders and even potential customers. In such cases, the BEAUTY OF THE ACTUAL DOCUMENT itself may be a factor.

In all other cases, however, as Jeff Gothelf has written:

“Putting in [high levels] of polish and effort into the early stage artifacts — wireframes, sitemaps, and workflow diagrams — is a waste of time.”