Category Archives: Usability

Usability is the science and art of creating a better experience for the users of software. That experience is driven by the choices made during software development. These articles focus on the relevance and applicability of usabilty to all facets of software product success.

Use Cases for Iterative Development

Almost everything I’ve read about use cases focuses on describing what needs to be added to your product.  Agile development says “get it working first, make it better second.”  That means changing the way the software enables a user to do something they can already do.  How do you manage requirements for incremental improvement?

Continue reading Use Cases for Iterative Development

Modeling User Competency

Perpetually intermediate (competent) users.  Users who briefly exist as novice users and never become experts. Most of your users are competent, and you should design for them.  Competent users have different needs and different expectations than novice or expert users.  How do you know your user’s competency levels, so you can design for them?

Continue reading Modeling User Competency

User Adoption ROI

using or bypassing the software

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

Continue reading User Adoption ROI

Global Actor Hierarchies and Personas

Actor Hierarchy

We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.

Continue reading Global Actor Hierarchies and Personas

Foundation Series: Heuristic Evaluation

usability classroom

A heuristic evaluation (or heuristic analysis) is a quick, low-cost usability analysis of the design of a user interface. Pareto’s rule tells us that we can get 80% of the results from 20% of the effort. And that’s where discount usability tests like a heuristic evaluation come in to play. Formal, and more detailed usability studies yield better results – but cost more and take more time. A small investment can pay off big with a heuristic evaluation.

Continue reading Foundation Series: Heuristic Evaluation

Don’t Make Your Products Too Simple


Joshua Ledwell wrote a short article expressing his perspective on designing software that is neither too simple nor too complex. He also links to some excellent other articles on the topic.

Designing For Competent Users

We’ve written in the past about how to design for competent users. In fact, it was Joshua’s link to that article that helped us find his article – thanks! Users start out as novices, and most of them become competent users. Very few of them reach a level of expertise with your product. You need to make sure you support both their growth and their likely “end state” – competence. The feature set needs to support the fact that most users end up in a state of competence.

Maximizing ROI

One of several good links from Joshua’s article took us to Luke’s article on the sweet spot for selling software. Luke references an article from the Harvard Business Review and includes an interesting graph that shows the relationships between the number of features and profitability. In short, more features drive higher initial sales by satisfying the buying persona. Fewer features drive higher eventual sales through word-of-mouth marketing based on improved usability.

The HBR suggests a profit maximizing approach of seeking the middle ground in terms of feature quantity. Trying to please everyone tends to result in pleasing no one, so we don’t have a lot of confidence in this approach. But we still like the graph.

Some great thinking out there, what do y’all think in here?

Software Usability and Learning Curves


Learning curves have been studied for decades when evaluating manufacturing systems and proposing cost reductions. The Boston Consulting Group did an oft-cited analysis in the 1960’s that describes how people get faster at tasks through repetition. Peter Abilla looked at the application of learning curves to writing software. We look at how they apply to using software.

Learning Curves

Wikipedia tells us that the learning curve phenomenon was discovered in the 1800’s by a psychologist, but industrial applications of the concept reference the Boston Consulting Group study on experience curves.

Learning curves describe how people become more efficient through repetition of a task. The experience curve concept extends this idea to organizations, suggesting that overall costs for an operation will drop over time in the same way. People argue about the validity of this – suggesting that economies of scale take over with high volume activities. Regardless, the element of learning still applies.

Learning Curve Explanation

The easiest way to explain the concept is with an example. Consider a task that takes five minutes (300 seconds). Over time, a person will get faster at performing that task. The graph shows the amount of time required to complete the task decreasing with repetition of the task.

To make it more concrete, consider the task to be “Enter an issue into the bug-tracking system.”

classical learning curves

[larger image]

There are three curves in the graph above, labeled 90%, 85%, and 80%. Each curve shows a progressively faster rate of learning. Note that the scale of repetitions is logarithmic. The first time the user enters an issue in the bug tracking system, it takes five minutes. By the thousandth time, the user will spend under two minutes on the “90% curve.”

The percentage-labels of the curve represent the quickness of learning. Each time the number of repetitions doubles, the amount of time a person spends on the task is reduced by the listed percentage.

On the 80% curve, the user will spend 300 seconds on the first issue, 240 seconds on the second issue, 192 seconds on the fourth issue, etc.

Usability Is Important

