One of the (many) things I take heat for is my insistence that, with very few exceptions, there’s really no such thing as an intuitive application or user interface. Rather, I believe that apps and interfaces are familiar: you’ve used something similar in the past and can muddle your way through it. But that muddling takes in account a store of knowledge, specifically the hard-won knowledge that comes from having learned to use an interface or an application in the past. You can’t always carry that knowledge over to a new application or device.
The other day, I read a blog post about a usability study of the iPhone by the firm Create with Context. The study looks at how people actually use the iPhone, and according to the blog post I mentioned:
The research showed that some of the tasks that experienced iPhone users would consider trivially simple were much more complicated for newcomers to the interface.
Here’s the slide deck that goes with the study. Interesting stuff.
The other day, I came across the Apple Human Interface Guidelines, which is a document that helps guide developers to create consistent, easy to use applications that will run on Apple’s devices.
The guidelines are very detailed. Check the link above to see for yourself, or download the 28+ MB PDF version. While skimming the document, I ran into two interesting sections.
The first is titled “Involving Users in the Design Process, which states:
The best way to make sure your product meets the needs of your target audience is to expose your designs to the scrutiny of your users. Doing this during every phase of the design process can help reveal which features of your product work well and which need improvement.
When you give people an opportunity to use your product (or a prototype of it) you may uncover usability problems that you did not anticipate during your initial design phase. Finding and eliminating these problems early can save you time and money later on. Clearly identifying the needs of your users helps you create products that deliver effective solutions and are typically easier for them to learn and use. These improvements can translate into competitive advantages, increased sales, and enhanced customer satisfaction.
The second is titled “Keep Your Users in Mind“, and starts off with the following words:
In addition to the basic principles of interface design, consider the needs of your audience. Are your users more comfortable in a language other than English? Do they have special needs that might affect the way you present data to them? The following sections identify areas that might influence your design.
Admittedly, I don’t own a Mac. And I’m definitely not an Apple fanboy. That said, I’ve used and played with them sporadically over the years, though. Something that always struck me was the general consistency of the applications, and the (relative) ease of use of Mac OS. Obviously, there’s something to be learned from reading the Apple Human Interface Guidelines.
Why do software designers want their work to appear more complex instead of less? That’s a question David Pogue poses, and I’m sure it’s one that you’ve asked too. Whether as a user of software, or in your role as a technical communicator.
In decrying complex, cluttered interfaces Pogue hits the problem squarely on the jaw:
it’s less effort to make the end user jump through a bunch of hoops than to make your own software more intelligent.
Documentation can help explain a complex UI. But, as Aaron pointed out in a previous post, You can’t paper over bad design, no matter how hard you try.
It takes more than that, and technical communicators can play a role. I remember a quote I read on the User Advocacy blog:
[Technical communicators] can also become a part of the development team that ensures the interface is consistent, the application works from a user’s point of view, all of its parts work correctly and the experience confronting the user is one they will want to return to. We will be instrumental in communicating application to user, and user to application.
Thoughts? Feel free to leave a comment.
The other day, my wife pointed me to an interesting presentation given at the LIFT 2007 conference by Sugata Mitra. In this presentation, Mitra discusses his Hole in the Wall project — literally, putting a computer and a track pad in a hole in a wall in several locations in India, and letting children (who’ve never seen or used a computer before) discover and learn to use the device.
The results were very interesting. Mitra found that when they stumbled upon this, the children invariably were able to teach themselves to browse the Web within minutes. All with no outside assistance.
This got me thinking about so-called intuitive user interfaces, and the ability (or lack of it) of users to adapt to something different.
That sounds like a simple question, doesn’t it? But the answer is not as simple as it seems, as this blog post explains. Usability, according to the post’s author, encompasses:
- Learnability — how easily a beginner can use the system, and how easily they can become an expert.
- Efficiency — how quickly people can achieve what they want.
- Memorability — how easily people can remember how to use the system or feature, after not using it for a while.
- Safety — how rarely people experience errors, and how easy it is to fix any errors.
- Satisfaction — how pleased people are with the overall experience.
To be honest, I never viewed usability from all of those perspectives. Before reading the post, my take on the subject was wrapped up in learnability, efficiency, and satisfaction.
The post makes some good points and is definitely a must read.
Do you have anything to add? Feel free to leave a comment.