#20 - Strategic usability: Partnering business, engineering and ease of use

By Scott Berkun, May 2002

The most limited view of usability engineering is often unintentionally promoted by usability engineers themselves. A typical usability study or method is not where usability is created or defined: it’s only where it is measured or witnessed. By focusing on the lab, the methods, or the data, an organization or team can fall into the trap of externalizing ease of use. For change to take place, and better designed websites or products to occur, the attitudes and philosophies of usability and design must be internalized by everyone that makes decisions that effect the final design. The focus has to shift away from the usability engineer, and to the entire development, project and design team, to create and deliver high quality designs. Usability engineers can certainly contribute to, and in some cases drive, the design process, but that is often not how their role is initially defined, nor the strict focus of their training and background.

The shift to internalizing usability for an organization can be accelerated by thinking about usability from a strategic, instead of tactical, perspective. Tactical use of usability engineering is responsive and isolated, focusing on adjustments to existing designs, often late in the schedule. Strategic use of usability or user research is proactive and integrated, improving decision making at many levels of project and business planning. To make the transition from tactical to strategic work, a usability engineer needs to develop partners and champions within the heart of an organization. It can often take several projects releases, and the cultivation of multiple partnerships with key players in an organization for this change to come to fruition.

Connecting ease of use to business strategy

Most project leaders and business managers know something about ease of use. Their vision documents and specifications mention usability or customer satisfaction as goals, and sometimes they even use these concepts to justify their budgets or business plans. Sales teams and marketing managers typically describes the value of the service or product in terms of customer convenience, or satisfaction. What is missing is the connection between those high level goals, and the planning and design practices that fulfill them. Often executives or managers are trained only in the effects of a good design, and have little knowledge of the methods, talents and challenges required to create them. If you are a designer or usability engineer working with these individuals, it is up to you to invest in broadening their perspective. No one else will do this for you. You are a pioneer, paving the way for those likeminded individuals that will follow. Be proud, brave and, when necessary, cunning.

Start with you organization’s business model. Where are the strategic and competitive areas of growth, and how can ease of use and greater product quality help achieve success in those areas? Take advantage of whatever logical connections you can make, using it to support the decisions, and resource allocations, you think need to be made. This requires developing your knowledge of your company’s business, or developing relationships with decision makers from a business or management background, but it’s time well spent. Any opportunities you create for connecting business success with ease of use will pay off naturally. They will come to understand the value you add to the business in their terms, and become advocates for your involvement in the decision making process.

Align usability goals with business goals

Often a usability engineer will develop a set of usability goals for their project early in the schedule. Hopefully this is done with co-operation with key developers or project managers, so that the goals are shared by the team. This is a good tactical practice of trying to integrate usability metrics or goals into the individual contributors goals. The more your developers and managers feel responsible for ease of use, the more they will come to your for advice or consultations.

However, there is a more strategic approach for usability engineers to take. Most corporations, divisions or projects have a set of overall business goals that individual teams are working to fulfill. These goals might include obtaining more market share, increasing revenue or partnerships, or winning reviews against competing products. The more the usability engineer can align the usability and customer goals with these higher level business goals, the greater the leverage they will have for getting people to rally behind them (both the goals and the usability engineer).

In the worst possible case, you might find that the business goals do not align well with the usability goals you’ve created. You have three choices:

1. Work to change the business goals
2. Change your usability goals to better map with the business goals
3. Recognize that there is a limited connection between your particular organization’s definition of business success and ease of use or customer satisfaction.

This last choice is uncommon, but when it happens, you need to either lower your expectations, or become comfortable with working against the grain of the team. Either way, knowing the truth about the focus of your organization can only clarify the nature of the situation you’re in. Unless you believe ignorance is bliss, the discovery of the truth of any situation is a good thing.

Connecting ease of use to development team productivity

A by product of a good design process is more efficient use of the development team’s time. If investments are made in researching the customer needs, and exploring design alternatives in storyboards and prototypes, much less time will be spent during development, changing directions or recovering from unexpected design problems. Wisdom in the planning process results in efficiency in the development process. A well planned low investment prototype of a design will help reveal potential engineering challenges, and areas that might need more coverage from test/QA. Prototypes make many kinds of choices visible, and this is to the advantage of everyone that will contribute to the website or product. If a good design exploration and evaluation effort can take place before specs are written, odds are things will go much better for everyone involved.