Usability is an important factor in software development. It may be a challenge to define the usability requirements, but usability affects user satisfaction, and usability sells software.

When investing in usability, you have to take into account how valuable each investment is. Any product will have a number of business use cases, and each use case will have a frequency with which it happens. Usability investments affect two factors of that use case:

  • The initial amount of time it takes.
  • The speed with which someone improves at the task.

ROI of Usability

Once your company reaches stage 5 in corporate usability awareness, you will be prioritizing usability initiatives, and prioritization should be driven by return on investment. That analysis is typically done based on the initial amount of time that a task takes.

Incorporating the element of learning into that analysis will yield a better (and higher) indication of the value of usability investments.

If you’re math-oriented, you’ll notice that the learning curve never really ends (theoretically). You have to “stop” the learning at some point when performing a financial analysis, based on the net present value of future savings. Three years is a realistic time horizon for software (and might even be a little long).

However, you won’t continue to see benefits for three years.

Competent Users

There’s a phenomenon with software – people stop learning when they become competent. Most people get “good enough” to satisfy their own needs, and don’t move on. They don’t become experts, so don’t design for experts, and don’t propose an ROI that assumes that everyone will be an expert.

Grasping Time Horizons

The theoretical learning curve is handy, but you have to do a little more work to make it useful. Consider first the frequency of repetition of the task. Is it a weekly, daily, or more frequent activity? This frequency will determine how quickly (on the calendar) someone will achieve the high levels of repetition that result in improved efficiency.

The following graph shows how an 80% learning curve overlays a calendar for tasks that happen daily, weekly, and hourly.

80% learning curve frequencies

[larger image]

The graph shows that for a weekly frequency, after 16 weeks, the task time has reduced from 300 seconds to 100 seconds. With a daily frequency, the task time is even lower – about 60 seconds. This graph shows nothing other than converting the academic learning curve graph into one that incorporates calendar time and frequency of occurance.

Note the odd, vertical drops in task time during week 1. This is just a manifestation of looking at a weekly time scale. For a task that happens once per hour, the user will rack up 40 repetitions during the first week. From a decision-making standpoint, you don’t have time to react to that rapid rate of learning, so it is ok that it is collapsed on this graph.

Further Limiting The Time Horizon For ROI

There are three vertical, dashed red lines on the graph. The original learning curve theory stays pretty, well, theoretical – using log graphs for a time horizon. This is fine for academics that want to understand the underlying trends and drivers. An ROI analysis brings in a set of relevance constraints driven primarily by the time-value of money.

However, software’s time cycle should limit the time horizon even further in order to be practical.

  • First Impression. Software is often evaluated for usability or suitability based on first impressions. The reduced barrier to entry for many software products makes it extremely easy for a user to say “I’ll download something else – this isn’t good enough” after a couple minutes with the software.
  • End of Training. Other software sales cycles involve training as part of the evaluation period. This is more common with enterprise software, and may be the way your target users (or decision makers) approach the evaluation. Everyone is different. When this is the case, the user’s ability to be effective with the software will be evaluated after some nominal period – perhaps two weeks.
  • End of Attention Span. The competent user phenomenon limits the attention span of most users – they simply stop learning. A realistic way to represent this may be to draw an (admittedly arbitrary) line in the sand at the three-month mark. At this point, users either like the software or they don’t. They’re as good as they’re going to get.


You will have to determine which time horizon is most relevant for your product, customer, and users. That decision will determine the relevance and impact that learning should play in prioritizing usability investments for your product. If your product will thrive or die on first impressions, then the learning curve should be all-but-irrelevant to your decisions. Only the word-of-mouth-marketing factor will come into play. You need to stress investments that lower the initial task times over those that accelerate learning.

8 Stages of Corporate Usability Awareness

Jakob Nielsen identifies 8 levels of adoption of usability by corporations. He calls them the stages of corporate usability maturity. There is definitely a continuum of adoption and appreciation for usability in companies today. By understanding the eight levels we can determine how best to increase the commitment to usability on our projects.


Nielsen describes maturity stages 1-4 and 5-8 in separate articles, found via his blog.

1 Stage 1: Hostility Towards Usability

The system determines how people will use it. Developers are not interested in focusing on how people will want to use the software. At most, developers can be convinced to help write the doc. The focus is on teaching users how the software works, not writing the software to work like the users.

