Usability: The Key to Product Success

The usability challenge

Everybody wants a usable product— it’s absurd to suggest that a product manager should address the team at the beginning of a project and say, “Make sure to include all the user’s needs in the specifications; it doesn’t matter how you do it, just make sure you do it.”, but often that is how the process goes. Even though one of the team’s goals may be to produce a usable product, the design and development process often treats usability as a “feature” or as something that can be tacked on at the end; build a prototype, bring in some users, give them a few tasks and see how they perform. Then correct the errors and behold “a usable product.”

Unfortunately, the outcome is rarely a usable product; more likely it’s an application that has some threshold level of frustration that users are willing to tolerate—until another company delivers a product that addresses the same functional challenge (or in some cases not), with a user interface that is more intuitive or just “simpler.”

This “usability challenge” is faced by many companies that are heavily reliant on their software products to attract new customers, build loyal communities of users, improve their client’s effectiveness, and generally help a business be better at what it does. In each case, the launch of a product that has not considered the “usability factor” poses a significant risk to the business, and provides an opportunity for competitors to gain an upper hand.

I spent time researching what the user wanted, so why isn’t my product scoring high in user experience/usability?

Customers are rarely quiet and, if given the chance, have a lot to tell a company that is willing to listen. Amidst all that chatter—the help desk logs, focus groups, and site visits—a product manager might find some gems that point to features for the next generation product. What will be missing is how to make the product more usable. Undoubtedly the customer will often say, “it would be nice if this were a dropdown instead of a textbox” or “you really need to add more keyboard shortcuts” but those incremental changes only turn an unusable application into a tolerable one. In other words, all customer data is not equal—work practice and improved usability is not gathered in the same manner that one captures the details within a functional specification.

Usability is not an end product; rather it should be thought of as an emergent property. Good usability does not come from knowing where to place buttons, or even how to display complex information. It arises by innovating on current work practices and integrating that with potential product requirements. In other words, usability starts from the beginning, and in the beginning there is the customer.

Current approaches to user interface design are a combination of guidelines and seat-of-the-pants decision-making. Design decisions are usually made on an ad hoc basis with problem analysis performed on the fly and from wildly varying empirical bases. What we generally have is TLAR, or That Looks All Right to me. We ask our co-workers, the marketing department, defer to the boss, the client, and fiddle around on a trial-and-error basis until the results meet some, usually unspecified, criteria. Various goals often compete. Technology and time constraints determine much of the decision making, and there is usually very little real information to guide decision-making. Many of the changes take place in the design and iterate phase, with scant empirical support for changes.

This is very apparent during design reviews. In a typical review, especially during expert evaluations, team members argue their points based on what is more logical. But often logic is not the proper measure for determining how an application should behave. Real people rely on rapid categorization and pattern recognition not “if A then B.” Though the intent, again, is to create a usable product, the end result is often one that makes sense to the development team, but not to the actual end-users.

In the design of complex applications, an in-depth understanding of the user population is critical. Unfortunately, the majority of projects find ways to circumvent the process. Knowing others is hard work—even in our everyday life, we have ways of cutting corners. We jump to rapid conclusions about the behaviors and motivations of others, which is an efficient tool for decreasing our cognitive load, but not a good method for creating a usable product.

During the product development lifecycle there are two major obstacles to creating a usable product; information degradation and responsibility transfer. As information is translated into various forms; from customer workflows and needs, to product requirements, use cases, technical and User Interface (UI) prototypes, to the final product, it undergoes both information loss and translation. Some of the changes are positive and are the result of refining the product, but many changes result from the need to simplify the design process and get the product to market.

Similarly, responsibility transfer comes as each department within a company has their own specific goals/milestones that need to occur during product development. Though lip service may be given to the idea that the product must solve the user’s problems, immediate department needs often supersede this. Marketing wants a usable product, and the UI team starts off with that goal, but as time-pressure mounts, the UI design suffers and responsibility still sits with Marketing, who, as the development process continues, takes on less and less of a role. By the time coding begins, the developers are concerned with creating innovative error-free code, not necessarily a usable product.

Addressing the usability challenge

Contemporary usability practices include augmenting the standard marketing approach with a specialized contextual method of understanding the user and their needs.

This approach begins with observation and contextual analysis of the user wherein the user is interviewed in their natural environment and asked to share day-to-day activities as they relate to the product being designed. This observation/interview method provides a clear understanding of the user and their needs as well as key areas where a user is struggling to effectively do their job. The output from this process is provided to a User Experience (UX) analyst who uses their expertise to synthesize this information, develop user model(s) and produce design recommendations.