Chapter 4. Methodology

A methodological standard describes how to do user-centered design—select a good methodology that will work for your organization.

You probably already have a system development life cycle in place, but it is probably not a user-centered methodology. You may need to retrofit a user-centered process onto or in front of the current technical methodology.

Implement a quick test of your life cycle. Is it user-centered? Take the test in this chapter.

Review The HFI Framework 7 as an example of a proven user-centered process.

Some people do not like standard development methodologies. They prefer to work with each project and figure out what is needed for that one project without thinking about standard practices. They may feel that any inefficiency and nonrepeatability are inherent to the creative process.

With a user-centered design process or methodology in place, the critical steps to make a product usable will not be missed. All projects will follow a similar method, ensuring a standard level of quality.

A methodological standard primarily plays the role of a memory jogger. It makes sure that you do not forget to complete some of the hundreds of major steps needed for good design. Implementing a methodology also provides your company with a mature process—that is, a systematic methodology that can be organized, supported with tools, monitored, and improved. A standard process of user-centered design is essential, and the methodology you choose or develop must enable you to be reliable, successful, and efficient in your design process.

A methodology is also the core of your institutionalization effort. Because many of the other steps to institutionalization are dependent on the methodology project, it is often the first thing that gets done. The methodology program will not only define what needs to be done, but also identify which groups and class of staff will do each type of work. If you decide to have your business analysts do much of the detailed design work (generally with mentoring from user experience design professionals), then you will need training for those business analysts. Doing the methodology first, as you might imagine, is often a good plan.

This chapter describes how to choose a methodology and outlines some of the challenges you may face as you integrate it into your current development process.

Figure 4-1: The “old” technical-centered solution needs to be replaced by the “new” user-centered solution

Almost all practitioners in the field agree on the general steps required to follow a user-centered design process. You can document these steps yourself and build your own user-centered design process. Accomplishing this feat, however, may be slow, expensive, and time-consuming. You should undertake this task only if you have senior usability staff with many years of experience, as that approach will ensure you are following industry best practices. In most cases, however, you are far better off buying a process and then customizing it for your organization.

Your user-centered process affects the way functional specifications are created. For example, you will craft the user taskflows before you worry too much about the database structures. The user-centered process will mostly bolt onto the front of your technology process. Then throughout the software development process, steps connect the user-centered process to the work that the technical staff is doing as well as to the documents that serve as input to the programming staff. In addition, many linkages ensure that the methods stay coordinated. Document handoffs need to be identified at a detailed level.

This is not to say that technical limitations are ignored in the early design phases. Interface designers need to know about the technical issues for a particular project. They need to understand what the technology can and cannot do to ensure that they have used the technology to the fullest extent and without designing something that will prove difficult to implement. The primary concern here, however, is meeting the customers’ needs. You need to engineer the user experience and performance and derive the user interface structure to support this user taskflow. At that point, the technical staff can design the software to support the user interface design. This effort might require pulling together data from a dozen servers to provide a summary view when entering the site, using graphic preloads to shorten the download time on a website, or using cookies so that users get book offers that relate to their needs. The technology has a huge role to play, but it needs to remain focused on the needs of the users.

Select a user-centered methodology that meets the following criteria:

• The methodology must be comprehensive. It is not acceptable to have a process that relies on usability testing alone—it must address the whole life cycle.

• It must be user-centered. The methodology must be firmly grounded in designing for an optimal user experience and performance first, and the interface design and technology must be based on user needs. It must take those user needs into account and must actually access representative users to obtain data supporting the design and feedback.

• It must have a complete set of activities defined and deliverable documents required. The methodology should not be a loose collection of ideas but rather a specific set of activities with actual documentation throughout the process.

• It must fit with corporate realities. Ill-defined or changing business objects are by far the most important cause of feature creep. The user-centered design process needs to include steps that bring together the diverse strategic views and ideas of your organization’s stakeholders. There need to be activities in the process to ensure that all key stakeholders contribute and feel heard.

• It must include more advanced user experience design activities, if appropriate. Today, methods that simply ensure usability are usually no longer sufficient. As UX practitioners, we need to deal with the complexities of cross-channel alignment and integration—so there needs to be a UX strategy. We are often asked to participate in systematic innovation programs—so we need innovation methods and not just a general intention to be innovative. We need to design for conversion by applying persuasion engineering methods. For most organizations, all of these capabilities must be part of the current methodology.

• It must be a good fit for your organization’s size and criticality of work. Large organizations that build large and critical applications should have a more thorough process and more detailed documentation.

