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?

User Competency

User competency is a concept I first read about in Alan Cooper’s The Inmates Are Running The Asylum.  Cooper’s contention is that the level of expertise of your users follows a bell curve, or normal distribution.

When we’re designing software we need to keep in mind that most of our users will be competent – neither experts nor beginners. Alan Cooper’s studies tell us that user skill levels follow a bell curve. He talks about competent users as perpetual intermediates. Some users drop out of the bell curve when they stop using our software. The rare user becomes an expert. Most users only learn enough to get their real job done.
Competent Users and Software Requirements

Cooper contends that the combination of learning curves and natural user tendencies to stop learning or abandon a software application are the sources of this distribution of user competency.

Experience Curves

Experience curves represent the diminishing costs over time of manufacturing something repeatedly.  The process of manufacturing something gets more efficient as you get smarter about the process.  The process of using software is at least analogous to, if not a specific example of a manufacturing process.  If you’re using an email application, you are manufacturing email messages.  In a CRM system, you are manufacturing contacts, or contact reports, etc.

By treating any “using the software to do something” interactions as a process, you can measure the cost (how long it takes) of the user’s interactions.  Applying the math behind experience curves, you can predict the reduction in cost (to your users) over time, for any set of interactions.  Experience curves take into account that some processes are inherently more learnable than others.  This property of learnability is reflected as an efficiency coefficient – how efficiently someone can learn ways to reduce the cost (time) needed to perform the interactions.

This gives us an approach to quantitatively model user competency.  Having a definition allows us to model competence.  And measuring competence allows us to manage product design in the context of user competency - designing for competent users.

Defining Competence

The first step to measuring competency is to define the model.  I am proposing a definition in this article that I suspect will yield insights (to help us manage our products). I was unable to find any quantified definitions of competence, when researching it as part of a client engagement.  If you have, or know of a model, please share it in the discussion below this article.

• A competent user is someone who learns to perform a task in half the time it initially took them.
• An expert user is someone who can complete a task in 10% of the initial time.

This definition is guided by an expectation that Alan Cooper’s premise about perpetually intermediate users is true.  Being a novice user is a very transient state, and becoming an expert is very infrequent.  The goal of the definition is to be able to segment your users and make well-informed design decisions.

A Proposal, Not a Doctrine

This is a proposal that doubling performance reflects competence, and achieving a ten-times improvement represents expertise.  It may be that some different measure of performance improvement more accurately reflects competence and expertise.  We have to test it to know.

The experience curve is defined mathematically by Henderson’s Law.  It states that the time to complete a task is a function of the number of times you have previously done that task, adjusted by the “elasticity” of the cost of that task.  In other words, some tasks are easier to improve than others.  If you populate a table with the results of applying Henderson’s Law, you get the following:

[larger image]

• Each row in the table represents the Nth repetition of a task.
• Each column represents how easy that task is to learn – progressing from “hard to improve” on the left, to “easy to improve” on the right.
• Each cell in the table represents how long it would take to perform the Nth repetition of the task, as a function of how easy it is to improve your performance at the task.

The above definitions represent what experience curves predict mathematically, when the task initially takes 60 seconds.  The following definitions reflect the proposed user competency model:

• A user is a novice user until she has learned enough to cut the time-on-task in half.  These cells have a white background (and are in the upper left area of the table).
• A user is a competent user when the time needed to complete the task is between one half and one tenth of the initial time.  These cells are shown with a yellow background (and are in the central area of the table).
• A user is an expert user when she can complete the task in less than one tenth of the time required to initially complete the task.  Theses cells are shown with a red background (and are in the lower right area of the table).

In the absence of empirical data, I used my intuition to suggest that a representative experience curve for a typical task performed in software would be one with an “elasticity” of 50%.  For a task with those learning characteristics:

• A novice user would cut the needed time in half on the 4th repetition of the task, and would be considered to be a competent user.
• A competent user would further reduce the time needed to one tenth of the initial time on the 100th repetition of the task, and would be considered an expert user.
• The 50% elasticity column is surrounded by a black border, and the number of repetitions required to advance to competent or expert status is also highlighted with a black border.

Inferring Competence

Since different processes have different learning characteristics, you have to figure out how easy it is for your users to improve at your processes.  To do that, you have to study (or at least measure) your users’ interactions with your software.  In the 50% curve highlighted above, a user is capable of cutting their time-on-task in half by the fourth time they perform the task.

If data from your initial testing (or measurement) reveals this to be true, then you have selected the correct curve (the correct column in the table).  If it takes more or less time to reach this level of improvement, shift to the left or right to find the appropriate curve.  If software-interactions are reasonable analogs to manufacturing processes, then the experience curve projects an expected rate of improvement on task.

The following graph isolates the time-on-task data for a user who is learning to improve when repeating a task (process) that matches the 50% elasticity curve.

[larger image]

Note that the number of repetitions of the task (the X axis) is represented as a logarithmic scale.  The data points along the curve correspond to the cell values in the table above (for the 50% column).

Shades of Gray

One nice thing about this quantitative approach to inferring competency by measuring usage is that your measurements are per-process.  Users are not “purely novice” or “purely expert” – they can be experts at some processes, while remaining neophytes at other.  There is also awareness, for any particular process, of “how much competency” a user has.  This allows you to refine your assumptions of the steepness of the learning curve, and of the thresholds (doubled performance and ten-times performance improvements).

Improvement Over Time

Any particular learning curve can be considered relative to calendar time, to see how quickly a user will progress along the curve (as a function of frequency of use).  This can be useful for determining the ROI of improvement in a particular process.

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

