Project Plan

Fluid UX Walkthroughs - Purpose and Scope

The UX Walkthrough Project

The project has two main goals:

1. The first goal is to create procedures, guidelines, protocols, checklists, and reporting formats for evaluators to use when conducting actual reviews of products.
   
   
2. The second goal is to coordinate the efforts of those who are performing the evaluations, and capture their raw results for analysis, integration, and publication.

The deliverables associated with the first goal comprise the set of mechanisms we develop to enable pursuit of the second.

Deliverables

• Guidelines for target selection
• Pre-selected targets
• Personas
• Scenarios
• Protocols
• Method descriptions
• Prescribed procedures
• Checklists
• Examples
• References
• Reporting templates

Issues

• Coverage 3 products, 3 methods, two dimensions (accessibility and usability)
• Result reporting
  • Common reporting templates
  • Integration of results - analysis across products
  • Publication - audiences/consumers (designers, developers, institutions, product communities, funding bodies)
• Result interpretation
  • Distilling observations
  • Identifying pain points (user problematics)
  • Assessing frequency and severity
  • Identifying solutions
  • Proposing components
  • Ranking and prioritizing

Activities (this list corresponds to cardmeeting.com entries C1-C8)

1. Create a coherent set of web pages in the Fluid wiki containing guidelines and protocols to guide the efforts of evaluators.
   • Highlevel protocol and guidelines
   • Checklists, principles, and protocols (step by step procedures) for conducting walkthroughs
   • Reporting templates
2. Create and document some basic resources for reviewers
   • Procedures for selecting target product instances
   • List of pre-selected product instances for review
   • List of personas
   • List of scenarios
3. Create standard mechanisms for processing the results of walkthroughs
   • Distilling observations
   • Identifying pain points (user problematics)
   • Assessing frequency and severity
   • Identifying solutions
   • Proposing components
   • Ranking and prioritizing
4. Create mechanisms for producing other artifacts from walkthrough results, and publishing
   • Design patterns
   • Guidelines and approaches for developers
   • Pitfalls to avoid for developers
   • Other rules of thumb for developers
   • Messages to communities
   • Messages to stakeholders (e.g. funding bodies)
5. Integrate all of the above as part of the Design Handbook
6. Assess coverage achieved to date over 3 products and 3 methods, for both accessibility and usability
7. Create a mechanism for triggering walkthroughs when they are required by the Fluid project (Wave Planning)
   • Observed need for coverage such as new or changed product functionality
   • Release cycle - e.g. every couple of milestones
   • Other triggers
     • before general release of componentry
     • project deliverables: e.g. report to funding bodies
     • prioritization: e.g. pain point impact
8. Create a process to initiate, coordinate, and conduct walkthroughs as required
   • List coverage required (from Wave Planning)
   • Assemble the reviewer teams
   • Select protocols and resources
   • Conduct the walk-throughs

Ongoing Program

As one of the drivers for component creation, walkthrough evaluations are conducted as part of a long term, but cyclic program. The need for walkthroughs arises when:

• There is a need to discover pain points (user problematics) in the core Fluid target products.
• A new product is added to the list of core targets.
• It is demanded as a project deliverable (i.e. not product deliverable) such a reporting to a funding body
• New versions of the products enhanced by Fluid components are put into production (for comparison).
• Important new personas or interaction scenarios are discovered.

It is assumed that walkthrough activities will occur in waves throughout the duration of the Fluid project.