Specifications — or “specs” — describe the structural, behavioral, or visual aspects of your software conceptually and in the context of both your goals and the user’s.

Why are specs necessary? Because they can offer an added level of abstraction. Where artifacts like “comps,” prototypes and wireframes serve to describe decisions about form and behavior, a spec will describe the rationale, logic, and patterns behind those decisions.

My samples come in three categories: IA specs convey high-level structural decisions about the solution, like its “content model.” IxD specs describe the logic driving the ways a solution will behave in response to kinds of user input. Visual Design specs describe decisions about the UI that must be fleshed out by a Designer or implemented by a Developer.

Can you just wing it? Sometimes. But for large, complex solutions, you cannot afford to not be explicit in such matters. Anything less risks a disjointed user experience.

What are the qualities of an effective spec?

Specifications, like wireframes are usually internal documents, intended to be consumed by colleagues on your team. And typically your team won’t care what these documents look like as long as the message gets across. And, unless it’s a pattern library, the relevance of the average spec is often extremely 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.”

Strategy Report
This 2013 spec I authored describes a solution’s core concept and how it shall be expressed in the UI.