Typically, organizations progress through a sequence of stages as their usability processes evolve and mature. Because the sequence is fairly universal, you can match your own organization with the following descriptions to see what your next stage is likely to be.
Stage 1: Hostility Toward Usability
The initial stage is characterized by the slogan, "A good user is a dead user." Developers simply don't want to hear about users or their needs; their only goal is to build features and make them work on the computer. In this mindset, humans are irrelevant — they're told to use the system, regardless of whether doing so is easy or pleasant.
In computing's early days (1945-1965), this was the most cost-effective approach to most projects. Hardware was so expensive that it made sense to subjugate people to the computer's needs.
Around 1965, computers became cheaper and enough people were using them that we started to see economic returns from reducing training costs and increasing user productivity. Usability started showing positive ROI in the few companies that used it, but hostility toward usability predominated in most IT shops until the 1980s.
Even today, there's a school of Web design that ignores users under the assumption that it's better to oppress users and turn the Web into television.
If your company is at the hostility stage, you can forget about promoting usability. People have to want to change before there's any chance of helping them do so. Once the company's been sufficiently hurt by its Neanderthal attitudes, management will be ready to consider usability and enter the next stage.
Stage 2: Developer-Centered Usability
Sooner or later, most companies realize the value of making designs easier for humans to use. At this point, the most obvious (but erroneous) approach is for the design team to rely on its own intuition about what constitutes good usability.
After all, the team members are human beings, and they use computers and websites. Surely they know whether something is easy to use or not. The existing team members also have one huge benefit: they're already onboard and participate in every project meeting, where they're not shy about sharing their design opinions.
This approach works reasonably well for one class of design problem: developing tools, such as Web servers, for developers or other geeks. Open-source projects like Perl, Linux, and Apache have had great success with developer-centered design. But even these projects could have been better with more systematic usability input from people outside the design team. Programmers who work on Apache's guts have a deeper understanding of it than other technical experts who only want to use Apache, not hack it.
For projects targeting non-geek audiences, it's disastrous to rely on the design team's understanding of what's easy. Anyone working on a project knows much too much about it to represent outside users.
Luckily, the difference between a team member's conceptual model and that of average users is easy to explain. It's also an easy pill for team members to swallow, because you're basically telling them that they're too smart and knowledgeable to stand in for the average user.
At stage 2, you have a huge advantage: people care about usability. That said, you're still likely to get lip service from high-level executives, who'll make announcements like "good user experience is a high priority" while failing to actually fund usability work. So, while you can't go directly from stage 2 to an elaborate usability process, you are likely to find people receptive to the logic of usability. These people will also show some willingness to move to stage 3 — if you keep pushing.
Stage 3: Skunkworks Usability
At this stage, the organization realizes that it shouldn't rely on the design team's personal judgment of what will be easy for customers to use. Most design decisions will continue to rely on this judgment, however, because people tend to assume they are both archetypal and the focal point of the universe. Thus, even while designers know they should get external data, they don't try very hard to acquire it.
Despite all the barriers, at this stage, a few groups within the company will initiate small usability efforts. Perhaps someone will recruit a handful of users for a simple test. Or perhaps a manager will hire an external usability expert for the company's first-ever independent assessment of user-experience quality.
What distinguishes this stage from higher levels is that there's no official recognition of usability, nor is there an approved budget allocated in advance. All usability activities are ad hoc and driven by user advocates who want a bit more data to improve the quality of the one thing they're working on at the moment.
Primitive as it is, skunkworks usability is effective. (The sidebar shows an example in which testing just two users increased the probability of picking the better of two designs from 50% to 76%.) Even tiny usability efforts can't help but create vast user-experience improvements in a company that hasn't done usability before. The old cliché of "low-hanging fruit" always holds true in such cases.
When moving from stage 2 to stage 3, you can rely on logic — and maybe a bit of flattery — to convince design team members that they're far too knowledgeable to represent average customers. In moving upward from stage 3, however, you have to rely on results.
When designs get a small usability injection, they get better — hopefully so much better that the results are clear to anybody. The only downside is that really great usability seems so obvious (after the fact) that management might not recognize how much work was required to simplify the design. To prevent being overlooked, save the initial design ideas, clumsy as they may seem, and show before/after comparisons to document the usability advances.
Stage 4: Dedicated Usability Budget
Maybe a manager who funded a bit of usability from the slush fund gets promoted to director with a bigger budget. Or maybe a big-shot VP decides to place higher priority on the usability aspects of product quality. Several scenarios can cause a company to invest more in usability. Typically, the primary cause is that some of stage 3's small, ad-hoc usability projects caught the eyes of the higher-ups and convinced them that the company will profit from improving the user experience.
The big difference between stages 3 and 4 is a dedicated budget for usability. However small, the budget is set aside in advance, meaning that usability is planned for in the same way as other quality processes.
Depending on the company's size, the usability budget might cover only a percentage of a single employee's time or it might allow for a few full-time usability specialists. In either case, the usability staff is scattered around the company and doesn't use have any systematic processes in place. But at least they have usability in their job description and a pot of money for things like recruiting test users (which costs an average of $171 per user).
At this stage, the company mainly views usability as a magic potion that's sprinkled sparsely over a user interface to shine it up. The main usability method is user testing, which is invariably conducted late in the development process after the user interface has been at least partially implemented.
This is contrary to recommended best practices, which call for frequent and early testing, including the use of paper prototypes that teams can test without the sunk cost of a full-scale design implementation. The more work that goes into implementing a user interface, the less willing management will be to make the architectural changes that are typically needed after the design is first exposed to real users.
To move up from stage 4, even more proof of ROI is needed. Moving from stage 3 to stage 4, it's fairly easy to deliver credible results: you can't help but make dramatic improvements the first time you do a bit of usability on a project. And, with skunkworks funding, those advances come cheaply.
With a real budget, you need bigger improvements to justify increased usability investments. Because usability methods have astoundingly high ROI, those big improvements will come, but it will take some time. You need more than a couple of success stories. You need several fielded products with higher conversion rates, fewer calls to the support lines, better intranet productivity, or whatever business measure is salient for your company.
Collect results across your usability projects and eventually you'll have enough ammunition to make the business case for moving to stage 5: managed usability.
Stages 5–8: Next Column
At stage 4, the company has started getting serious about usability, but it still has far to go before it reaches ultimate maturity at stage 8. Although stage 4 is the halfway point numerically, progressing through the remaining stages usually takes much longer than moving through the first four.
In the follow-up column, I discuss why this is so and how your company can continue its ascent.