• It should be supported. While it is wonderful to have a process described in a book, implementation requires much more. It requires training, templates, tools, and a set of support services. It is a daunting challenge to create all of these components or cobble them together from a diverse set of sources. You might find a pretty good user-centered design methodology—you might get it from the Web or from a friend. Then, of course, you need to determine what is required to support that methodology. Expect to devote a good half-year of work to this process if you have to create all the deliverable document formats, questionnaires, tools, and standards, and another half-year to develop training to support the standard.

• It must be able to work with your current development life cycle. This is no small task, and is discussed later in this chapter.

• The methodology must have a cross-cultural localization process through which the design is evaluated for language and culture issues (if you are doing cross-cultural or international development).

The technical part of our ISO certification is based on following this process.

Figure 4-2 shows an overview of The HFI Framework. The first column lists needs that are fulfilled, and the second column lists engagements we use to fulfill those needs. The last column outlines the business need that is being fulfilled. Not every type of engagement gets completed on every program. Instead, what is important is a coherent set of engagements ensuring that the thread between executive intent and design is unbroken.

Figure 4-2: The HFI Framework

• Reduce service calls and return of tickets in error

• Migrate customers to digital self-service channels

• Increase conversion and market share by 40%

• Gain a 20% share of the mobile market in Kenya

It is the executive’s job to come up with these types of desires. But then as we start our UX strategy program, we must ask the hard question: “How is that going to happen?” We might want to migrate customers to digital self-service. But that won’t happen by just creating a self-service facility. Nor will it happen—on a large scale—by just making the self-service website easy to use. First, we need to determine how to motivate customers. Where a decade ago the journey of a major development program might start with a discussion of the technological framework for the development, today it starts with work on the customer’s motivation. Once the customer’s motivation is understood, then we need to see how that target motivational experience can be supported with the wide range of available channels (Figure 4-3). Success generally requires coordination of applications, across various channels. There may be a physical store and a call center. In the end, the whole ecosystem solution needs to be simple to understand and a good fit for the capabilities and limitations of the various channels.

Figure 4-3: The diverse capabilities of various channels

While it is common to find organizations that do strategy work, in the end they deliver only generalities—and those at a very high price. At HFI, we always illustrate a motivational and cross-channel solution with conceptual designs. This concretizes the recommendations. In the end, those concepts become the initial foundation for ongoing structural design.

The UX strategy is likely to spawn one or more innovation programs, identifying areas that need innovation in the business model or product design. Many organizations try to innovate by asking their staff to be innovative—they might provide a quick training program on “thinking outside the box,” for example. In reality, a request for lateral thinking is quite different from industrial-strength innovation processes. Serious innovation takes a systematic definition of the context, including the capabilities of the organization and the ecosystem of the customers (Figure 4-4). An innovation process creates many ideas and then determines those worth applying.

Figure 4-4: Results of a systematic innovation program about online security

Two kinds of assessment methods may be employed. In a usability test, designs are evaluated by having representative users attempt to use the facility or be interviewed about the facility. In an expert review, trained experts in user experience design systematically investigate the design based on research-based principles and models in the field. You might think that the user research is much better than the expert review, but, in fact, the expert review is usually faster, cheaper, and better. User research might result in solid data that the user takes three minutes to complete a transaction. But what does that mean? Is three minutes good? An expert, in contrast, might immediately point out that default values can be used to slash the time requirement. In reality, the best application for usability testing as an assessment is when strong political issues are preventing stakeholders from listening to the expert.

You need different methods to investigate whether people will do a task as opposed to assessing whether they can do a task. PET is HFI’s acronym for persuasion, emotion, and trust. The methods we use to check whether people get confused while using an application don’t really work when we are trying to understand whether they will be motivated to convert. Today usability is no longer enough. It is certainly an expected hygiene factor to have a checkout flow that everyone is able to use, but assessing the customer’s willingness to actually buy the product requires different methods.

Figure 4-5: Example of an ecosystem around ATMs showing scenarios, users, and other elements

The second type of research that user experience design practitioners undertake is a controlled experiment. This scientific research study, with proper controls and statistical analysis, is needed when a critical decision must be made between two different designs and millions of dollars hang in the balance. A controlled study is clearly justified when you really need to be certain which design is better. Controlled experiments are also appropriate to support marketing assertions. For example, HFI recently had a smartphone company approach our firm and tell us the blogosphere had proclaimed that they had the fastest keyboard. The company wanted scientific backing for the claim so it could own that distinction and make it the core of a marketing campaign. So we ran the study (the company’s keyboard was the third fastest).

