By Scott Berkun, November 2002 (Edited June 2015, formerly titled Why Ease of Use Doesn’t Happen)
One way to use this essay is to share it with your team and ask everyone to identify ones that apply to the current project. The discussions that ensue will lead to better solutions than any list made by an outsider could provide.
1. Ease of use is not an explicit project goal
For many projects ease of use is never a stated project goal. It may be an assumption among managers or developers that the project will result in something easy to use, but if it’s not a first order goal of the project, tradeoffs can never been made in favor of ease of use (and can implicitly be made against ease of use). Often the lack of a clear statement occurs because leaders are unfamiliar with how to make ease of use operational in the development process, and one way to avoid this issue is not to make it an explicit goal.
Advice: Any project must have clearly defined goals. One of these primary goals needs to be about the customer’s experience and how it will improve on past or competing projects. These goals should also be combined with a set of tradeoffs the project should make to ensure these goals (will the schedule slip? Will resources be dedicated to ease of use? etc.). If the problem is convincing managers that ease of use can be made actionable during a project, keep reading.
2. Ease of use is not defined in actionable terms
Most project managers and developers believe, or want to believe, that success is tied to clearly defined metrics, and the team’s ability to work hard enough to meet them. Often these metrics include a list of features, goals for defect rates, and a schedule for completion of the work. If ease of use is not defined in operational terms that matches other goals ease of use will tend to be ignored. When stressed, most humans prefer to focus on things that are tangible and well defined, rather than vague and poorly defined. So even if ease of use is an explicit goal of a project, if it is not broken down into discrete and measurable pieces, or tasks and work items for someone to do, it will remain an abstract idea that no one feels pressure to fulfill.
Advice: Define the customer tasks and scenarios that the product must satisfy, and explicitly call them goals. “Our goal is to make buying airline tickets take 30% less clicks on average than before”. Any work required to achieve those goals, such as conducting research, creating prototypes, or running lab studies, should be reflected in the same schedule list as the project’s development work. Make the cost and time required for ease of use work as visible as any other kind of development work. In short, this means the project has to be planned and managed well to make ease of use possible.
Gantt charts and Kanban boards, popular with some development managers, rely on the dependencies between different work items, and there is every reason to factor ease of use work into the development manager’s view of the project. Basically, if you don’t quantify ease of use as some set of work that someone has to do in a set period of time, it is nearly impossible for some managers to track it, much less ensure that it happens at all. Worst case, if you do quantify the work, and someone decides to cut it, it will be clear to everyone exactly what is being sacrificed.
Advice #2: Once the goals for a project are defined, a team leader has to work to make the goals actionable. For ease of use, this typically means dividing the available time for planning into thirds: 1/3rd for researching customers and their needs, 1/3rd for generating different design alternatives and prototypes, and 1/3rd to narrow down the alternative designs into one well defined specification. Regardless of how much time is available for “ease of use”, some amount of work can be done in these three categories. If it is done before specs are written, even a few hours spent at each task can radically improve the ease of use of what work is developed
3. Decision makers do not see the tradeoffs
Good project managers recognize that every decision has opportunity cost. If you decide to add more features, quality must drop, or the schedule must slip. If you decide to cut the schedule, features must drop, or quality must drop. There is no way around the natural tradeoffs of resources, time and quality.
Beyond the standard set of tradeoffs, ease of use adds an additional dimension to the decision making logic. For a product to be easy to use, it has to match the design of the system, web or otherwise, to the user’s abilities and expectations for how the system should work. The definition for quality changes to mean something other than pure engineering quality.
Often this means that the way in which features are designed and engineered must change, since the objective is no longer simply the completion of an API or some purely technological function. There is a new tradeoff that has to be considered, that is more elusive, and for some with an engineering background, completely terrifying (“you mean we can write perfect code, and it still won’t be good enough? Ahhh!”). Ease of use as a key product attribute challenges many of the working assumptions developers and development managers have about how to go about conceiving and building a product.
The most explicit example of this kind of tradeoff avoidance is the case where the best solution for a ui design involves extra work for a developer, or creates a code base that is slightly harder to maintain. For some teams, they will always chose easier code maintenance over an improved customer experience. A smarter team will recognize that in some situations, it is better for the development team to suffer, than for customers to suffer. Good managers should understand this general situation as a familiar tradeoff situation, not as an easy win.
Advice: To get an easy to use product, a different kind of thinking and planning is required. Someone has to research customers and their behavior, someone has to define the key tasks and scenarios that user’s need to perform, and then someone must go and prototype different design ideas, helping to improve the probability that the final chosen design will be easy for customers to use. This all has to be done before the development team is fully engaged, and before specifications are written. Team leaders have to recognize how ease of use effects other engineering decisions, and must modify their decision making process to account for it.
4. The unseen impact on ease of use on system/code architecture
From a code architecture perspective, the user interface of any website or product is almost always described as being the top layer. The implication, intentional or not, is that this top layer is both simpler than the underlying layers, and also, the least consequential to the overall architecture. It’s easy for engineers and project managers to believe that this is true, because it facilitates the notion that somehow, as long as everything is done well at the lower layers, the topmost UI layer will be easy to manage.
Of course, from the customers perspective, things are completely reversed. The only thing that a customer ever experiences is the UI layer. The most reliable and performant system architecture is worthless if the customer can’t figure out how to do whatever it was they bought the product for. In fact, in many cases, customers would prefer an easy to use system that was slow, or crashed every so often, to an unusable system that ran fast and steady. I think an argument could be made in many situations that they’d be more productive with the later system than the former.
The biggest danger with the code architecture view of a project is that if the UI is designed last, many assumptions can be built into the design of the architecture that unknowingly effect the UI design. For example, a database architecture for a website might require that information be typed in by the customer in a certain format (which turns out to be confusing to customers), or that certain kinds of widgets have to be displayed together (which turns out to be confusing to customers). By the time the team gets around to working on the UI layer, so many constraints may be placed onto the ui designer, that it’s impossible to actually create a system that’s easy for customers to use (so surprise: the system turns out to be confusing to customers).
Advice: Early prototyping, even on paper or in sketches, of what the customer’s experience will be like, always has great value. It will inform the entire team, architects and developers alike, as to what kinds of requirements might need to get pushed down from the UI layer, and what kinds of requirements should not get pushed up from the systems internals. A good designer should be able to generate rough ui sketches and diagrams early on in a project, that enables this kind of thinking.
A common good example of architecture impact on customers: error messages. When you see a system that has obscure and confusing error messages, it is a sure sign that lots of engineering work was done without thinking through how the failure cases would impact the customer’s experience.
5. Confusion over how to use customer data
It is possible to collect many different kinds of information about customers, their needs and requests. But each method, such as focus groups, site visits, or usability studies, are only good at answering certain kinds of questions. Just like you wouldn’t use a hammer to pound in a screw, you shouldn’t use focus groups to tell you how easy to use your product is (That is best served by a usability study). It’s very common for teams new to ease of use, usability or product design, to latch heavily onto the first kind of user data they happen to have access to, and overstate the value and assumptions that can be made from the data. In some cases, the method chosen to answer a question might be the right one, but if the method is performed by someone without the proper skill and experience, the results can be worthless. (Imagine asking your janitor to implement a Java based search engine: right method + wrong person and experience = stuff you don’t want to use).
It is also very easy for any kind of data to be misused or misrepresented. Without knowledge of the methods used, or the details of a study, all sorts of erroneous claims can be made. Typically, it is those who understand the least about research methods that tend to be most bold about abusing and misinterpreting the data they’ve seen (intentionally or not).
Example: Clickthrough data for a website tells you only what happened: it doesn’t tell you why. It’s entirely possible that the placement of links on your pages might have a strong impact on which things customers have clicked on, regardless of their actual value to customers. To understand why customers are using certain features, or to understand what features you don’t have that customers might need, you have to use other methods, such as site visits and customer interviews – but you won’t answer those kinds of questions using only click through data. Every single method has similar limitations, so if you only rely on one method, you’ve been warned. A good usability engineer should understand the limitations of each method, and know when and how to apply the appropriate one to answer the questions a team has.
Quick warning: The saddest thing about confusion over data is how often teams become obsessive about it. Data doesn’t solve problems: people do. At best, good data helps to settle arguments quickly, prevents bad assumptions from going too far, and frames the discussions for how to approach satisfying customers. But it won’t solve the problems for you. I’ve heard of teams using all their planning time doing research (typically resulting in a panic attack when specs are due), when instead they should be using at least half of their planning time generating ideas and prototypes and applying the research to actual new decisions.
6. Confusion over who the customer is (user vs. customer vs. client)
There are two different flavors of this problem. The most common is the assumption that the customers of a project are just like the people developing it. When this occurs, programmers and managers rely on their own judgment, without observing actual customers, for how things should work and behave. This typically leads to designs that expose a model for interaction that is very similar to the engineering model used to build the software (“Hey, lets use our OOP structure as the navigation system. yeah!”). Jargon and technical language dominate the way things are communicated to users. Hierarchies of information reflect the internal engineering hierarchy, rather than categories or groupings of information that will make sense to customers. In rare cases, like development tools, the programmers might actually be good representatives of their target user, but even in that case, being a member of a representative group doesn’t give you any guarantees that you’ll be able to design something well for your peers (Being someone that likes food, doesn’t make you a good cook).
The second flavor of this problem is common among consultants or service organizations. Depending on your team’s work environment, there may be different sets of customers that you are trying to satisfy. The person who is making the decision to buy your product, or why pays your salary, might not actually be the person that uses the thing you are designing. So it’s possible to have very satisfied customers, who pay for your product, but very unhappy users, who are employed by your customer, who actually use the thing you are designing. Generally speaking, well meaning customers will realize that ease of use for their users is something they should want to have, but it can be challenging to express to them that their notion of a good product is very different than their user’s notion.
Advice: Early in a project, identify who your customers are, and who your users are (Sometimes, your own boss might be the customer, while your end-users are the end-users). Make sure to understand what your customers and users need the product to do for them, and document what skills or knowledge you can assume they have or don’t have. Use some kind of research method, and use a trained usability engineer if possible to decide what method(s) to use, and to perform the actual research. If you recognize conflicts of interest, raise these as issues as early on in the process as possible. In the best case, you’ll be able to convince your customers why they need to have a different view of their users, or of what a good website or product should be like. Worst case, you’ll know that your decisions throughout the project will be constrained, and your expectations for success might have to change.
7. Technical focus dominates the view of the project
There are many different ways to look at a software project. It can be seen as lines of code, a customer solution, a revenue stream, a set of features, or even a set of experiences. The best software comes from teams, or from team leaders, that are able to see the work from multiple perspectives, balancing them in accordance with the project goals, and the state of the project at any given time. When a team is dominated by its technological perspective, its natural for individuals to make decisions that optimize technological considerations over all others. These projects are unlikely to result in easy to use things. Instead, the result is more like a movie with great cinematography, but lousy acting, and a forgettable plot.
Wise engineers understand when they don’t have the right sensibilities for certain kinds of decisions, and know to yield them to someone more appropriate. An arrogant engineer will tend to assume that what they do not understand must be trivial, or worse, doesn’t exist at all, and will proceed to apply their hammer to things that are definitely not nails.
Advice: Team leaders must recognize that the technological view of a product is only one of many views. Everyone has to recognize that a product can be technically sound, with great code architecture, performance, and reliability, but be impossible for users to use, not solve any customer problems, and be a total failure. It takes the right combination of perspectives to achieve great products, so it’s important to cultivate a broader holistic attitude about what good software or web engineering is about. Minimally, you want people on your team to understand what perspectives they are most attuned to, and feel comfortable yielding to others when the decisions regards a matter they know less about. Developers often do this comfortably about programming languages or strategies (“Oh, ask Joe. He’s our SQL expert”). The same behavior just needs to extend to business strategy, marketing approaches, and high level / end-user product design.
8. Diffusion of design authority (Too many cooks)
Good design of any kind, from skyscrapers to transit systems, requires many tough decisions to be made. When authority over the design of a project is distributed across too many individuals, the likelihood of a high quality final design decreases. The worst approach is design by committee, where lots of people who don’t have shared goals or shared high level ideas, get in a room and torture each other with compromises until mediocre results that no one likes, but everyone can just barely manage to live with, are achieved*. Committees aren’t pure evil, but when misused, they are pretty close.
Sometimes the diffusion occurs at a high level, where too many team leads compete for authority over a project. Other times it happens at lower levels, where individual feature area owners build great individual components, but fail collectively to create something that customers can use easily, since for the most part, customers use products in ways that cut across the arbitrary boundaries defined by the engineering team. Project teams with lots of small feature units, led by strong leaders, often suffer from this problem. (“good features, lousy product”).
Advice: There are many ways to contain and distribute design authority. The simplest is by asking one individual, or small group of well chosen individuals, to define the vision for a project. They set the tone for what key decisions should be made, and what the spirit and philosophy for the project should be. If a good vision is defined, with a prototype or early conceptual sketches, there is still plenty of room for individual area owners to be creative and generate ideas: but they will naturally want to work within the framework defined by the vision. Another solution is to assign explicit authority, by role, to people who should drive the design of the product. Like a film director or composer, they are granted authority to lead the decision making process for large areas of the project. In either case, being an effective designer, or design authority, means the ability to: generate good ideas (creative), convince others of an idea (conviction and communication), and integrate the best ideas and feedback that others around them have (mature egos). Good design leaders are therefore quite rare.
9. Feature based design vs. scenario/task based design
On the back of the box of many software packages is a checklist of features that the product provides. Unfortunately, the existence of a feature does not guarantee it’s ease of use, or it’s quality. There is a big difference between making a feature functional, implying that it is possible for someone to use the feature, and making the feature usable and simple, so that most people can actually perform that task with a minimal amount of suffering. During the development process, it can be easy to focus on features and checklists, since it’s the minimal bar required to get that feature name on the back of the box. However, the focus on features for features sake typically results in mediocre features, and a product that is difficult for people to use. Simply including a requested feature in a product, regardless of it’s quality, is not good design, nor is it really good engineering.
Advice: The value of a product or website is not in its features: it’s in the ability for a customer to complete the tasks they bought the product for. If the entire team recognizes the difference, they will naturally strive to create something that enables the user to complete tasks, rather than merely ship something that happens to have that functionality somewhere within the product. If the team shares the belief, then they just need someone to provide constant reminders of the difference, and leadership to strive for it. So for every instance they are rewarded for checking in a feature, there should be a separate, and possibly larger reward, that they are given for making a feature usable.
Advice part 2: If you have a usability engineer on staff, they should be helping the team to set usability goals for each feature area. Those goals, often defined by time on task, or # of errors an average use might make, help drive the team towards creating good features, instead of just features. In some cases, they can run studies on prototypes or early builds, and provide feedback on the team’s progress towards those goals as the project is developed.
10. No connection made between business goals and ease of use
Without clearly defining the business and competitive advantages of building an easy to use website or product, engineering work items for ease of use can easily become the first things to be cut. These work items can be seen as superfluous, and not directly tied to sales or transactions or other primary metrics tied to revenue. If someone on the team doesn’t clarify the value of these work items, relative to the business goals for the company or business, odds are they won’t survive when things get hairy late in the project. I’ve seen great design ideas and new models for improving interaction with customers scrapped, simply because the costs of building them were not defended with arguments that the team managers could respond to. The best place to make these arguments are in the vision document, or project plan, very early in the process. The last thing you want is to be in the position of making high level arguments about product strategy late in a project.
Sometimes the competitive situation, and the quality of other products in the market, creates an environment where ease of use is not an important goal. This happens sometimes in young product lines, where the functionality offered is so sparse, that there is more competitive leverage in offering an arsenal of mediocre or unreliable features, than offering an easy to use, well engineered product. If you study the history of technology, you’ll probably find that this trend is not uncommon (e.g. Early automobiles, televisions, and other electronic devices. Quality as a key attribute tends to come later). This is not special to the technology sector: go to any mid-west supermarket, and examine the strange bread-like products they call “bagels”. Market conditions can cause the attributes required for success of any product, including core ones such as overall quality and price, to change dramatically. Ease of use is one attribute of a good product, and there are legitimate cases when this is not as important as other attributes from a purely free market perspective.
Advice: Know what kind of market you are in. Understand your competitors products. If you believe that ease of use can be a competitive advantage, work to clarify where the key points of leverage are, and make sure these are reflected in the project goals. It is a rare for ease of use not to provide a competitive advantage, especially as software and web businesses mature, but it is certainly possible. Keep in mind a hidden lesson from the book Design of Everyday Things, which explains how many common every day designs suck: it implies that our world will always be comprised of many common, but difficult to use things. Sometimes, ease of use does not matter as much as we’d like it to.
11. General Incompetence (#11 = the spinal tap commemorative entry)
A dysfunctional team is a dysfunctional team. If a team fails at delivering quality code, meeting schedule dates, or working together without killing each other, it is unlikely to be competent enough to build something that customers will love. Some teams fail at delivering good designs simply because they fail at much more basic challenges. In some cases, it is a question of team interaction and communication, where bad decision making practices run rampant throughout a team (The worst kind of bad decision being the one made without anyone else knowing until it is way too late). In other cases, it is the team leaders who set the wrong tone, and exhibit bad practices and work styles that the rest of the team is encouraged to emulate.
Advice: Well, sadly, there isn’t one for this kind of problem. Typically, a dysfunctional team has to be led by example, with a leader driving one specific area to the appropriate level of quality, and defining through their own behavior, the appropriate ways for teammates to interact and make decisions. Once the bar has been established, the entire team can refer to an example of good work, and it is possible for them to work towards changing their behavior and practices to match. In the worst cases, it is only through new leadership and the replacement of the most dysfunctional team members that things can improve.
12. The wrong people are involved
You can avoid all of the previous problems or traps, and still fail, if you give the authority to make design decisions to the wrong people. The craft of designing interfaces is a unique skill. It requires an individual to have at least four personal attributes: compassion for other people, abstract problem solving skills, the ability to communicate or detail web/software design ideas, and experience crafting designs and watching people use them. Giving design authority to programmers or project managers without these traits is unlikely to work out well.
It’s important to know that interface design has advanced enough as it’s own discipline, that you can hire people who have undergraduate and graduate degrees in HCI (human computer interaction) and various forms of user interface design. However it’s important to note that some of these degrees are more focused on methods of analysis and customer research (usability / hci), than on the skills of creating and exploring design ideas (product design / interaction design). In many cases, it’s better, and easier to find, a small group of 2 or 3 people with a diversity of skills who can collaborate effectively, than trying to find one person that can do everything. If I only had one bullet to spend, I’d hire a designer who knew a bit about research, rather than a researcher who knew a bit about design.
Advice: Choose your team wisely. Even without degrees or formal backgrounds, chose people with natural compassion for customers, strength in problem solving and idea generation, and someone that is agile enough to shift from researching customers one week, to generating early prototypes in the next.
13. Lack of familiarity with the creative process
There is a difference in mentality and philosophy between generating and refining ideas, and implementing them. For a first rate design of any kind to be generated, time must be spent exploring alternatives, and learning about the problem space that the design needs to solve. Mature engineering organizations, such as automobile engineers, or architecture firms, excel at defining the creative phases of a project, and separating them from the implementation phases. We’ve all seen sketches and clay models of new cars, or balsa wood models of skyscrapers: these aren’t made for fun. They’re an integral part of the engineering process, providing great help in exploring and understanding different choices in a decision space before the decisions are made.
Many software and web development organizations have trouble separating the creative phases from the implementation phases. This inhibits the team from discovering good solutions, since many of the best ideas require some exploration to find. If managed properly, short but well defined and well managed periods of time early in a project can reap great rewards for product quality and implementation efficiency.
So the typical problem situation, described with crude stereotypes, is either A) designers try to do good, well organized creative work, but one day engineers walk in the room, can’t figure out what the hell is going on, don’t bother to ask legitimate questions, and storm off to go and design the product themselves. Or B) The designers attempt to design something way out of scope of the schedule or business goals, show it to the understandably confused engineering team, and storm off to complain about why they’re being ignored.
Advice #1: The problem is often one of crossing over discipline boundaries. What’s required is a designer who is effective at working with engineers, or vice versa, to define a schedule and a process for integrating the creative phases of a project into the engineering schedule. It is often simply a set of conversations and agreements as to what will happen when, and what can be expected of whom. Like all process changes, sometimes it makes sense to focus on a small project the first time around, so everyone can get comfortable with how the integrated process effects their individual work.
Advice #2: Good scheduling should allow for creative and exploratory phases. The best argument for justifying this time, is that the more energy that can be spent working on prototypes and exploring ideas, the less time will be spent dealing with late and expensive changes later on in the schedule. Good design work often results not just in easier to use products, but in an implementation phase that is more predictable, and more efficient, because by the time specifications are written, the designer has thought through 3 or 4 different versions of the idea. The specification then is really a v4 quality spec, with v4 quality ideas.
14. Experts fail to positively impact their teams
It is entirely possible for a team to have one or more individuals that knows a great deal about how to design and engineer easy to use things, but still fail. If those individuals are unable to impact the team processes, and change the outcome of specific design and implementation decisions,the product or website will not get any better. Sometimes this kind of failure is the result of lack of support: A designer or usability engineer is hired into an organization that has never had one before, and team leaders don’t respond to their suggestions or support their decisions. In other cases, the individual might not have the confidence, conviction, evangelism and communication skills needed to effect change on their own. Either way, the result is a failure for those experts to impact their teams.
Advice #1: Half the battle is team leaders in key roles (development, project management, business, etc.). If they support the new ideas and process changes, things are likely to move forward. There may be some stumbling along the way, but with support, smart motivated people with the right knowledge will tend to lead things in good directions. If there isn’t much support from leaders, it then becomes the individual’s job is to seek it out, plant seeds for it, and cultivate it over time. In this situation, if the individual doesn’t decide to become proactive, then not much will tend to happen (other than feeling bitter, becoming passive-aggressive, and eventually becoming cynical enough to miss opportunities for things to actually get better).
Advice #2: The success of an individual is dependent on their ability to adapt and thrive in a given environment. When hiring someone, it is important to evaluate how much support they’ll need to effect change, and what role they need to play in the organization. If the team is new to design or usability practices, the individual will have to be an agent of change: someone who is not only comfortable making arguments and challenging the status quo, but who will do so in a way that actually moves things forward.
They will need to be open and receptive to questions about their skills and knowledge, continually teaching and informing those around them, since most of their ideas will be foreign and strange to most of the people in the organization.
These skills and attitudes can often be more important to success than their knowledge of specific research methods or ui design techniques.( e.g. A mediocre designer, with great evangelism and communication skills, will probably be a better contributor to an typical engineering project that’s never had a designer before, than a stellar designer, with weak evangelism and communication skills. Same applies for usability engineers, or almost any other role).