Category: Practical Matters

UI specs should capture the following pieces of data: consistent terminology, pixel-level measurements, annotated screenshots (see prior post on how to create accurate images for specs), behavioral descriptions beyond the obvious or “for free” stuff, with cross-references where appropriate and useful between depedent specs.

Tables and spreadsheets do NOT make for good spec content or layouts as they tend to be hard to read.

Indeed, specs should be considered “designed artifacts”, not simply last minute or post-mortem writing thrown together at the end of a prototyping phase. Per schedules, the spec writing should occur somewhat in parallel, with engagement with the spec writer and devs, QA, UI designer, prototyper, etc.

Chunking and spacing the text and imagery properly is necessary to achieve that delicate balance of creating a document that is easily scannable and comfortable/inviting to read at length. Extensive prose text is not recommended. Avoid “should”, “could”, “would”, and any explanations/rationale–this is not a defense but a statement of what is to be. In effect, a recipe or cookbook so that if a disaster wiped out the company, then a remote dev team can rebuild the product from the specs (presuming that the documents are backed up somewhere!)

As the design and development teams are finalizing the designs of widgets, controls, labels, you need to come together on the vocabulary: is it a dropdown menu, droplist, pulldown list, or something else? Establishing consistency of lingo is key towards more efficient, clear communication with minimal confusion downstream at spec’ing and QA’ing stages.

And part of the consistency might mean the designer has to suck it up and “drink the kool-aid” of the client company and use their legacy lingo particular to their customers and culture. I prefer the analogy of “when in Rome…do as the Romans do”, as “kool-aid” has a rather grim origin :-)

When constructing POC (proof of concept) prototypes for customer evaluation:
1) The prototype should be as real/accurate as possible with real data, to convey something sufficiently familiar in terms of tasks/content…not greeked text with random, imagined data and layouts. That will only confuse users.
2) The goal of the evaluation is to gather feedback–both positive and negative–for subsequent iteration and decision-making
3) Consider staggering the introduction of new features into the prototypes such that the initial round is for primary concepts and later rounds have variations of the concepts with more detail, interactivity, etc. — ie, don’t overload the prototype with every whizz-bang feature. Be diligent and focused/scoped to yield better feedback.