It is often best to complete the structural design before planning the detailed design. The structural design will create the overall container for the interface (Figure 4-6). It defines how the user will navigate, and if done well this structure will match the user’s deep mental model. The result is that the design will seem obvious and laid out in a common-sense manner. The user will be able to find things. The navigational container must also be physically efficient. It must fit with the user’s taskflow so as to minimize the time and physical effort involved. Finally, it must define the persuasion strategy and the style of the site.

Figure 4-6: Example of a structural redesign

The structural design takes a high level of expertise. Once it is done, however, it is easy to plan the ongoing detailed design. Each screen must be fully designed and specified. It is easy to find good structural designs that are built out with poor detailed design: they are good-looking and easy to navigate, but awkward and frustrating as the user proceeds through the interaction.

The detailed design work is easier than the strategic and structural design, but often involves quite a bit of work, and it is critical to maintain quality throughout this step. The detailed design must be guided by user interface standards (or patterns). Detailed design also requires staff who understand a wide range of design methods, principles, and techniques. It cannot be left to graphic artists or business analysts unless they are competent in user experience design principles. The detailed design process also generally requires cycles of usability testing, so that skill set is essential as well.

The last phase of the user-centered design process, continuous UX measurement and improvement, is often neglected, but is potentially a great investment. If the design is for a large application, it pays to make ongoing improvements. At HFI, we once changed just one page on an office supply company’s website and increased sales by an estimated $6 million per month. Ideally, you will create an ongoing dashboard that provides an array of UX measurements. This can allow you to track the impact of the ongoing work done on the design.

Generally companies have good business metrics on their sites and applications. And in a sense that is exactly the focus of UX work. We really care only that our work has increased conversion, saved time, and reduced call center load. Why, then, would you need user experience design metrics in addition to the business metrics?

By having specific measurements for user experience design, we can tell if that design is likely to improve the business metric. If both the business metric and the user experience design metric yield poor results, then design improvements will most likely be helpful. If the business metric is poor but the user experience design metric is great, then the problem probably stems from something else, such as pricing, marketing, or even the executive intent.

To take the test, look at the 15 design activities described in Table 4-1. Check which ones are included in your methodology, and then add up the points to get your Usability Quotient. The maximum rating is 100. If your methodology scores less than 75 or so, it is probably in need of enhancement. If it scores less than 50, you probably need a whole new process.

Table 4-1: Calculate Usability Quotient

Occasionally, a company needs a whole new development process. This scenario occurs not just within brand-new organizations; a new development process may also be needed when there is a major change in the technology or scope, such as the switch from simple Web brochures to complex Web application development. Usually, however, the organization already has a software development process and needs to deal with the relationship between the existing process and the newer user-centered design methodology. The methods have to be interwoven with proper communication and handoffs between the different types of development staff. There may need to be particular stage-gates to verify that the required user experience design work has been done in one stage before proceeding to another.

There are three likely scenarios when there is an existing process: classic methodologies that are not user-centered, patches where some user-centered activities have been added, and classic methods that just have usability testing added. These same situations tend to appear in commercial methodologies that do not have an ideal user-centered process. The following subsections explore these three scenarios in greater detail.

Both software methodologies and user-centered design methodologies have many steps. These steps are important for each methodology, and they need to be completed in a certain order. However, the steps are different. Trying to retrofit the steps of one methodology onto the steps of the other methodology does not work, just as trying to force the tools, templates, and documentation of one to fit the other does not work.

Without a full user-centered process, performing a usability test at the end of the development process merely serves to highlight the unacceptable nature of the design. It’s a sad and frustrating result, but there is usually little that can be done except to release the poor design.

With a user-centered process, the usability test becomes a source of useful, easily implemented changes. These changes are not radical because the structural design has been solidly built and tested; there is no need to throw it out when problems crop up. The insights provided by the usability test tend to be small—in the form of minor changes to wording, layout, and graphic treatment—and easily implemented. Yet this type of final usability testing is well worth doing.

Implementing full user-centered development can be compared to creating a wooden statue. In the early phases, there is sawing. Then, you need to switch to a chisel. Finally, you apply sandpaper. The final usability testing becomes the fine sandpaper. Without the full user-centered process in place, the development effort is just like trying to create a wooden statue by starting with fine sandpaper.

Figure 4-7: Example of a template