When it comes to building software many New Zealand companies unnecessarily struggle with design and development issues. Much of this is due to software specifications without adequate pictures.
Below is the specification a building architect has written for a new house:
…the total floor area of the building is to be approximately 250 square metres and incorporate two “wings,” a central space, and a utility room. The entry door is to be located in the centre of the southern façade and open into the kitchen area. The block on the west will contain the bedroom and bathroom. The block on the east will contain the living and office area. Mechanical, electrical, and plumbing equipment is to be located in a central pod next to the bathroom. The living/office block will have interior dimensions of 5m by 7m with a high sloping ceiling. An irregular-shaped kitchen will be 4m by 6m at its largest interior dimensions. With a peak ceiling height of 4m, the kitchen block will contain a high space area above the kitchen counters, referred to as the “catwalk”. This area can contain plants and the air ducts. The small bedroom will measure 4m by 3m interior dimensions, again with a sloping ceiling. The bathroom will contain a sink, toilet, and shower. Rather than a shower tray and fixed walls, the shower area will use a curtain and sloping bathroom ‘wet floor’ to maintain wheelchair accessibility. The front entrance is to be served by a deck with access by stairs and wheelchair ramp. The deck off the rear entrance is to be accessible by stairs…
Sounds comprehensive. But would you take this sort of information to a building firm and say – “Build this – you’ve got three months”.
Unlikely.
Although the specification describes the house and its features in detail, each person reading this document would have a different visualisation of the end product. Rush into the construction process and soon the builders will be downing their tools and holding debates over the architect’s definition of a ‘façade’. Building managers will be pulling their hair out over the tight deadline (“no time to debate!”). And the building owner will be watching their money rapidly disappear (kiss goodbye to that interior design budget).
Now, what if the architect also presented the builders with diagrams similar to the following (the key is, they do this before they start building it, not when construction is part way through).
 |
 |
 |
 |
Images: Copyright © University of Colorado Solar Decathlon Team
Obviously this is a vast improvement as the diagrams bring the written specifications to life. The construction team can now visualise the same end goal and build with greater speed and confidence. In the building industry the use of blueprints and diagrams is essential. In fact, builders can’t do their job properly without them.
But, historically, the software development industry has worked differently. And we’re not just apart from the building industry, but also film, advertising, publishing and manufacturing. These industries almost always create visuals and prototypes of what they intend to take to market – it’s inherent in their culture – not questioned, but essential.
The industry whisperings are that software technical specifications confuse a significant percentage of the very smart people involved (although they rarely realise this at the time). The writer isn’t always to blame. They have a daunting task in trying to communicate a complex system in mainly words. While the typical software specifications do contain some technical diagrams (including flow-charts, UML diagrams and the odd rudimentary screen mock-up), it frequently isn’t enough.
There are a number of reasons for this:
Own Goals
If your analysts haven’t researched the goals of users and the business then the project team will not be able to contextualize their understanding of the specifications. Instead they will assume what is required based on hearsay and their own view of the world.Opaque Thoughts
When team members get together to discuss technical documentation there is a lot of essential information hidden from view. This is stored in each persons thought processes. While everyone at the table might nod in agreement, does each person hold the same picture in their head as everyone else? How do you know for sure?Isolation Tanks
Software developers are often instructed to start building features in a modular fashion and to “just get on with it”. There’s rarely a comprehensive vision of the end goal, leading to inconsistent code and designs.
In New Zealand we pay the price for these follies over and over again. This is because the entrenched de-facto standard is that most software is built without visuals as a central component of the analysis, architecture and feedback-loop processes.
It’s not uncommon for businesses and Government to spend tens and hundreds of thousands on business analysis and technical requirements but still come away with little idea of what their product it will act like or look like. This is like building a house without diagrams.
If your company is planning to redesign an aging software application or building new web-based application then it’s time to think fresh. You need an Interaction Designer, or a person with equivalent skills, on your project (they can also come under the guise of ‘interface designer’).
Just like a building architect the Interaction Designer will consider how your users will move through the software application in order to achieve their goals. They’ll take into account user habits, preferences and other characteristics. They’ll also bring team members together to encourage debate, resolve issues and help create a unified development environment.
Bob Baxley, author of the book ‘Making the Web Work – Designing Effective Web Applications‘, describes the field of interaction design as concentrating on the following:
Human/machine communication
In the role of translator, interaction designers are required to understand the subtleties and colloquialisms between the technology and the user, ensuring that they can readily and efficiently communicate with one another.Action/Reaction
This requires the designer to understand and anticipate how interactions unfold over time, designing for the wide range of permutations that can occur.State
As part of its role as translator, interaction design is also concerned with ensuring the user understands the current state of the application.Workflow
Like a film director connecting individual shots into scenes, and scenes into movies, the interaction designer uses individual screen elements to create pages, pages to create complex operations, and operations to create a complete application.Malfunction
As with all forms of communication, misunderstandings and mistakes occur. Therefore it is also part of the designer’s role to anticipate and mitigate those problems, ens
uring that both the user and the system can easily recover.
In the software realm the Interaction Designer will breathe life into your software – preferably before a line of code has even been written.
It’s this simple. They will build the application on paper before you build it for real. Here’s a few examples of paper prototypes (created using Microsoft Visio) prior to development:
Low-Fidelity Paper Prototype
High-Fidelity Paper Prototype
Images: Copyright © Provoke Solutions
Paper prototypes are powerful. Here’s a few of the benefits:
- You can test the basics of your system on users.
- Business stake-holders get a tangible view of their investment.
- They help clarify functional requirements and the associated costs.
- Developers use them as a blueprint as they build the system.
- They reduce the number of change requests and unseen issues during the development cycle.
- They’re more productive for the whole organisation and can even be fun to work with.
- You as a business stakeholder, or software developer, will lower your risks.
Using visuals and paper prototypes does mean boosting the investment for your software budget. But the cost is justified when you consider the various benefits.
Design is one of the first categories to be habitually squeezed by many a manager trying to make the budget work. This needs to change. It would often be wiser to trim features over design.
To sum up:
- Well-designed visuals greatly improve the understanding of technical specifications.
- Interaction Designers specialise in working with developers to build visual specifications and prototypes of your system.
- Make design a baseline item in project plans and budgets.
- The overall design lifecycle also includes analysis and architecture.
- Get designers involved early in the process.
You must be logged in to post a comment.