[first published November 2002]

No one intends to make bad things, yet we know how much of the world is not  well designed. Most designers assume conveniently that the problems are obvious and easy to fix, but that has never been true.

Designers should know if it takes more work to do something the right way,  most people won’t be motivated to do it. This means a workplace has to be designed to make good design likely and that requires significant leadership effort. Many of the problems that lead to bad design are not design specific but reflect limitations of the leaders and the organizational design itself.

1. General Incompetence

A dysfunctional team is a dysfunctional team. If a team has rampant in-fighting, low morale, low quality work, and low trust, it is unlikely to be competent enough to make a product customers love. Some teams fail at delivering good designs simply because they fail at most things. It’s not about a disregard for design, it’s that good design is well beyond the operational capacity of the team.

In some cases it’s a question of team interaction and communication, where bad decision-making practices are common. Or perhaps it is the team leaders who set the wrong tone and exhibit bad habits the rest of the team emulates.

Advice: A team becomes functional because of good leadership. Someone with authority (granted or earned) has to set a better example, reward those who follow it and coach (or fire) those who don’t. A designer could quietly build a better design for one small area with an engineer, ship it, and then when coworkers are impressed show them how it was done. Once a new 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.

2. Design is not (perceived to be) good for business

Without clearly defining the business advantages of higher quality design, it’s easy for managers to cut the budget for “design work”. These work items can be seen as superfluous, and not directly tied to sales or transactions or other primary revenue metrics. I’ve seen great product designs scrapped simply because the costs of building them were not defended with arguments that the team managers could support. The best place to make these arguments are during the drafting of the projuct vision, early in the process. The last thing you want is to be in the position of making high-level philosophical arguments about product strategy when half the planned features are on the chopping block.

The painful realization, however, is that sometimes there aren’t good business arguments for better design. The marketplace you are in may not value it. Costs, features and partnerships may have far more cost/benefit returns than an improved design. There are reasons Norman doors and television remote controls are often so hard to use: there is little market advantage to offering better ones, since ease of use of these objects is not a top factor in how the purchasing decision is made.

You can always make a case that design has strategic advantages, but that’s easier to do in some businesses than others. If you study the history of technology, you’ll find this trend is common: early automobiles, televisions, mobile phones and other products initially have low-quality designs. Good design often enters the market as an advantage later on. This is not unique to the technology sector: go to any mid-west supermarket, and examine the strange round bread-like products they call “bagels”. It’d be hard to argue for the business case of opening a high-end bagel shop based on a true NYC or Montreal design quality level (as the higher price point would be unlikely to be supported by that market). Ease of use, or high quality, are attributes of a good product, but 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. Study the strategic preferences of your organization’s leaders. Understand your competitor’s products. If you believe that ease of use can be a competitive advantage, work to clarify where the specific points of leverage are, and make sure these are reflected in the project goals. It is 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 are bad: 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.

3. The wrong people are involved

You can do most things right, but if you give decision making authority to the wrong people you will still fail. The craft of designing user experiences is an uncommon skill. It requires an individual to have at least four personal attributes: compassion for other people, abstract problem-solving skills, the ability to effectively communicate design ideas, and experience with the cycle of making and watching people use what you’ve made. 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 its 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 / 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.

4. Lack of familiarity with the creative process

Developing new ideas requires a different mindset than implementing old ones. For a good design of any kind to be created, time must be spent exploring alternatives and learning about problems in the customer experience 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 apply their methods, but one day engineers walk in the room, can’t figure out why the specs aren’t finished, don’t bother to ask legitimate questions, and storm off to design the product themselves. Or B) The designers attempt to design something far beyond 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 part 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 part 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.

5. Experts fail to positively impact their teams

Knowledge only helps design quality if the person with the knowledge can successfully convince engineers to do their work differently. Hiring a designer or design researcher is one thing, but if they are not set up to have influence over decisions then their knowledge is wasted. Since these experts are often not decision makers, two core skills they need are persuasion and diplomacy. But rarely are they trained in those skills or hired for them. The result is design knowledge is paid for but wasted, either ignored in favor of other priorities or never heard because the designer couldn’t make a compelling case for taking their advice.

Advice part 1: Half of the battle is team leaders in key roles (development, project management, business). If they support the new ideas and process changes, things are likely to move forward. 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 part 2: A mediocre designer, with great evangelism and communication skills, will probably be a better contributor to a typical engineering project that’s never had a designer before, than a stellar designer, with weak evangelism and communication skills. 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.

6. Good design is not a project goal

If ease of use is never a stated project goal it will lose resources to other goals. It may be assumed among the team 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 be 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 when compared to past or competing projects. These goals should be combined with tradeoffs the project should make to ensure these goals (will the schedule slip? Will resources be shifted to ease of use? etc.). If the problem is convincing managers that ease of use can be made actionable during a project, keep reading.

7. Good design is not made actionable

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 part 1: Define the top user scenarios that the product must satisfy, and explicitly call them goals. “Our goal is to make buying airline tickets take 30% less time for users 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 efforts in a way that can be compared to other work, it is impossible for managers to track it, or ensure 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 part 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

8. 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?”). 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 usability involves extra work for a programmer. For some teams, they will always choose 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.

9. The code architecture limits the product design

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

10. The wrong data is used for the right question

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.

11. 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 variable names as the web 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.

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

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

14. 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 its 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.

———————————————–

Originally published November 2002 (Edited June 2015, November 2019, formerly titled Why Ease of Use Doesn’t Happen)