How do you specify a user interface?

I was recommended to read through a book of M. Schrage titled “Serious Play”. In the very beginning of the book I found the term “prototyping-driven specification”. This means that the specification is very much defined by intense prototyping efforts.

Conversely, “specification-driven prototyping” is primarily propelled by formal (modelling) processes that ultimately end up in a detailed paper-based specification document. With regards the IT organizations I have been a part of, most projects environments seem to be very “specification-driven”. I’d even say that the liability to “specification-driven” processes increases with the complexity of the organization and the software product being developed.

As I stated earlier in this blog, paper-based specifications are not very suitable for defining how a user interface should look and feel like. Unfortunately, most IT organizations produce textual specification sheets and assign the implementation to an (external) IT supplier. Not before this specification has been finalized, the supplier starts working. This usually leads to situations where the first prototype is available after several weeks or even month (depending on the kind of software that is developed).

With regards to Schrage’s book, I can therefore very much understand the necessity of changing development culture to a situation where prototypes are available much earlier. The philosophy of “prototyping-driven specification” is very reasonable, but it is as well not very new. Well known requirements engineering lifecycles as Volere already recommended to prototype certain requirements up-front in order to address uncertainty and gather user feedback very early. The Volere process model was designed to incorporate the experience from such prototyping efforts into the consolidation of the requirements specification.

It is easy to map Schrage’s ideas to the business of usability engineering. Every interaction designer knows that early-stage prototyping should belong to his regular tools of the business. Showing designs to end-users very late is usually not a very good idea and mostly leads to costly late-cycle change requests.

So what’s so excitingly new in “Serious Play”? Nothing. But in my opinion the book is a very good mean to wake up project managers that still tend to defer user interface issues until the later stages of software design. And, one might start thinking about the “weight” of the methods he usually applies. If you strictly follow the “prototyping-driven” approach, you might end-up in a situation where “old-fashioned” artefacts of requirements engineering have been replaced by running simulations that show the implications of the requirement. Actually, this very radical approach seems to be behind the idea of Rise. The success of the tool underlines the high demand for easy-to-apply analysis and design tools. But are prototypes really enough to specify the UI of a software system? Definitely no.

Even in iRise, you can add textual descriptions to build use cases or write scenarios. Moreover you can export all artefacts to a Word document which is especially needed for making contracts with your suppliers. The fact that iRise has interfaces to management tools such as Rationale also points out to the necessity of having a repository of design thinking and design rationale. Especially if you forward a specification to a supplier, it is necessary to provide additional information about the system that has to build. For example, that is why designer write Style Guides.

What especially disappoints me is the fact that there is not a single book available describing how whatever-driven specifications really look like. The usability engineering community has done a lot to come up with different design lifecycles. The associated methods are described in detail and in some parts supported by international standards (e.g. ISO 13407 or 9241).

But only if we are able to define the necessary ingredients of a user interface specification, we can really say whether a specification approaches we are using are really suitable. Naturally, this also affects the tools that we apply.
Until we see an ISO standard for user interface specification, the outcome of many design processes will remain unstructured and very individual. How do your user interface specifications look like?