When Spec’ing, Going Visual Gets it Done Quicker

These days, writing effective and efficient specifications for web sites should involve less narrative description and more visual depiction. It used to be that in conveying client desires to the engineers, we felt more of a need to write everything out, to be sure nothing was lost in translation. And to show and have proof that we heard our clients loud and clear.

However, now we can lean much more on visuals in our specs and less on narrative to get the job done quicker. Our “blueprint” is now one showing pictures of what we intend to build, that rough out various objects in an application or on a web page. And in some cases, the pictures “work” like real apps. or web pages in a prototype we can create for demonstration and testing.

Part of this is due to the way that specification tools have evolved. Tools such as Axure, which we use here at Beaconfire, include nice out-of-the-box visual “widgets” and design patterns that we can easily drag and drop into place. You can also spend time building your own if need be and store them in a library, for next time. These visuals are capable of conveying much of how the interface with function. Then any description needed can be added as an annotation that the tool manages for us. Also, such tools can publish out prototypes and specifications as HTML, giving us a handy web-based version of our spec for client review and for reference by the engineers.

We can also lean more on visuals rather than narrative, as certain design patterns and ideas have become so common on the web that they no longer require long narrative to describe them. A picture of the design pattern does just fine on its own, as there is an existing understanding and expectation we can rely on. Just as some things in the real world are already understood – you wouldn’t describe the action of a door knob turning to open a door in your house’s blueprint for instance – so are many things on the web.

For example, think of drop-down menus on a web site. Just labeling the object a ‘drop-down menu’ already sets plenty of expectation around how the object will work based on established norms. There is no need to describe the process of mousing over a primary label and triggering secondary navigation to drop-down below. It’s just expected. There may be specifics we still need to capture… “Delay .5 milliseconds before fading in the secondary nav…” but these are additive to or exceptions to established behaviors.

However, regardless of how common place objects in your spec might be, how much and what type of description you include still needs to be considered carefully based on the two typical audiences for specifications: the engineers doing the building, and clients approving that your spec meets their needs and desires. While the engineers will be able to intuit many behaviors from visuals with little description, you may need to describe more to be sure clients fully understand the spec.

Still if objects are already visual – or better yet interactions can be demonstrated with a working prototype – you can use the visuals to explain and demonstrate to clients that you heard them loud and clear. And that the spec reflects all of their wishes, along with smart interface design.