Good interface design isn’t about making software look impressive.
It is about making people understand what to do next.
That sounds obvious.
It is surprisingly difficult to get right.
Put the common actions where people expect them
BrightChecker’s main administration screens have a deliberately limited top-level menu.
We chose six of the most commonly used areas rather than filling the screen with every function the system can perform.
Most organisations don’t spend their day changing subscription settings or managing configuration.
They assign surveys.
They carry them out.
They review them.
They produce reports.
So those are the things that should be easy to reach.
Less frequently used functions are still available from the main dashboard.
The dashboard is the complete map
The dashboard provides access to the wider system.
Each major function has its own tile, with an icon, title and description.
That means users don’t need to remember obscure menu structures.
If they need something they don’t use very often, they can find it.
The survey tracker becomes the workflow
One of the things we found particularly useful was making the survey tracker itself part of the navigation system.
The status of a survey isn’t simply information.
It is a control.
Clicking the relevant stage takes you into the appropriate part of the workflow.
So instead of learning a complicated series of menus, users can look at the survey and simply move through its stages.
Help where you need it
We also learned something from our earlier knowledge base.
It was good.
It was detailed.
It covered the system extensively.
People didn’t use it as much as we expected.
The reason was simple.
People didn’t want to leave the screen they were working on.
So we brought the help into the interface.
Each major screen has an education area explaining what the screen does and how to use it.
It can include explanations, screenshots and links to other material.
Users can close it when they understand the screen, and reopen it when they need it.
There are also contextual explanations and help around individual controls.
The idea is simple:
Don’t make someone leave the job they’re doing to find out how to do it.
Consistency matters
We also use consistent visual behaviour throughout the administration interface.
Actions that generate something use one visual treatment.
General actions use another.
Destructive actions have a deliberately stronger warning treatment.
Buttons change appearance when you interact with them.
Notifications tell you when something has succeeded or when something needs attention.
That consistency means users don’t have to relearn the interface on every screen.
The field interface is deliberately different
The field section is different because the environment is different.
You might be using a phone.
You might be outside.
You might be standing in bright sunlight.
You might only have one hand available.
The interface therefore uses stronger contrast and larger, clearer controls.
Menus are designed around mobile interaction rather than simply shrinking a desktop interface.
On a tablet, the interface expands naturally.
On a computer, it adapts to the larger display.
The aim is that the system remains recognisable wherever you use it.
Accessibility influenced the design
Accessibility was one of the influences on decisions around font sizes, contrast and button sizing.
Google and Apple guidance also influenced our thinking.
That does not mean we are claiming formal compliance with a particular accessibility standard unless a specific implementation has been tested against that standard.
It means accessibility was considered during the design process.
That’s an important distinction.
Built through use, not just specification
Perhaps the biggest difference is that the interface wasn’t simply specified and handed to developers.
We have used it.
We’ve built prototypes.
We’ve rebuilt interfaces.
We’ve carried out inspections.
During development alone, we uploaded thousands of photographs and repeatedly performed the same actions.
That gives you something that a conventional specification doesn’t.
Muscle memory.
Frustration.
The things that take one extra click.
The buttons you naturally try to press.
The screens you don’t want to leave.
That’s where a lot of interface design actually comes from.