Chapter 12 - User Experience Specialist’s Perspective

See the User Experience Specialist persona in the company stereotype called “A Product Company” in Appendix X – Reader Personas for an example.

As a person with the responsibility of user experience you may be responsible for designing the user experience associated with the product. This may involve various kinds of activities to better understand and characterize the potential users including ethnographic research, user modeling, task modeling, etc. It likely also includes verification activities such as usability testing at various points throughout the design and development process.

The Role of User Experience in the Acceptance Decision

It is important to have a clear understanding with the product owner (product manager or business lead) as to what your role shall be in making the acceptance decision. It could be any of:
  1. Being an input into the product definition process but no direct involvement in the acceptance decision. That is, helping the product owner define the product but leaving it to other parties to define the acceptance criteria.
  2. Being an input into the software development process with no involvement in the acceptance decision. This is similar to the first point but working more closely with the software development team rather than the product ownership / definition team.
  3. As in point 1 but also providing usability testing data for the acceptance decision made by the product owner.
  4. As in point 1 and 3 but also having a say in the acceptance decision either as part of the product owner’s team or as a part of a separate, parallel acceptance decision.For products where usability is a key differentiator, the preferred role would be either 3 or 4. For products with captive users such as systems developed for internal users it is more likely to be 1 or 2.
In any of these models it is important to work with the business lead or product manager to define the usability component of the acceptance criteria as early as possible to give the development team as much guidance as possible. Early in the project this may consist of descriptions of the kinds of testing procedures that will be used to verify usability; later in the project, it may be specific functionality to be tested such as the novice user’s top 5 transactions, specific usability guidelines to be complied with, and so on.
Where usability is important and how to achieve it is unclear, it is crucial to address the usability risks as early as possible. Some of these risks may be addressed through the use of low cost usability testing techniques such as sketching and Wizard of Oz testing, a form of low-fidelity usability testing conducted with paper products and mock-ups. Visual communication is very powerful to present and validate ideas. bility to gather feedback from the users effectively is as important as production of the prototypes. Figure 1 presents a sample low-fi electronic prototype built with Microsoft SketchFlow stststSketchFlowfififi that a user is able to preview in a browser and provide rapid feedback.
Figure 1
Figure 1. User adding feedback on a SketchFlow prototype
Other situation may require the construction of electronic prototypes for higher fidelity usability testing. Construction of special purpose high-fidelity prototypes may be avoided if the actual system can be built and delivered incrementally sequenced by usability risk. This may require working with the product owner to help them understand the risks and consequences and to use these to influence the order in which functionality is built. Usability-related risks can be mitigated by defining an internal milestone at which sufficient functionality is available to allow usability testing of the actual product with real or proxy users. This requires collaboration between the product owner and the supplier organization to do incremental development and delivery of the software based on the usability test schedule. The areas with highest impact of usability issues should be built and tested first to ensure enough time for any usability-related issues, which may be pervasive enough to have a wide-ranging impact, to be addressed before the cost of change has become too high.
Where the product owner has not specified incremental delivery it may be possible to work directly with the development manager to arrange for opportunities to do usability testing using early versions of the actual software system.

Note:
Sidebar: Marrying Usability Practices with Incremental Development MethodsA commonly held opinion is that Interaction Design and Usability Testing need to be finished before software development can be started. This is in direct contradiction with the agile approach of incremental development. Modern product development timescales often preclude a separate “design phase” so the work of usability specialists needs to be done within the development iterations as the project unfolds rather than before their start.
A number of case studies demonstrate that Interaction Design and agile methods do not need to be at odds with each other. In stststAstonAndMeszarosOnAgileUsabilityfififi Janice Aston and Gerard Meszaros compare two phases of an agile where lightweight usability practices were incorportated into the second release. They used paper prototyping and Wizard of Oz testing to validate the user interface design and saw significant improvements in usability and user acceptance. The benefits were so significant that in a subsequent project the business partners initiated the prototyping and user testing activities without prompting from the IT department.
In stststMillerOnCustomerInputfififi Lynn Miller concludes: “The Usability Engineering team at Alias has been gathering customer input for many years, but never as effectively as when we work with an agile development team. For SketchBook Pro, we were able to maximize the quantity and impact of customer input by having the interaction designers work in a parallel and highly connected track alongside of the developers. Daily interaction between the developers and interaction designers was essential to the success of this process.”
In stststSyOnAgileUCDfififi, Desiree Sy describes how Alias Software (now Autodesk) adapted their UCD process to support agile development. She concludes: In stststMcInerneyMaurerOnAgileAndUCDfififi, Paul McInerney and Frank Maurer describe three case studies of how user experience specialists integrated with agile teams and report various techniques from pair observations to informal usability testing in the team room with the latest build involving both developers and customer proxies.
Many notable advocates of usability practices describe techniques for adapting them into agile methods. Jeff Patton has a web site stststPattonOnAgileProductDesignfififi and a Yahoo! Group dedicated to the topic of agile usability and product design. In stststMeszarosOnAgileProductDesignfififi Gerard Meszaros writes that on most projects there is plenty of time to understand the users and their goals and to do the overall product design activities called for by UxD methods before iterative development starts because the business case needs to be made and funding needs to be secured before the programmers can start developoment.
Larry Constantine has pointed out that even when this isn’t the case, there is usually some back end (or technical development) that can be started immediately that does not depend on the interaction design or the user interface stststConstantineOnAgileUsabilityfififi.)
In stststNielsenOnAgileUsabilityfififi, Jakob Nielsen (known as “the king of usability”) writes: “There are good reasons to believe that usability and Agile development methods can work together and improve user experience quality:

Recommendations for Success