My company’s product, ONEIS, is a complex and sophisticated information management platform. It has metadata handling which far exceeds that of other products, and combines a graph database with easy free text searching.
Yet our “training course”, which enables a user to get the most out of it, is just this:
- When you want to find something, click Search and type in what you want.
- When you want to add something, click Add, click what kind of thing it is, then fill in the form to describe it.
That’s it. If someone follows those instructions, they will be managing their information well, and they will find what they need when they need it. And, perhaps more importantly, their colleagues will find what they need too.
The key to delivering sophisticated systems which are easy to use is to take a radical approach to simplicity. Assuming that you’re a developer, unfortunately this means you’re going to have to work harder.
Complexity belongs below the user interface
This quote is vastly overused, but only because it puts an important point so succinctly:
“It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry
Like a duck, ONEIS is graceful and elegant to look at, with all the hard work hidden from view. On the top, it enables elegant and effortless progress to an objective, but underneath, there are some really complex systems to enable it to “just work”.
We believe that developers should do the hard work, not the users.
Compared to developers, there are many users. And the work that developers do, once complete, will run over and over again without any more effort. Yet any work our users do is repeated over and over again.
It is clear to me, therefore, that the division of labour must be such that developers do lots of hard work, and make sure that users do nothing more than the absolute minimum to get their work done.
This is what ONEIS looks like now:
At the beginning of the project, while we were prototyping and exploring what we needed to build, like many systems, we had quite a complex interface. There were two causes:
- Lack of time spent polishing the UI.
- Exposing an underlying model of the application.
The first is pretty obvious, and I think the one that generally gets the most effort. You need to spend time polishing a user interface.
But it’s the second which is more important, but more subtle. If, underlying the user interface, the application itself is clumsy, the user interface will reflect this. Each thing the users have to understand about the way the application works will make it harder to use.
Don’t just polish, rethink everything
Your challenge, when you’re aiming to build a truly usable application, is to remove absolutely everything from the user interface that you possibly can.
This isn’t about removing features from your application, it’s about structuring it so those features work without the user having to think about it.
As an example from our pre-release versions, we used to split all the information we stored into explicit “sections”. Our intention was to model the way organisations are split into different functions or departments. You had to explicitly switch to a section to see things within it.
Obviously, this was crazy, so we removed it quickly.
But you do actually need a feature like this, so we didn’t remove the ability of the system to partition information. We just rethought how it should work, and implemented something much more difficult to write: the ability to split up information without the user noticing. We use cues from the data model and the users’ permissions to determine where information belongs, yet present a single unified view across everything the user can see.
This was not easy. We had to do some very careful design, write some complex code, and go through many prototypes.
But the end result is that our system is even more powerful than it was before, and yet has less user interface, and there’s less for our users to think about.
We use a couple of techniques for achieving radical simplicity in our application.
Firstly, we treat all support requests as bugs, and fix them. This is not a new idea, Joel Spolsky wrote about it years ago (read “Fix everything two ways”). We use this as an essential measurement of how we’re doing, with our aim to get no support requests at all. We’re pretty successful at this — our support queries are almost always about strategies to get the most out of the system, rather than using it.
The second is to ask “how would I remove this without compromising the power of my application?” when implementing any new bit of user interface, along with regularly running through the application and asking it again of everything you’ve done already. If there’s a way something could be removed while still retaining the capability, remove it.
Radical simplicity works
We’ve found that three important things happen when you take a radical approach to simplicity.
- Our users love our work.
- Our application becomes more powerful and capable, yet remains easy to use.
- It’s easier to make sales.
Of course, it means we have to work harder. But we don’t mind that. Every bit of hard work we do means our users have more time to get on with their actual work.
No one should have to do mindless and unnecessary tasks to drive software. As a developer, it’s your job to prevent this.
COMMENTSblog comments powered by Disqus