[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 occurrence.

Software Usability and Learning Curves

One approach to inferring user competency would be to measure how long a user has been using your software.  The variation in how frequently different users perform the same task will introduce an error into that inference.  You can avoid introducing that error into your modeling by counting the number of times a user has performed a task.

Applying the User Competency Model

The advice in previous articles, and from Cooper’s book, and from this great article on the  Coding Horror site, encourages us to focus on the competent users.

I’m working with a client who needs to prioritize a set of capabilities and establish design principles for a product.  We will incorporate this user competency model as part of our analysis.

Hopefully we’ll have an opportunity to collect data to validate and / or refine the model.  I’m proposing that we first gain some insight into the which users (novice, competent, expert) drive the most revenue and profit from use of the product – to establish the importance of each category of user.

For this product, I suspect that we will find many more novice users than a normal distribution would predict.  If that is true, the next question will be to understand if we are dealing with a normal behavioral dynamic, or if characteristics of the current product “force” novice users to abandon it before they achieve competence.

Either way, we will have a framework for prioritizing the goals of the novice, competent, and expert users.

How would you apply a model like this to improving your product?

Netlife Research brings us the 2009 Bad Usability calendar.  Get it while it’s hot.

Download it from the 2009 bad usability calendar page on their website.  Or check out our article from last year for the 2007-2008 bad usability calendars.  They really do have some great points to make.  Two in particular got my attention this year – any guesses which months?

Last year, over 100K copies were downloaded.  Act now and be on the bleeding edge of the first 2% to download for 2009.

Netlife Research (company website in Norwegian) has done it again. Their 2008 Bad Usability Calendar is here and it is great. So great that it is hard to pick a favorite. Download it here. 2007 has more great examples.

[Note: This is a short post- just got back from the Velvet Revolver concert at Stubb's. Living in Austin rocks!]

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.

The ROI of User Adoption

The image above is great – it shows one person choosing to use the software, and one person choosing to do the work by hand instead. It is a classic user adoption problem. The good thing about it is that you can talk in concrete terms about the goals of your software, and how user adoption plays a role.

Let’s start with a definition of return on investment (and read the full article for more details and examples)

ROI is the acronym for return on investment. Another way to think of it is “How much profit will we make if we invest in this project?” Profit is revenue minus costs. Technically, the question should be “How much profit will we make, relative to our investment, if we invest in this project?”

Definition of ROI – Return on Investment

OK, with a definition of ROI, you have to develop a model for return, and one for investment. The model for investment is built by looking at the cost of developing the software. That defines how much it costs. Assume it costs $1,000,000 to develop and deploy the solution.

The model for return is a little more complicated.

For our user adoption example, assume that the software saves the company $1 every time it is used, relative to whatever the company does in the absence of the software. There are several ways to calculate the ROI of design, we’re picking one Assume we have 1000 users, each of whom would use (or not use) the software 10 times per day. That is a potential savings of $10,000 per day. Call it $2,000,000 per year once all the users are using it all the time.

Unfortunately, many people stop there. They see a 6-month payback period, they fund the project, and they stop thinking about it – the money is already in the bank. But you’re not going to do that.

Imagine that this is your project. You write perfect requirements, you have an excellent development team, and the software works perfectly – saving a dollar every time it is used. The problem is, only 100 people are willing to use the software. Now, instead of a 6-month payback period, it takes five years to recover the cost of developing the software.

The False Promise of the Mandate

“Not a problem for us,” you say. “Everyone must use the software. Or they’re fired!”

Many corporate IT departments work this way. The business tells them what they need (“Save us a dollar!”), and the IT guys gather requirements, develop a perfect application and confirm that it saves a dollar every time someone uses it. And then they mandate that everyone use it. Simple. 6-month payback.

There are a couple problems with this approach.

1. Not everyone uses it right away, even if everyone is required to use it.
2. Not everyone uses it effectively, even when required to use it.

The explanation is a little less obvious, but the brutal reality of it is just as true.

Delayed User Adoption

You issue a mandate – all 1000 users will use the software! The users are conveniently spread out into 10 business units, each with 100 users. One of those business units will go first. And your software is a disaster (we’ll get to #2 in a minute). The plan was to pilot the software with the first 100 users, then roll it out a month later to the other 900. No problem – 7 month payback, and less risk to the business.

The problem is that the people running the business units – and thereby managing the users – are smart too. They see the train wreck that Tom’s department became, and they refuse to use the software. They have their own financial targets, and they don’t want to jeopardize them. These business unit directors, if they lack the power, will escalate, until their demands are heard.

What’s the first place in the hierarchy where there’s a common manager? Is it the CEO? Maybe you’re lucky, and it is only a couple VP’s arguing about it. What conclusion do you think they will reach when presented with the following arguments:

• If we use the software, we will miss our numbers – it slows people down. And that will cost you $X.
• But we want them to use the software – they have to. If they were smarter, it would save money

Even if the argument isn’t accurate – who will win? Best case, your roll-out is delayed. Worst case, it is killed before it ever gets a chance to work.

Ineffective User Adoption

It turns out, after watching the pilot group, that expert users can in fact save a dollar every time. Competent users break even – there’s no savings for them. And beginners were better off with the old solution. It was less efficient, but the new way is so hard that they can’t do it well.

You’ve mandated that people use the software. Since they didn’t otherwise want to use it, you had to spend a bunch of energy (and money, in opportunity cost) to make it happen. The rollout was delayed, and at the end of the day, you break even. Most users have no savings, and the few that do are offset by those that caused an increase in cost.

Mandating user adoption creates a false sense of confidence, and does not assure ROI – it only assures adoption. We’ll say that again, to let it sink in.

Mandating user adoption does not assure ROI – it only assures adoption.

So what can you do?

Measuring User Adoption

As product managers who care about user adoption, our first thought is “measure it!” The biggest challenge is in measuring the right thing.

We can’t just measure how many clicks, because while that might correlate with ease of use – it does not necessarily cause increased user adoption.

To stay aligned with the ROI model, we have to measure, directly, that user adoption is meeting the forecast used to create the ROI model. The only measurement that is assured to be an accurate reflection of user adoption is measurement of user adoption directly.

Prevent Mistakes, Then Monitor Them

If we measure poor user adoption after it has proven to be inadequate, that doesn’t help very much. It is generally accepted that a good design leads to higher user adoption rates. In the case of the “false mandate,” good design yields faster roll-outs and allows more users to be more effective with the software.

There are also other reasons to invest in good design.

The right solution is to invest in good design – targeting competent users (not novice users) to achieve the desired ROI. A good design is easier to learn too. You can track the rate of improvement among users.

Here’s a chart from an article that goes into learning curves in more depth:

[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.

Software Usability and Learning Curves

Thanks, now go hire some designers and achieve your ROI!

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.

Why Actor Hierarchies?

User-centered, or user-centric design is an approach to developing software that focuses, as the name implies, on the users of the system. When designing the solution – and more importantly, when defining the requirements for the system, special attention is placed on the users of the system. More specifically, center stage is devoted to developing software that helps the users accomplish their goals.

From a requirements perspective, the key is to acknowledge that there are different types of users, doing different types of work with the software. It is reasonable to conclude that they will have different needs. An actor hierarchy provides a way to organize the different needs of the people doing different jobs. [Note: These are the same actors that are identified in use cases.]

A Simple Actor Hierarchy

Let’s start by creating a simple actor hierarchy. We’ll build on this incrementally as we add more complexity to our user base. We’ll look at a hierarchy for sales representatives (reps) for a company that manufactures goods for sale to other businesses. Each business to which the company sells products is known as an account.

The hierarchy represents an approach to classification of sales reps. Each successive level of the hierarchy is more specific than the previous level. All employees who sell products are considered to be sales reps (the top level in the hierarchy). When the company sells products to its accounts, it is not always obvious which products should be sold. In those cases, an engineer is brought in to help determine the exact need, and suggest the right products to sell. This engineer is known as a technical sales rep and the technical sales rep works with an account rep to determine the right products and terms to close the deal. The account rep is responsible for making the individual sale, and occasionally gets help from the technical sales rep to do it.

The hierarchy shows that all sales reps are either technical reps or account reps. If an employee is a sales rep, then he must be one of the two choices.

Account reps are further divided into two groups – representatives who work with large accounts, and reps who work with small accounts. The company currently considers accounts that make more than $500,000 in purchases per year to be large accounts, and the rest are small accounts. The main difference in behavior is that a large account rep works with only one customer – and in fact, for really large accounts, there may be multiple representatives for a single account. Small account reps, however, each work with more than one account, maybe even dozens of accounts.

You could argue, in the abstract, that large and small account reps should not be treated as different types of actors – because they all manage relationships with customers and sell products. However, there is enough of a difference (in our hypothetical example) between the jobs of the two types of reps that it is worth treating them as separate actors.

In our example, the large account reps are focused on account retention, and maintaining relationships with a single customer. These reps are focused on account retention and are usually managing the upgrade cycle for their customers. The upgrade cycle is when a customer replaces their existing, worn out or obsolete equipment with new equipment. Small account reps might be working with really large potential customers who currently buy from the competition. These small account reps are focused on acquisition and growth. They are also trying to manage and create relationships in an attempt to grow the customers until they become large accounts. Small account reps are also managing multiple customers, and have additional activities associated with managing that complexity.

Global User Base

The situation above describes how the company (or if you have a product management hat on – the companies in the target market segment) organizes their sales force in one region. What do you do when the the company has operations around the world? If all global operations are the same, then you don’t do anything. It is a rare company that works this way. Most global companies have grown their regional businesses (where a region might be Europe or Asia, or it might be China or India) independently. This could be do to growth by acquisition, or the parallel growth of separate regions managed separately.

In different regions, companies often have different business models. They also usually deal with customers in different ways. These differences may manifest from varied local business practices, different characteristics of the customers, or different levels of maturity in the market for the products being sold. There are also differences in regional regulations, policies, and laws – although you should generally manage those as variations in business rules, not business practices. We’ll side-step that layer of complexity for the purposes of this article. Pretend that the same laws, policies, and regulations are in effect in all of the regions.

The same general actor hierarchy can serve to represent the sales reps in multiple regions, with some modifications to account for the differences. Consider for our example, that the company sells products both in North America and in Latin America. The actor hierarchy above describes how the sales team in North America. The company’s operations are a little bit different in Latin America (for our example).

Latin American operations are relatively new to the company. Where the company has a well established market in North America, it has relatively low market share but very rapid growth in Latin America. As a result of the way the company’s business has evolved in the two different regions, there are two distinct differences between the two regions in the way that sales reps are organized.

1. Technical Sales Reps. In North America, technical sales reps (TSRs) are salaried employees, who participate in a profit sharing program. In Latin America, the technical sales reps have a base salary, but sales-commissions make up a large portion of their compensation. The North American TSRs are therefore incented to propose solutions that are highly profitable (thus increasing their profit sharing bonuses). The Latin American TSRs are incented to propose solutions that may sacrifice profitability in exchange for increased revenue (thus increasing their commissions) .
2. Small Account Reps. In North America, small account reps, like all account reps, are employees of the company, and work on commission. In Latin America, small account reps are not employees of the company. Small account reps are third-party sales people. The model is very similar to independent insurance agents. The small account reps, when trying to bid on a job, can propose solutions from the company or from one of the competitors. The third party small account rep also gets to set the price that his customer will pay for the products, and negotiate the price that the company will accept – pocketing the difference.

In both situations, the user populations are different, and will behave differently. The TSRs in both regions do fundamentally the same work – but with different motivations. The Small account reps in Latin America, are markedly different from the ones in North America – in motivation, relationship with the company, and the work that they do.

Using Personas To Express Regional Differences

Personas provide an effective way to describe archetypes of classes of users. Persona development is a key component of the interaction design process, but it can be leveraged very effectively in a traditional requirements process as well. Each persona represents a homogeneous population of users. In other words, the collection of users that are in a role represented by a single actor, and who have similar personal goals. By defining personas, we can manage requirements in the context of those personal goals. One actor in the actor hierarchy may have multiple personas associated with it. This makes sense when there are groups of individuals with different personal goals.

The most common example, and one that is almost always present, is built around the notion of user experience. You can classify users of a product as novice, competent, or expert users. Novice users usually become competent users but rarely become expert users. Those people who become expert users are usually a different breed. Professional drivers become experts, where casual drivers rarely exceed competence.

These two user groups are made up of people with different goals, who use cars differently (even though they both drive, they drive differently, and with differing expectations and needs). It is critical to separate user groups that are different, and treat them differently, to avoid the elastic user problem.

The two different technical sales rep (TSR) populations – in Latin America and North America – would be best represented as two different personas. The TSRs in both regions do fundamentally the same work – provide technical support to an account rep, to help in closing a sale. The North American TSR is profit motivated, where the Latin American TSR is motivated by increasing revenue. These different goals make it very unlikely that the same persona would accurately describe the TSR population in both regions. There are other factors that drive the identification of multiple personas for the same role (in the actor hierarchy), but to simplify, we are focusing just on the regional dynamic.

Since the TSRs in both North and Latin America are performing the same job, it does not make sense to treat them as having different roles in the actor hierarchy.

Using Additional Roles in the Hierarchy to Express Regional Differences

In situations like with the Small Account Reps in North and Latin America, it is better to create distinct roles in the actor hierarchy to represent them.

The North American Small Account Rep works on commission and is an employee of the company. This rep is focused on closing the deal, but only with products from the company. This rep also may work with other reps to help them close deals – sharing intelligence about market pricing, helping with product selection, etc. There are elements of teamwork and collaboration present because all of the reps are “on the same team.”

In Latin America, the Small Account Rep is also focused on closing the deal. But this rep does not care who’s products are used to close the deal. The rep will work to get the lowest possible price from the company, in order to maximize the difference between the company’s price (to the rep) and the rep’s price (to the customer). 100% of this difference goes to the rep, so even if the rep is handsomely rewarded or commissioned based on transaction margin, the rep will always make more money by negotiating a lower price from the company. The rep also has additional activities associated with getting quotes from the competition and managing relationships with the company’s competitors.

Not only are the jobs different, but the company will treat these two reps very differently. For example, the company would be likely to share cost or margin information with the North American rep. That information will help the rep know how low he can price products for the customer without jeopardizing the company’s profitability. The company knows that the rep wants to close the deal at the highest possible price, to increase margins and therefore increase the rep’s compensation.

The company will not want to share cost information with the Latin American rep. The company is still motivated to get the most profitable deals, but the company realizes that the rep is trying to get the lowest possible price – not the highest possible price. This means that the company needs to provide low enough pricing for the rep to close the deal, and low enough pricing that the rep will resell the company’s products instead of products from the competition.

Summary

Actor hierarchies provide a way to differentiate groups of people who have different roles. Personas provide a way to describe groups of people within a role who share motivation and characteristics. The combination of the two allows for clear, yet flexible expression of requirements – both from a business perspective, and from a user perspective.

When dealing with user populations in different regions of the world, it makes sense to extend the actor hierarchy when the jobs, and business requirements of the user populations vary. When the users are doing the same job, but with different motivations, using personas to describe the differences makes more sense.

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.

Heuristic Evaluation

The Nielsen Norman Group defines heuristic evaluation as follows:

Heuristic evaluation is the most popular of the usability inspection methods. Heuristic evaluation is done as a systematic inspection of a user interface design for usability. The goal of heuristic evaluation is to find the usability problems in the design so that they can be attended to as part of an iterative design process. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the “heuristics”).

Jakob Nielsen

Relative Usefulness of Usability Methods

In another article of Nielsen’s, we see the results of surveys about different usability methods and their usefulness. One of the figures from that article shows this stunning graph.

[source: Technology Transfer of Heuristic Evaluation and Usability Inspection, Jakob Nielsen]

While user testing is the clear winner – both in usefulness and adoption, heuristic evaluation is a close second. The two of them are reportedly much more effective than all of the other tests.

Ten Usability Heuristics

Nielsen also shares with us a list of ten usability heuristics, or general principles to guide user interface design. His list goes into more detail on each of the ten heuristics, essentially answering the following questions. You can think of it as a checklist.

1. Does the system provide information about its status? ["Please wait while the system is updating"]
2. Does the system use terms and language that are familiar to the user?
3. Can mistakes easily be undone? ["Undo" and "How do I get back to where I was from here?"]
4. Does the system use controls (buttons, links, words) to enable actions consistently ["Yes" vs. "OK" vs. "Apply"]
5. Does the system help prevent common user errors?
6. Is it easy for users to see what they can do, versus being forced to remember what they can do?
7. Are there ways for expert users to be more efficient than novice users?
8. Are users forced to filter out irrelevant information (minimalist design)?
9. Do error messages help users to resolve the errors?
10. Is the documentation searchable, task-centric, and precise with “how to” steps?

These are fantastic questions to answer (and there’s a right answer for each one). And they also represent very easy to understand ideas – which can be very helpful when trying to explain it to someone who thinks that HCI folks just make applications “sexy.”

Summary

Really bad user interface mistakes can be avoided quickly with heuristic evaluations. This is the best bang for the buck, when determining how to invest in user experience efforts.

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?

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.”

[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.

[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.

Conclusion

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.

Reference

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

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: 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: 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: 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.

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: 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: 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: 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.

Conclusion

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 :).

There is such a thing as too much choice. For new users, too much choice (or control) is too much. For experienced users, too little choice is a problem. Ease of use usually comes from reduced control – but users don’t stay “new” for long. There’s a “canyon of pain” to quote Kathy Sierra in that transition from “new” to “experienced.” We call them “competent” users and we have to help them cross the canyon of pain.

Kathy’s Canyon of Pain

In her article on how much user control is too much?, Kathy talks about how hard it is to make the transition from a new user to an experienced user. We twist that idea into a discussion of feature prioritization. To illustrate her point, Kathy uses a great visual to get the point across.

On the other extreme is Apple’s iMovie. It gives you almost no control, but the payoff is high right out of the shrinkwrap. It exceeds my expectations of pain-to-payoff. But pretty quickly, anyone who gets into iMovie–and is bitten by the movie-making bug–starts wanting things that iMovie doesn’t let you control. So… Apple says, “not to worry — we have Final Cut Express HD for just $299″. The problem is, the learning curve jump from iMovie to Final Cut Express is DRASTIC. There needs to be something in the middle, to smooth that transition.

Kathy Sierra, How much control should our users have?

This is a fantastic visual, and allows us to steal an idea from market segmentation.

Market Segmentation Model

We presented the following chart in an article about how Microsoft is segmenting the market for Visual Studio (a software development environment).

Apple’s iMovie is in the “Good” box, and Final Cut Express HD is in the “Best” box. The problem is that users will grow out of the “Good” box, with no “Better” box to move into. Redrawn to illustrate (imagine this is an arial photo of Kathy’s canyon diagram):

Kathy describes this in the context of moving from one product to another. The same dynamic will take place within a single product as users get more experience. Imagine a product that provides “limited but easy” stuff for new users as well as “full power” for experienced users. How will you get your users across the canyon of pain, when they are ready to start doing more with your product?

Features For Competent Users

A product that is designed with a focus on new and/or experienced users will have this canyon of pain. Competent users need a way to do more than when they were new users. And it needs to be easier than if they were expert users.

By developing features expressly for competent users, you create a bridge across this canyon of pain.

There’s another reason to make sure you build this bridge for competent users.

Most of your users will be competent. Users don’t spend very long being new. They quickly want to walk across the bridge, in hopes of doing more. But only a very small percentage will invest the time and energy to make it all the way across the bridge and become experts. Most users will reach a level of competence and stay there.

If you don’t design features for those competent users, they will be in the canyon of pain, instead of enjoying the view from the bridge of competence.

Minimizing the Size of the Canyon

In an earlier analysis of the right number of features to include in a product, we looked at ways to increase the number of features without making the product overly complex.

The article goes into more detail, but essentially what you are doing is making it easier for users to do more stuff with less effort. This encourages more users onto the competence bridge, and helps them move further along it as well (less effort to become an expert).

By improving features that are already there, you make it easier to get better at using the tool.

Conclusion

By improving performance, you raise the utility for the users, ultimately making the bad parts less painful, and the good parts more rewarding.

Both of these approaches focus on improving existing features, versus adding new features. The challenge is to incorporate utility with ROI as part of your prioritization activities.

There are three main models for selling software. You can hire a direct sales force. You can spend a lot on marketing and advertising. You can let your users sell the software for you, a technique commonly known as viral marketing. There’s a catch with viral marketing – users have to like your software.

Viral Marketing

We wrote an article in 2005, Ideavirus – Marketing By Word of Mouth, where we talked about a presentation by Seth Godin.

Some really key points he makes -

• The idea vectors from user to user (slide 29)
• The more you give your idea away for free, the more valuable it is (slides 32-33)
• Build the mindshare first, then monetize. “get cash now!” cripples the spread of your virus (slides 36-40)
• Seth gave his book away instead of selling it – 200,000 downloads the first two weeks (slide 55).

Seth may be the authority on viral marketing today. When he combines his work with Malcolm Gladwell, we get a great extension of the idea virus concept:

Seth Godin spells out the virus analogy. Someone uses a product or service and raves about it to his friends and associates. This is called sneezing. Some people only sneeze occasionally. Some people sneeze all the time. Some sneeze quietly, some loudly. Some sneeze to a small crowd and some sneeze to a huge gathering.

Karl Palachuk

Its the sneezers that spread the virus. But what makes people want to share?

Compelled To Share

People want to share the virus when they love the product. Gladwell talks (I think in The Tipping Point, but I don’t have it in front of me right now) about how some people are predisposed to sneezing. They will tell us all, good or bad, about the products that generate enough emotion for them to feel compelled to spread the word.

This sounds pretty scary – customers telling everyone about our product. What if our product sucks?

BazaarVoice, a company in Austin, issued a press release a while ago – “Positive Online Reviews Outweigh Negative Reviews 8 To 1.”

Analysis across a diverse set of products and services indicates that positive reviews outweigh negative reviews 8 to 1, with an average rating of 4.3 out of 5 stars across all live Bazaarvoice clients.

[...]

“We are seeing a ‘Rating J-Curve’ across many clients in diverse industries,” said Sam Decker, vice president of marketing and products at Bazaarvoice. “The distribution looks like a J on a graph, where you see a low volume of 1 star reviews, fewer 2 and 3-star reviews, and a huge jump in 4 and 5-star ratings. While surprising at first, this finding agrees with third-party studies that suggest word of mouth is much more positive than we often assume.”

Sam Decker (Who also has a great blog)

If you’re still gun-shy, even though we know the odds are in our favor, there are ways to make our software not suck.

• Getting Past The Suck Threshold – Understanding the Suck-Threshold
• Goal Driven Documentation – Helping Users Cross The Threshold
• Goldilocks and the Three Products – Manipulating The Suck Threshold

Comprehension Through Contrast

There’s a great visual in an article at 37signals titled In-store good or at-home good? that puts this all in perspective, when compared to traditional marketing approaches. The article sites an analysis from the Harvard Business Review.

They contrast the imact that the number of features has on two different personas. The buying persona, and the using persona.

• The buying persona perceives more value (at the time of sale) from having more features.
• The using persona experiences more value (over time) from having fewer features.

This is the basic premise of the more is less argument. We can step back and generalize this a bit.

Software that is more usable grows in value to users over time

Usability Sells Software

The buying persona is the target for marketing and advertising. She is also the person that a direct sales force tries to convince to buy our products. That’s why marketing is always asking for more features. They want products that appear to be more valuable, because perception sells.

But buyers aren’t sneezers. Rarely does a friend call and say “I just bought this, and I haven’t used it much, but you have to get one!”

The idea virus is vectored by users. And users grow to like the product more and more over time. And the usability of the product has a major influence over how well they like the product. The more usable it is, the more word of mouth marketing we get.

What a great way to demonstrate 12 key usability concepts – creating a calendar where each concept is demonstrated.  You’ve heard the saying – “If you can’t be a good example, be a horrible warning.”  Here is that saying manifested in calendar form.

The Calendar

A Brilliant presentation of the importance of usability.  Brilliant because it is fun, and the ideas are all extremely well executed.  Thanks to Netlife Research for this!  And a hat tip to Jesper at justaddwater.dk.  Netlife’s main site is in Norwegian, which will be a pleasent surprise for some of our readers.

The other twelve months of the calendar are available in a pdf (go to justaddwater.dk to get the download), and are really great.  My favorite ideas (cleverly done in calendar as examples of how not to do it):

• Give All Pages Suitable Titles and Subtitles
• Don’t let news and information take up too much space from the main focus
• Use a language the users understand

Genius.

Thanks, Jesper, and happy birthday – the one year mark is a big deal for a blog!  Jesper’s current “highest traffic post” is a roundup of 30 ajax tutorials.  Let’s see if we can push the bad usability calendar to the top of the list for year two of justaddwater.dk.  Go check it out!

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular – using goal-driven documentation to encourage upgrading.

Background On Documentation

Over the last couple of days, we’ve written about how to structure documentation to define what users can do with the software, instead of capturing what the software can do for users. This reverse approach uses user goals to guide our documentation. We also presented, more concretely, how to trace and manage our goal-driven documentation with use cases.

We can leverage this documentation approach to achieve two additional benefits:

• Encourage users to install new upgrades
• Encourage users to migrate from other applications to ours

The same factor is at play in both situations – users already know how to use their existing software, either a previous version of our software or a competitors software. The fundamental question for users is “How will I do what I need to do?” This is a major barrier to both upgrades and migration from other applications.

Kathy On Upgrades

Kathy’s article on why users don’t upgrade is awesome. She creates a great visual graph (shared via her CC license) of the user’s perspective on upgrades:

Why they don’t upgrade (and what to do about it)

Kathy goes on to list several approaches to address the problem, all of them fall into either “make them want it” or “make it easier.” We will focus specifically on how writing goal-driven documentation can help.

Make Them Want It

We must apply the same prioritization approach to defining upgrades as we do to defining the initial release. This assures that the most valuable not-yet-implemented goals are addressed in the new version of the software. If we are using Kano as a framework for prioritization, we have the added benefit of effectively lowering the suck-threshold.

Make It Easier

We can make design decisions that make software easier to use. We can also follow Kathy’s other good suggestions. And we can write our documentation to make it easier for users to make the change.

Goal-driven documentation has two effects on the curve Kathy drew above. Here’s the same curve, representing a typical software upgrade:

With goal-driven documentation, the curve is shifted up and to the left:

This shift can be analyzed as two different factors:

The goal-driven documentation allows users to climb become more competent more quickly – effectively lowering the suck-threshold. When applied to upgrades, it reduces the size of the drop – preventing users from re-entering the suck-zone.

Faster Climb

Competence is not a measure of how quickly users can do everything the software can do – it is a measure of how quickly users can do everything they need to do with the software. When we define our software to prioritize solving the most valuable problems for our customers, we are defining the set of activities that the users need to do. And we identify this as a set of use cases.

We then document how users will follow those use cases, with the implementation we’ve given them.

This goal-driven approach to documentation helps users climb the competence curve much faster, immediately reaching the “Finally I can actually DO something” point (above the suck threshold). As long as we document the right somethings, we’re all set.

Shorter Drop

We apply this same approach to our upgrades. Those use cases that we’ve added in a new release yield new documentation. Those implementation areas we’ve modified as part of the upgrade yield updates to previously released docs.

Users will have an easy answer for “how do I do it now?” as well as “What can I do now?”

Collateral Benefit

We also get the benefit of making it much easier for users to migrate from other software packages (not just our earlier releases). There are books out there where authors address exactly this problem – Microsoft Word for Wordperfect Users and Java For Cobol Programmers come to mind. By showing users how to do what they need to do, we make it easy for them to switch.

Conclusion

• Goal driven documentation makes it easier for users to learn how to use our software.
• Goal driven documentation makes it easier for users to switch from other software programs to ours.
• Goal driven documentation makes it easier for users to upgrade to new versions of our software.

Stephen Turbek, at Boxes and Arrows, tells us how to get better results from our wireframes. Wireframe prototyping can provide feedback early in the design cycle, reducing costs and improving the quality of the final software. By putting a little flesh on the bone, we can get even better results.

Hooked From the Start

Stephen starts his article with the following quote…

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

A very solid opening to his position that when you only use wireframes, you introduce problems. Wireframes are designed to eliminate problems and “clutter” from the feedback session. Feedback sessions provide us with a lot of information, and the challenge is to separate the noise from the signal. The goal of wireframes is to eliminate sources of noise, to make it easier to focus on the signal. But using wireframes also introduces noise into the data.
He goes on to provide a real world example of a website under development for Verizon – showing wireframes and “low fidelity prototypes” that include more information than just the wireframes.

Why Wireframes?

Stephen makes an interesting point – wireframes (named after 3D modeling techniques) were initially designed to provide quick feedback and insight into 3D models, without the expense of complete rendering. As technology reduced the cost of of rendering, rendering cycles began to replace wireframes as early prototyping tools.

A wireframe, in the user interface world, is a minimalist visualization of a website or application. It shows where information will reside on a page, and what information will be shown. When using a wireframe to get feedback, it allows a designer to (attempt to) isolate the feedback about content and layout from other data (like feedback on color schemes and graphics). It also allows for more rapid prototyping because the prototype can be built as soon as a layout is done, without waiting for colors and graphics and branding to be incorporated into the design.

Why Not Wireframes?

Expanding on Stephen’s point, the lack of information detracts from an understanding of the usability of a design. Colors (such as blue hyperlinks) do provide visual cues for users. Branding and navigation elements provide a sense of context and comfort. The absence of these things can distract the people we were trying so hard to not distract.

What About Cost?

Another goal of using wireframes is to reduce the cost (and time equals money) of prototyping. Stephen shows how in less than 15 minutes, a wireframe prototype is converted into a prototype that leverages existing branding, navigation, colors, and images. 15 minutes is not a long time to spend to achieve this striking difference (check out the images in Stephen’s article). When showing multiple screens in a site with structured navigation, most of those investments will be re-used across multiple screens.

Why It Will Work

The ability to re-use the “extra bits” is the key to why it will work and not just the key to why it won’t cost more.

People who think about website advertising worry a lot about ad-blindness, or the ability of people to ignore ads over time. We actually depend on it here, to allow our regular readers to tune-out ads that appear in consistent locations and formats and instead focus on the content of the articles. This same phenomenon applies to these augmented wireframes.

The lack of context that a wireframe creates can be disconcerting or even confusing. The (valid) concern that drives the use of wireframes is that providing all the other stuff will distract the users and prevent them from providing feedback on content and layout.

The ad-blindness effect will quickly allow people to ignore the “other stuff” and focus on providing feedback on the content and layout of a page. People are good at scanning pages – they have an autopilot that takes them directly to the “meat” of the page. And the presence of the extra content allows them to do that – where the absence of that richness will immediately trigger a “what’s wrong?” or “what’s different?” analysis.

Tips to Making It Work

Stephen provides eight tips, which we really like. We are concerned about one of the tips – to use “real data” instead of fake data. I had always learned that real data risked distracting the users, who might fixate on the fact that you chose incorrect data to display.

Today, after a prototype review session, we got feedback from our reviewers that it would help them if we used real data.  The reviewers of our (fleshed out) wireframes were unable to visualize how the interface might behave with some real-world data examples. The data we were presenting and manipulating is fairly complex, and the contrived examples didn’t do a very good job of showing how the interface would handle the complexity it would need to support.

Using representative data is definitely a good idea – and as good as Stephen’s other ideas are, we’ll take his word for it that real data is even better.

Conclusion

Spend the incremental effort to make wireframes “feel real” by fleshing out some of the context that wraps the prototyped pages. That context will provide more comfort than distraction for users.

Microsoft Office 2007 has a completely new user interaction paradigm.

The old interfaces for Microsoft Office 2003 (and earlier) organized the menu structures around features or capabilities. Each grouping represented tasks that appeared to be related in functionality. This, unfortunately, doesn’t help the user very much. The new interface is very task based, and organizes capabilities based upon the task the user is currently performing. What the Office team has done is innovate. And the innovations differentiate them from every other business application I’ve ever seen.

Check out the 13 minute video from Microsoft’s user experience team here : http://www.microsoft.com/office/preview/ui/demo.mspx. It’s worth watching!

The best quote, from Jensen Harris, lead program manager, Office user experience team:

We realized that people weren’t trying to find commands in the product, they were trying to get great results.

This really captures the spirit of the changes – and they are compelling and dramatic!

Julie Larson-Green / Scoble interview on Channel 9

Robert Scoble filmed a 41 minute interview and demo with Julie Larson-Green, manager of the Office user experience team (Sep 2005). The comment thread on this Channel 9 post is really interesting, including several people expecting to be unimpressed, and ending up being converted. If you only watch one video, watch the other one. If you’re the kind of person who re-watches a DVD to listen to the director voice-over the decisions, check out this one too.

Jensen Harris has a blog devoted to Office 2007

After you watch the video, and decide that you must have this app (and you will), subscribe to Jensen’s blog to stay up to date. He provides great insight into how the UX force at Microsoft has driven these changes and why. A great post to start with: Ye Olde Museum of Office Past (Why the UI, part 2). Note that it is a repost of an earlier article he wrote, but it is still fun to look back at the evolution of the Office UI.

Conclusion

Suddenly, open office seems much less compelling. The Office team has put together very compelling and differentiated innovations. It isn’t the ribbon (replaces the menus and toolbars) that makes it exciting, its the task-centric design of the application. The new UI puts Office 2007 clearly in the revolutionary change corner of the magic square of innovation.

What the heck is UX?

UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. In some circles it is known as human-factors engineering, applied to software design. There are several disciplines within this field, we’ll introduce each of them.

We talk about the different roles within this field in several posts throughout Tyner Blain. The following are introductory explanations for these roles.

Information Architecture (IA)

The study of information and it’s presentation to people. Also the study of how people interact with information. Many software packages allow users to manage complex information. Information can be presented in ways that make it easier for people to absorb and understand.

As a very simple example, imagine a website that allows you to research the cost of living in different cities in the USA. There are thousands of cities in the country. IA helps with designing a user interface that allows users to get information for a specific city. An IA specialist would recognize that cities can be organized by state. In fact, cities in different states can have the same name, like Springfield, Missouri and Springfield, Illinois. But two cities within the same state won’t have the same name. This insight can be applied to present a design where the user selects a state first, which then filters a list of the cities within that state.

A corporate internet may really be the combination of several different standalone websites – a company news bulletin or blog, an interface to the HR system, a download center for installing corporate-approved software, an email directory for the company, etc. IA specialists will determine how to organize all of these functions so that employees can intuitively find what they need and get as much benefit out of the site as possible.

Usability

The study of what makes software easy to use or hard to use. A usability specialist will look at the tasks that a user needs to perform, and analyze the most intuitive or efficient ways to perform them. Think of the sequence of steps that you take when adding a graph of data in Microsoft excel. There is a wizard that walks you through a series of questions in order to create the graph for you. A usability specialist determined the best sequence in which to ask and answer those questions.
Usability specialists will also make holistic assessments of how an application or suite of applications behave. This helps users gain competence or mastery of software more quickly. All of Microsoft’s applications use the same approach for opening and saving files (same menus, same shortcut keys, same dialogs, etc). This is the result of usability analysis.

A usability specialist will also be the person who determines how to make software great for novice and experts alike. This is critical to having successful software – the experts are the people who will promote your software for you, but they won’t become experts unless they survive the novice-user break-in period.

Graphic (or Visual) Design

Some people erroneously think of visual designers as the people who make software sexy. The can certainly do that, but graphic design is as much about creating emotions for the users, consistency of presentation, and establishing elements of brand as it is about sexy. This is what makes a Macintosh look like a Macintosh (while usability specialists make it great to use).

A graphic designer can create a set of consistent icons that make an application feel professional, and make the user feel whatever the designer wants. Graphic designers can make the user interface feel different enough to create a notion of uniqueness and branding (association of the images with the product or company), while also keeping them consistent enough with “everybody else” that users know what to do. Another technique is to create an affordance visually. An affordance is an image or element that suggests an action. A dial says “turn me” while a slider says “slide me.”

This can be very subtle and very powerful.

Think about scrollbars for a second. Most scrollbars have a pretty boring look. There are tiny up and down arrows at the top and bottom – which create an affordance that says “click on me and the window will move up (or down). That’s good design. There’s also a grey bar in the middle. In some user interfaces, the size of that bar is proportional to the amount of the content that is currently visible. This gives the user some insight into how much content is hidden – another good visual design. A user can also click and drag the grey bar up and down to move the contents of the window. There are no visible cues that this would work, a user would have to be shown that this works. Another example of “hidden” functionality is the ability to click in the light grey “background” of a scrollbar – it causes the contents of the window to page up or page down. Again, without training or an errant click, people would not know this.

If we make a tiny change to that scrollbar by adding a few lines in the center, we create a tactile effect – implying that the user can “grab” it with the mouse. This scrollbar screams “grab me”. Subtle, but powerful.

Interaction Design

Interaction Designers are a different breed.  They focus on the software at a higher level, using a goal-driven process to focus on the intent and objectives of the users.

- – -

Check out the index of the Foundation Series posts which will be updated whenever new posts are added.

In Those “Minor” Usability Annoyances, Daniel Read at developer.* writes in on a topic that resonates with me.

Daniel describes working on a critical application with multi-year, continuous development and a couple hundred internal users. I’m currently helping a client incorporate automated unit testing for a similar enterprise application, and Ive helped teams manage the fixing of the same kinds of problems.

Daniel describes how a multitude of small usability problems add up to make the application all but unusable, one user even describing himself as a victim of the system.

He has some good insights into what’s wrong and suggestions on how to prevent the mistakes. He also provides a sample of approaches on how to fix existing problems.

We recently covered some major usability blunders and solutions too.

Five easy steps to alienating your users with bad usability

1. Fail to simplify a comprehensive interface so that new users can quickly climb past the suck threshold.
2. Build an inconsistent UI layout or interaction design that varies throughout the application, creating a sense of dissonance for the users.
3. Interrupt the user’s workflow with pop-ups and other modal interruptions.
4. Limit expert users to following “new user” workflow, one tedius, repetitive step at a time when shortcuts would work.
5. Don’t suggest solutions when an error message is displayed.

Five difficult steps to making your users fall in love with your application

1. Plan for new users. Incorporate training, documentation, guides (or wizards), and feedback (breadcrumbs, confirmations) into your design. All of these “new user” solutions can be ignored once the users become experts.
2. Plan a consistent UI. Share a common stylesheet across web pages. Keep screenshots of the application taped to the wall where UI designers and developers can quickly assure commonality. Reuse interace code – derive from (or reference) common search widgets, sortable grids, etc. Make sure part of design reviews explicitly ask “is this the same as what’s already there” or “are we updating the existing stuff to match this?”
3. Provide passive warnings. Provide feedback in the status bar or page header when something “might not be right”. Add “Don’t ask me again” checkboxes to the “Are you sure you want to do this?” interuptions – let each user decide when they know what they’re doing and don’t want the interruption. Add undo capabilities for when users mess up.
4. See #1’s solution approach.
5. Add a “Fix this for me” button whenever a modal message must be displayed. At a minimum, offer targeted advice on how to fix the problem manually – right in the dialog. Add logging of all modal interruptions, so that developers can design new automated fixes (or prevent errors entirely) in future releases.

Kathy Sierra writes a great post in her blog, Creating Passionate Users, that talks about the requirement to make things interesting.

The driving objective is to accelerate the user adoption curve – which Kathy calls the Kick Ass Curve. Any user is initially forced to focus on the tool, and not the task. The better the design of the tool, the faster they can master it, forget about it, and focus on the task at hand. Her graph brings it home – initially, users are frustrated and unproductive. Until they gain enough competence with the tool, they are trapped below the suck threshold. They climb into competence, and eventually to mastery.

The amount of time it takes them to cross this threshold can be a proxy for the difference between sucky software and great software.

Microsoft Office uses commonality of interface very effectively to shorten the time in the suck zone. Each application has a ton of “learn the tool” material – and by using a common set of menus, commands and experiences, the Office team dramatically reduces the sucking time for new users. Once you can save a spell-checked word document, or a presentation with a stock template, you are likely to have crossed out of the suck zone. And the familiar commands required to do that are in familiar locations.

When designing web applications, the flexibility to do “anything” makes it easy to do unconventional things. We can use interesting to help the users cross the suck threshold. Kathy talks about some ways to do it. Maybe they don’t all easily apply in our particular case, but regardless, getting users past the suck threshold is critical.

In the consumer space, this can be the difference between having and not having a viral marketing effect. In the enterprise space, it can be the driver of user adoption rates (and if users don’t use it, there goes the ROI argument for the project).

This is a great argument in support of having the best people you can find invest in understanding the usability of your application. Focusing on use cases at the synthesis stage of defining a new product can make or break your application. An application lives or dies by its ability to allow users to achieve the goals that drive the creation of (or purchase of) the software. Simply having the capability to achieve the ROI of a product is important. It even should have veto-power at prioritization time. If the product doesn’t have the capability to accomplish the goals (realized through use cases), then it won’t present the return on investment that was promised.

Unfortunately, many software products, especially enterprise products, consider this absolute-minimum to be the “check-off criteria” for a successful project. The examples Jan points out are considered software successes because they enable the users to achieve their high level (and most valuable) goals. But they don’t engender passion.

Great designs yield passion. Passion yields loyalty. Great designs can differentiate a commodity software product. Differentiation yields a market premium (dominant market share, price differential, etc). There are the pop-culture canonical examples, like the ipod and the mac. I think Apple gets it.

There are far too many applications that don’t inspire. They meet the minimum bar. My newsreader, for example – good use of system resources, provides a classic 3-pane viewer, organizes feeds hierarchically in folders. Meets the low-bar. But adding a new feed can only be described as tedious. And there isn’t an archive of past posts (wouldn’t it be great to archive feeds and search them later, without having to bloat the “current data” interface). Do that stuff, and you’ll have people who won’t hesitate to do your marketing for you.

We have a skunk works project going here at Tyner Blain (it’s too early to even call it stealth yet – still exploring the technology), and I hope we create passionate users. I know we’ll have the ability to rename files within the application.