Sometimes software becomes more complicated because the designers are trying too hard to make it better.
We’ve done it ourselves.
Our inspection software has gone through several iterations, and the way we structure surveys is a good example of what we learned.
The first version was simple
Our original prototype had sections and questions.
There was a fairly rigid report structure.
A particular element might have space for four photographs, with the response and perhaps a summary or recommendation underneath.
The resulting PDF was simple, but it worked.
At the time, we were producing surveys ourselves and sending them to a local printer to create professionally bound reports.
It was a remarkably effective workflow.
But it had obvious limitations.
Four photographs wasn’t always enough.
The report structure was fixed.
There was no interactive web report.
So we started experimenting.
Then we made it much more complicated
Our second major version became heavily icon-driven.
It looked fantastic.
Sections had icons.
Elements had icons.
Navigation moved between different levels.
The system had a deeper underlying data structure.
On a trade-show stand, it looked impressive.
People liked it.
But we kept hearing the same question:
“Yes, but what do the icons actually add?”
That was the problem.
We had made the interface visually sophisticated without necessarily making the inspection process better.
The problem with too many levels
The second version effectively created several layers between the inspector and the actual question.
You entered a section.
Then an element.
Then a question.
The navigation moved in different directions depending on where you were.
It was visually interesting.
It was also tiring.
Every extra level created another interruption.
The database structure became more complicated too.
That mattered on a mobile device.
Version three goes back to the useful parts
Our third version takes a much simpler approach.
There are fewer levels.
The interface uses straightforward written text.
The hierarchy is easier to understand.
But we kept the useful capabilities that had emerged from the earlier versions.
You can attach many photographs to an element.
You can tag media.
You can add notes.
You can provide hints.
And the underlying structure is much more extendable than the original prototype.
Hints are particularly useful
Hints are not simply instructions for the person completing the report.
They can be a way of standardising how inspections are carried out.
For example, a room inspection might have a hint telling the inspector to photograph:
- each corner
- the ceiling
- the floor
- relevant features
That creates a more consistent set of evidence.
Similarly, when photographing an issue, a hint might remind the inspector to take a wider photograph showing the context and then a close-up showing the detail.
That is useful for experienced inspectors.
It can be even more useful for trainees.
Notes don’t have to become part of the report
Notes can also be attached to the relevant part of the survey without necessarily appearing in the final report.
That gives the inspector somewhere to record information that helps them work without cluttering the client’s final document.
The Goldilocks point
The lesson from all of this is not that simple software is always better.
Nor is it that sophisticated software is bad.
The lesson is that there is a point where additional structure stops helping.
Too little structure is frustrating.
Too much structure gets in the way.
We think we have found the Goldilocks point:
enough structure to make inspections consistent and powerful, without making the inspector fight the interface.
Brightchecker is flexible by design
About the Author
