In the original Tron movie, the programs saw users as their gods, essentially. In that movie, when a program dies, he casts his eyes to heaven and cries, “Oh, my User!”
Obviously, the concept of the user as a god doesn’t exist in reality, and the idea that our programs should treat us as gods has essentially vanished. No application is truly subservient to your needs — in fact, that sentiment might have died with Clippy, the helpful paperclip. If anything, software developers create applications with the idea that the user is subservient to it. Create the basic functionality with no regard to ease-of-use, and if the user has difficulty, that’s their problem: if it works somehow, more or less, then the developer’s job is done.
While this is usually how software is made, this isn’t how good software is made. This is how useful software products fail, in fact. You can have the most functionally complete application ever created, but if you ask your user to fill in too many gaps, to do too much work to make your tools useful, then you might as well not have any product at all. If you want to create usable software, as opposed to useful software, then you have to keep your user in your mind with every line of code.
But who are your users? You know by talking to your customers that some are more technically competent than others. As much as you’d like to give the middle finger to anyone you don’t consider your intellectual equal, they are the reason you have a job. Your job is to write tools for actual users. So your job is to first understand who these users are.
No, they aren’t one homogenous mass of people with wallets. Each approaches your product with their own skill level and background. However, if you look carefully, you can break down the user base into three distinct groups, and focus your efforts accordingly.
First, and most obviously, there are the Beginners. Beginners have no extensive experience with computers or software in general, and they need a crapload of hand-holding. A subset of these are the ones who attack the software with no experience and no desire to read the manual — the needy users. Another subset will rely entirely on phoning tech support. Despite the fact that you speak to the needy users more than anyone else, these are a tiny minority. If you’ve designed your software correctly, the majority of Beginners will be able to intuitively understand how to use the tools you provided.
Second, we have the Skilled users. These are the ones who have spent enough days using your product that they’ve moved on from simple “how to” questions to advanced questions of how to affect the best use of your product. If you have a basic user manual, chances are, they are way beyond it already. Now they need advice on specific use-case scenarios and implementations. If you don’t cover these issues in your manual, these questions will inevitably fall to tech support and end up costing you money.
Finally, we have the Advanced users. These are the users you love, because they don’t actually need help. In fact, they’ve used your software so much, they can inform you as to what changes you need to make for future releases. It’s important to listen to these users, but at the same time, avoid being guided too much by their needs, because their needs by definition don’t match the needs of the vast majority of your user base.
So those are your users: Beginners, Skilled, and Advanced. If you design your product with the user in mind, which user are you designing for when the needs of each group is vastly different? Let’s focus on the learning timeline, because it’s clear that Beginners don’t stay Beginners forever; eventually, they’ll become Skilled. In fact, it’s likely that they’ll only remain fumbling, needy Beginners for a week or so before they master the basic skills and move on to more advanced issues. Advanced users are a tiny subset that could really master any interface in spite of even vast usability problems, while at the same time informing you of the problems as they work.
The group that you need to focus on is the Skilled group. Every day, these individuals sit down and use your product to solve problems. Your task is to make their life easier. And if you’ve designed your user interface right, you’ve eliminated the pain of repetitive tasks, and streamlined daily activities based on what they need. In terms of documentation, your manual provides tips on how to improve their work flow, rather than focusing on clicks and menus.
The ideal software is easy to approach for the Beginners, provides obvious benefits to the Skilled, and is open-ended enough to allow Advanced users to expand on what you started. If any of these users needs to read the manual to perform any basic function, then you’ll know that you screwed up the interface. A user’s experience both begins and ends with the interface. User experience is the alpha and omega of interface design, and for that reason, if you haven’t once said, “Oh, my User!” then you’re doing something wrong.