One development team I worked with was such a strong advocate for prototyping and early ui design efforts, that they created a “screenshot only” estimation process: they would only talk to designers and program managers about feature development costs if the designer provided a set of good screenshots, or prototypes, for how the design would actually behave. They would literally tell people to go away, and not to come back until they could show their designs. They recognized the value of up front planning, and became advocates of a better design process, in part, to protect the entire team’s valuable time.

Strategic opinions instead of tactical data

At the higher levels of influence in any organization, there is a transition of focus from data analysis to interpretation and decision making. The most difficult issues in any organization are rarely solved by more data. Information and knowledge might expose the problem and make it’s aspects visible, but often there is still a great distance to a clear solution. Tough issues of any kind often involve tradeoffs between conflicting goals, or complex situations where no simple analysis is possible (e.g. your worst romantic relationship).

It follows that to become a strategic decision maker (or to be hapily involved romantically with another human being) you must develop the ability to function comfortably in environments where there is limited information, and conflicting points of view. To transition from the work of usability engineering, a discipline focused on providing data to questions, into one focused on responding to uncertainty and complexity can be an enormous psychological challenge. You often have to reach beyond your training or degree to see a perspective that is much broader and less structured around a single theory or philosophy. It can be difficult for some to move out of usability engineering or design and into more general management or leadership roles because of the difficulty of this shift.

How not to get lost in tactical traps

It’s common to fall into difficult situations that prevent you from moving past a tactical relationship with your team. Below are some of the common ones, with tips on how to get yourself out of them.

• Avoid becoming the usability police: Your primary role should not be to veto design ideas, or to be the tyrant at specification reviews. It’s natural to fall into this role, since reviewing the work of others is often an easy and visible way to express your value to people. Instead, strive to convince team members of your value to them, in terms of their goals: making better web sites and products. You want them to want to come to you naturally, during informal discussions before reviews, or brainstorming meetings, as a way to get the best thinking into their code or specs. Chase them if you have to, but think about ways to make them want to come to you.
• It’s good to have opinions: Often you will be asked for your opinion on an issue, without time to run a study, or apply a method. Many usability engineers avoid these situations, afraid of offering their own judgment without the support of data. This eliminates participation in many situations, since other members of the team have no restriction from voicing their own thoughts. As a usability engineer, expert opinions are often more valuable than any number of studies. Simply clarify that you are not speaking from data, and are offering your own informed opinion, and tell them what you think. If you train them to understand the difference between your own opinions, and what you distilled from a method or study, your value to your team goes up, not down. Many tough design decisions are not made by analyzing data, they’re made by intelligent discourse around cogent points of view. Everyone else on the team is allowed to voice opinions, and you should be no different.
• Data should support encourage good thinking, not restrict it: Late involvement in the development process forces your research to be responsive. Early involvement in the development cycle enables you to be proactive. Instead of listing a bunch of minor improvements to a bad direction, you can provide user research early enough in the process to help define the direction that the solutions will take. If you are continually forced into responsive mode, dedicate time, your own time if necessary, to provide early research into the next release. Then you can help define the kinds of approaches the designers or engineers should consider, instead of trying to polish the output of a misguided or misdirected project. Often by the time a design makes it into the usability lab, it’s way too late: the key decisions have already been made. But remember that the goal isn’t to fight your way into meetings, instead it’s to make your contributions valuable enough that people will often come to you in their own interest. And remember that the nature of methods makes it much easier to find design problems, than to highlight good attributes of a design. Find ways to capture what’s good as well as what’s bad.
• Be patient, changing team processes takes time: Just like with people, habits for teams are hard change. Even with development practices such as code reviews, or build verification tests, teams are slow to adopt change and to learn how to adjust to new ways of working. Usability methods or good design exploration practices impact the way a team functions, and you should expect a learning curve before it becomes natural. It may take several project releases before team members understand the full value and ramifications of changes in process. You can reinforce your progress by documenting the team process, and provide ways for new members of the team to avoid having to start from scratch.
• Don’t live in the usability lab : Designing and running lab studies is a challenging and critical part of the process. However, someone must be working with team, influencing decisions, and you can’t do that if you’re sitting in the lab running studies all the time. It’s worth the investment to use discount or informal methods, since they take less time and often put you in a more collaborative environment with your team. Above all, remember that usability data doesn’t do anything. It just sits on its ass in a report on a web page. Instead, it’s the positive impact you are able to make on your project, as a result of the data you find, that’s important.