So you figured out your design, met all the requirements and managed to create an interface that not only solves the end-users’ problems, but is also aesthetically appealing. You might even have developed a prototype and conducted a little usability testing on the fly. Now what? What do you do with all that work and how do you communicate your design?

Communicating design is a critical part of the entire design process and often where things go wrong. Indeed, it is as important as the design itself. You can have what seems to be a perfect design, but if it is not well communicated or you simply cannot explain and justify decisions made, you will sink your design in the space of a single meeting. I have written about this before in:

What would Steve do?

Five essential elements in presenting UX design

This is why your specifications document (or documentation) is so important. They communicate your design to the developers, the stakeholders and often yourself after you have moved on to a different project. Indeed this last point is most important. I can always judge my own specifications by whether or not I can understand the design 3 months later when a developer comes to ask me a question.

Now, there is the whole idea of Lean UX and spending less time on these deliverables. But, many organizations rely on these documents as part of a formal or even regulatory process. As much as I would like to get away from updating a set of UX specifications 9 times, I really can’t because my company is regulated by the FDA. (GN ReSound produces Hearing Aids, which are considered medical devices and FDA regulation requires stringent documentation.) The other problem with leaning out your process is the lack of visibility. That is, our deliverables are often seen as evidence of our work and justification of our existence in an organization – despite the fact that most of our deliverables are thrown away by the time development is in its final stages. But Lean UX is a topic for another forum. For the sake of argument, let’s suppose you are in organization where these deliverables are expected.

UX specifications and documentation are not very well covered topics in our profession. What should they include? What should they look like? Most importantly, what should you use to build them? The best coverage I have found on this topic is Dan Brown’s book, Communicating Design: Developing Web Site Documentation for Design and Planning. It is now in its second edition, but 4 years old and due for an update (hear that Dan?). Chapter 8 of that book is an excellent overview of the documentation process. But, it doesn’t give you much in the way of tools in putting these documents together.

What Goes Into UX Specifications?

How you structure your specification documents will largely depend on the client or organization you are working for. The 4 essentials are a title page, an introduction to the feature, annotated wireframes and a version history. But, you can include a lot more such as flow diagrams, conceptual models, site maps and user research conducted prior to or during the design process. For me, it really depends on the project and what the document needs to communicate to the developers and stakeholders. Site maps, conceptual models, personas and the like are truly only necessary when the project is self-contained. For example, I currently work on a platform where I design new features for that platform which is well into its third major version. A site map is not necessary in our specifications and we need only know where the new feature fits into the existing navigation. But, I recently worked on an entirely new feature requiring us to understand the flow of the users. For that, I used a flow diagram and included it as an appendix in the specifications. Here is an example:

UX Specifications Example – Personal Fine Tuning

So let’s go over the 4 Essential content items for UX Specifications with a few bonus items thrown in.

Title Page – You should have a title page and while this might seem a no-brainer, many designers I work with will omit or forget to include it relying, instead, on the title of the file. Including a title page just gives your document a polished and professional look. Remember: First impressions are lasting and you want to have a professional first impression.

Introduction – This is where I usually outline the problem this solves for the user. Outlining the problem is important for me because I have found myself working on marketing projects more than once where there was no problem. If you can’t succinctly outline the problem the design solves, you might have another sort of problem. But, I generally spend a little time in this section telling the user what I am going to show and what I will tell them in the remainder of the document. It’s a simple overview.

Annotated Wireframes – This is essential and one of the hardest parts of the process because it involves a lot of detail in communicating the functionality of the interface. There are different ways you can do this. But, there is a fine line between giving too much detail and not enough. Too much detail drowns your user and not enough leaves open questions that must be resolved in long email chains or meetings. There isn’t a clear directive on this one. It just takes some experience to annotate with the right level of detail. In fact, this is such a complicated topic, I’ll devote a future post to it. But in a general sense, the annotations should explain the primary functionality, but also secondary functionality such as where navigation items take the user (back buttons, next buttons), how to cancel, how to undo, etc.

Versioning – Always document the version and what has changed in each version with a detailed list. This enables you to go back in future versions to determine what decisions were made, when they occurred and where they occurred on the project timeline.

