real world columns: specifications

There is a story that the Mathematics building at Manchester University was built back to front. The architect specified it all on paper and then went on holiday (very silly!). When he got back, the foundations were nearing completion and everything was facing the wrong way. It would have cost too much to dig it up and start again, so the specifications underwent minor modifications and the tower was completed back to front. I don’t know if the story is true or not but the tower certainly does seem to have a back to front feel about it, and the main entrance is on the second floor.

The specifications that pass between designer and constructor take many forms and the new discipline of user interface designer is still struggling with the ideas. Research groups are continually coming up with languages for describing interactive systems, and yet the commercial world in general is only just starting to take user interface design itself seriously, let alone specification languages for the area.

One of the key factors with specifying interfaces in a real-world, commercial environment is the threshold of effort needed to make a complete specification. Often the approach is to do briefings (rough verbal ‘specifications’), and refine them as the construction process continues. This requires regular monitoring, but in the end might cost less effort than meticulous specifications at the beginning. Also, it allows input from the person doing the construction (‘Errm, I hate to say this but aren’t we building it all back to front?’).

One interesting observation is that specifying a user interface could be easy. If you are specifying a digital communication protocol then the requirements (security, error checking) are such that the thing you end up specifying is complex. However, one of the key requirements of a user interface is that it is easy to follow and understand; the concepts must be as few and as simple as possible. It follows then that there should be some simple way of specifying it, and if it isn’t easy to specify, then it could be because the interface is badly designed. (If you explain an interface to a group of people and no-one understands it then the chances are that it is a bad interface). So what we need is a language that is close to the designer, that uses high-level, designer-concepts and has nothing to do with how the design is implemented.

The danger is the loss of elemental specification. With any specification language it should be possible to express all possible ideas. Some kiddies construction kits are geared up for building houses, there are large roof chunks, walls and windows. Building any variety of house you want is simple and fast. But if you want to build an airplane then it is almost impossible. In contrast, basic Lego blocks allow you to build whatever you want, but their elemental nature means that what you gain in flexibility you pay for in that it takes a higher level of investment to get the same results. What you need is the best of both worlds; a house building kit where the walls and roofs are prefabricated chunks made from many Lego bricks. You can put houses together very quickly, but if you want to make alterations or create something completely different the large chunks can be deconstructed and you have the flexibility offered by separate Lego bricks.

I opened with the suggestion that a complete specification is often too time-consuming compared to refinement during construction. Another point is that complete specifications are very rarely complete. There are always gaps. Sometimes such gaps are intentional, they form part of a top-down approach to specification, but sometimes the gaps are unintentional and then they are filled in, in one of the following ways:

1) Unknowingly by the implementers; no-one notices the gap and it is just filled in without thinking.

2) According to the implementer’s preference; the implementer is aware of the problem but just fills it in with whatever is easiest from a technical point of view.

3) Implementer’s guess of the designer’s preference; the implementer is aware of the gap, doesn’t consult with the designer and makes a guess as to the best design to fill the gap.

4) In discussion with the designer; the implementer (who has already implemented a large part of the solution) draws the gap to the designer’s attention and together they sort out a solution, usually resulting in a compromise.

A wonderful example of this last approach is Apple’s experiences with Giorgetto Giugiaro the top Italian designer and his studio. After several problems with the joint design process they discovered that the Italian designer’s way of producing models was completely different from their own. In America the model shop gets detailed design specifications and follows them to the letter. In Italy the model makers are ‘carrozzerie’; craftsmen, and actually take over part of the design process themselves, acting on partial specifications they refine them to produce the final models. The magic doesn’t happen in the design studios but in the interaction between the designers and these craftsmen.

Maybe introducing specifications into design always precludes that vital spark of genius that defies specification.

(The Italian designer story is from the compelling book ‘Apple Design’ by Paul Kunkel, Graphics Inc. NY).