This project is read-only.

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.

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:
  • Agile user-centered design resulted in better-designed software than waterfall user-centered design. Agile communication modes narrowed the gap between gathering usability data and acting on it.
  • Because Agile development is highly feedback-driven, product teams may rely on user opinion in situations where user observation is more appropriate. Usability practitioners can be the best-suited members of an Agile team to mitigate this bias because of their skills in gathering and analyzing user experience data.
  • It is possible to use the familiar arsenal of usability investigation methods on Agile projects, including formative usability testing, user and task analysis, interviews, and even field-based work like contextual inquiry. This is achieved by changing the timing and granularity of the investigations, and how results are reported.
  • usability and design activities can be scoped as incremental mini-designs. Different validation and elicitation activities can be blended within single sessions conducted at a usability lab or in the field. Design activities occur at least one Agile cycle or sprint ahead of the development team in an Interaction Designer Track separate from the Developer Track. Developers receive validated designs.
  • Prototype demonstrations and daily conversation have largely replaced detailed documents such as usability test reports and UI specifications when communicating with the product team. Documents are now written for interaction designers, to record a history of design decisions.
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:
  • Agile offers many opportunities for overcoming problems with traditional development methods that have long impeded usability.
  • Approaching Agile narrowly, as a programming methodology rather than a system development methodology, threatens to destroy the last decade's progress in integrating usability and development. But, as outlined above, there are ways around each of these threats. So long as teams recognize the threats as explicit issues, they need not harm product quality.
  • Finally, we know from our research that many companies have made things work swimmingly — once they adapted the Agile methodology to suit quality-focused system development. … For user experience practitioners who support Agile teams, the main change is in mindset. Having good, general user experience knowledge will help you understand how to change traditional design and evaluation methods to meet your Agile team's different focus. Ultimately, however, you must both believe in yourself and embrace Agile development concepts if you want to succeed.”

Recommendations for Success

  • Here we summarize a list of recommendations by Jeff Patton, an expert in User-Centered Design and agile methods stststPattonOnAgileProductDesignfififi and others:
  • Help product managers understand and balance business and user goals; Use end-user testing as a way to give voice to end user needs to balance them with business goals stststSyOnAgileUCDfififi.
  • Help product development team understand the underlying product experience and define interaction and visual design patterns
  • Do just enough user research and design to get started but plan for ongoing user contact for research and validation.
  • Involve the development team in the interaction design; become a design facilitator rather than purely a behind-closed-doors designer.
  • Focus on big picture, help the product development team set the context
  • Validate usability before development through the use of low-fi prototyping and testing stststAstonMeszarosOnAgileUsabilityfififi
  • Validate usability after development (through lightweight usability testing on developed features)ststst AstonMeszarosOnAgileUsabilityfififi
  • User parallel track development to work ahead and follow behind stststMillerOnCustomerInputfififi and allow development to proceed on back end functionality in parallel with interaction design stststConstantineOnParallelUxfififi to avoid separate interaction design phase.
  • Increase the frequency and timing of end user involvement: build a ready supply of users and user surrogates inside and outside of your organization to leverage for continuous user testing. Consider scheduling regular user test sessions and defer deciding what to test just-in-time.

Last edited Nov 5, 2009 at 11:26 PM by rburte, version 2


No comments yet.