There are a few other items I frequently add as well. One item is an open issue section. So instead of including questions on each page for each part of the feature, I line them all up in a section of the specifications so I can keep outstanding problems in a single place (and straight in my mind). Another item I like to include is a demo video to illustrate the interaction in a feature. This works really well on conceptual or new projects and is less necessary on projects where there is an existing platform with similar interactions. There is a link below with a working example of this concept in use.

How Do You Put the Specifications Together?

This is always a tricky topic because everyone has their favorite software and tools to use in creating UX specifications. There are generally three ways to create specification documents – export directly from the software, use a combination of software platforms to create higher end specifications or use specialized software designed for the task. I’ll cover each briefly.

Direct Export Method: There are a number of platforms used in the industry to create wireframes and prototypes such as iRise, Axure and Justinmind. Most of these platforms allow you to export directly from the software to a Word document. For example, if you work in Axure, you have an option to export specifications with a number of settings you choose and annotations you set in advance. The downfall with this approach is that you generally have to do a lot of work in advance to get the specifications you desire and you don’t have a whole lot of options for image manipulation. Axure will export the entire screen at a percentage, but you don’t have the option to crop or highlight smaller areas of the screen. Moreover, exporting the specs to Word limits you as Word is not really well-designed for such tasks. It’s a word processing program, not a desktop publishing suite like InDesign. This option is not my preference for creating UX specifications for the sole reason that I like to have more control over the output. I also like to have more control over the format.

This method is best for: Those who want to work in as few platforms as possible and do not have stringent aesthetic requirements for the output of their specs.

Here’s an example of a set of specifications exported from Axure:

Axure Specifications

Software Combination Method: This method employs the use of a wireframing tool, a screenshot tool and software to join them together. For example, many designer I know use Photoshop to create their wireframes and then use InDesign to annotate the Photoshop screens. Any image manipulation in a scenario like this could be done in Photoshop or InDesign. But, this process could also be extended to Axure where you create the wireframes in a tool designed for creating wireframes, run the prototype and use a screen capture program such as Snagit to get the images. Then you use InDesign to create the specifications. The downfall to all of this is that you have to be proficient in 2-4 different software packages in order to complete this process. The nice thing about this method is the fidelity or the end product. Specifications created this way tend to have the highest aesthetic value.

This method is best for: Those who are already familiar with Adobe and working in it to create wireframes or those proficient in Adobe and their wireframing tool who want high fidelity specifications.

EightShapes Unify has some InDesign templates and other resources you can use along with example specification documents here:

EightShapes Unify Specification Templates

Dedicated Documentation Software: This is my preferred option and it does still force you to use more than one software package. But, I see the documentation process as different from the design process. I don’t like to think too much about one when I am doing the other. Essentially, you create your wireframes and then use this software to create the screens and annotations. This method is fairly cheap as well. The two best software options are Clarify and ScreenSteps. ScreenSteps has an online version and a desktop version. They are phasing out support for the desktop version, but you can still purchase it and it is what I started with. This is software primarily designed put together tutorials in a document form. But, ScreenSteps allows embedded videos and export to various formats such as HTML. Here is an example of a sample document I created in HTML with embedded video when we were reviewing our specification process last year. Note: You will have to enlarge the videos to full screen for the best detail.

UX HTML Specification – Frequency Lowering

Basically, the process works like this: I create my prototype in Axure. I then run it as a prototype (or export it to HTML), capture the screens and interactions from ScreenSteps, annotate them and export this document to an MS Word. I’ll go into detail as to what my process is in a future post. It is beyond the scope of this particular article. But, ScreenSteps allows image manipulation, built in numbered annotations, embedded video and a host of other features to create nice linear documents for developers. Clarify is very similar and will be the replacement for the desktop version of ScreenSteps eventually. But, I have only recently downloaded the beta version and have not used it yet.

This method is best for: Designers who need solid control over the output of their documents but do not want to tackle the learning curve provided by Adobe software packages. ScreenSteps and Clarify are easy to use, economical and are dedicated to the task of building specifications documents.

In summary, your specifications documents, the detail therein and how they look are all important aspects in communicating your designs. It does you little good to produce great designs and wireframes, but fail to use the right vehicle in communicating the problems your design solves. Good specifications can help you do that. But, the UX profession has not been very good at documenting how we handle documentation. This article is the first in a series of articles I’ll write in an effort to change that.