stage 2 Stage 2: Developer Centered Usability

Members of the development team develop an awareness of usability, conceptually. Unfortunately, developers approach software very differently. Cooper calls programmers homo-logicus, to distinguish them from actual human users. Because programmers understand how computers work, they have very different expectations than everyone else.

Stage 2 may be effective if you’re writing software for other developers. The designers working on eclipse and subversion don’t need to design it “for your mom.” So when they incorporate usability from their own perspective, it will at least have a lot of overlap with the perspective of the target users.

Developers want to achieve software product success. Your team just needs to be asked to think about how they would use the software. One strategy that may work is to present two perspectives: inside-out and outside-in.

Inside-Out Design

Think of the earliest automobiles. The driver had to get in front of the car and crank start it – because that’s where the drive shaft was. They had to pull on a hand brake to stop the car because that’s how the brakes worked. Neither was a particularly usable design. The “under the hood” engineers built it so it would work, and then “interface guys” connected an interface to the inner workings.

Outside-In Design

Now think about the Dick Tracy wrist-communicator. An artist designed what it would do, how big it was, and how to use it. Then engineers spent the next few decades figuring out how to squeeze radio-transmitted video signal hardware (and a camera) inside the form factor. This is outside-in design.

stage 3 Stage 3: Skunkworks Usability

The outside-in concept begins to take root “under the radar” on projects within your company. Some representative users are brought in to provide feedback on designs. Usability testing has an impact on some projects.

Nielsen points out the distinction between this level and higher levels – funding and recognition. At this point, it is starting to happen naturally, but it is neither funded nor actively promoted.

To get from stage 2 to stage 3, find some receptive team members, and buy them a book or two on usability or interaction design. Send them to Neilsen’s website, or Kathy Sierra’s or even our usability articles archive which links to those sites and others.

stage 4 Stage 4: Dedicated Usability Budget

Usability becomes intentional and systemic. Your company has usability funding for its projects and usability testing becomes widespread. Nielsen describes the attitude succinctly:

At this stage, the company mainly views usability as a magic potion that’s sprinkled sparsely over a user interface to shine it up.

You might reach stage 4 because an exec makes a connection between the magic potion and the success of a stage-3 project that applied usability. Instead of hoping that will happen, convince your managers of the importance of funding – get a stage-3 project, demonstrate the benefits, and then expand.

Neilsen also adds:

you can’t help but make dramatic improvements the first time you do a bit of usability on a project

This should be an easy sell.

stae 5 Stage 5: Managed Usability

Your company now has a usability group with a charter. The usability team, while still focused primarily on user-testing, is beginning to approach projects more consistently. They keep records of results, learn from each other, and begin introspectively improving.

Nielsen also makes the distinction that at stage 5 there is a person responsible for usability thought-leadership across the company.

If anyone has successfully helped their company move from stage 4 to stage 5, please share how you did it in the comments. We haven’t been involved in this transition before, and would be inclined to use the same methods we use to reach stage 4 – only more so. There are surely better ideas (or failed ideas) out there that everyone can learn from. Tell us all in the comments on this article.

stage 6 Stage 6: Systematic Usability Process

A formal user-centric design process is in place. Your company is tracking the quality of usability across projects and identifying trends. The usability budget is big enough that key projects get the needed funding.
stage 7 Stage 7: Integrated User-Centered Design

Your company is now doing pre-emptive field studies or working with companies like Expero, Inc. to help them. [Disclosure: I’ve worked with Dr. Morkes, one of the founders, in the past, and he’s awesome.] Nielsen also suggests that tracking of usability results is becoming quantitative instead of qualitative.

We think the notion of improving user-understanding before projects start is the key distinction.

stage 8 Stage 8: User Driven Corporation

The company evolves into one where attention to the user-experience affects not only all projects, but corporate strategy. Perhaps your company looks for opportunities based on usability issues with current solution approaches. Usability extends beyond product development decisions and into other areas of the company – anything customer facing, for example.


This is a long and valuable path. Nielsen concludes that it can take a company 20 years to move from stage 2 to stage 7, and perhaps another 20 to reach stage 8. Some companies, like 37signals seem to buck the trend by starting out with a high level of user focus. Perhaps the founders get credit for previous experiences at other companies?

Wherever you are, the next stage is clearly better. Focus on that. And come back here to reread the list every few years :).