Documentation and Methods of Refinement

Each document produced should take the project one step closer to completion. Methods to refine (improve) the design of a product:

1. Scenarios - stories about what it will be like to use the product or service once it has been made. Protagonists - personas. running each persona through a "fist-time use scenario" can reveal how to tailor the final design to appeal to and work for each persona.
2. Sketches and Models - visualizing concepts and ideas (currently - with physical tools and drawing surface). Most helpful when the ideas are still being formed to help clarify and communicate them.
3. Storyboards - image panels with accompanying text that can be drawn directly from scenarios. Helps to illustrate the product/service in use and key moments of an action.
4. Task Flows - putting tasks (defined in task analysis) into a sensible order/flow. Helps to see where the users will have to perform certain actions, where the decision have to be made and helps to clarify implementations of controls.
5. Use Cases - UML (for developers). Explains in plain language what a certain function does and why. Time consuming, but good for breaking down tasks and showing what the system will have to support. Form of a use case:
   1. A title - should be descriptive
   2. The actors - who is performing the function? (ex: user, system)
   3. The purpose - what is this use case meant to accomplish and why?
   4. The initial condition - what is happening when the use case starts?
   5. The terminal condition - ...ends?
   6. The primary steps - discrete moments in this piece of functionality.
   7. Alternatives - other use cases that may consider the same functionality.
   8. Other use cases used - the ones that this use case is built upon (if there is).
6. Mood Boards - means for designers to explore the emotional landscape of a product. Collage of images, words, colors, typography and others (audio, video..).
7. Wireframes - set of documents that show structure, informations hierarchy, controls and content. The most important document that interaction designers produce when working on product. Designers need to accomodate the needs of various audiences, who want to see different things in the wireframes:
   • Clients - how design meets their business goals.
   • Developers - how the product works (ex: what happens when an error occurs, so that they know what to code).
   • Visual/industrial designers - what visual/physical elements need to be designed (ex: types of buttons).
   • Copywriters - what they need to write (ex: help texts, manuals..)
   • Designers - to remember details (ex: why there are two buttons instead of one for a certain feature).
   Wireframes have three main areas:
   1. The Wireframe itself - a detailed view of a particular part of a product. Three factors:
      1. Content (ex: text, movies, images, icons, "placeholders" if the content is not ready yet)
      2. Control / functionality (ex: buttons, sliders, input boxes, knobs and accompanying labels and feedback to those controls)
      3. Navigation (ex: methods, such as hyperlinks, drop-down menus, toolbars with widgets and complex manipulations)
   2. Annotations - brief notes to understand not just what the feature (ex: button) does, but also why it is there. Wireframe objects that should be annotated:
      • Controls (ex: what happens when a button is pushed)
      • Conditional items (objects that change based on the content)
      • Constraints (anything with a business, legal, logical or technical constraint, ex: the longest length of a password allowed)
   3. Wireframe Metadata - information about the wireframe. Every wireframe sould include the following:
      1. The designer's name
      2. The date the wireframe was made or changed
      3. The version number
      4. What has changed since the last version
      5. Related documentation (ex: business requirements, technical specs, use cases.. with specific page number)
      6. Unresolved issues
      7. A place for general notes
8. Service Blueprint - "wireframes" for services. Two major elements:
   1. Service Moments - discrete moment that can be described (ex: customer pays).
      • There can be multiple designs for each moment (ex: pay with cash, debit, credit).
      • Which touchpoint is or could be used during each service moment? (ex: a sign listing the costs of services and an attendant who takes the customer's money). All of these elements should be designed.
      • Each moment should have visual representation (sketch, photograph).
      • What service elements are affected: the environment, objects, process, people invilved.
      • Designers should especially look for service moments that can deliver high value for low cost.
   2. Service Strings - putting concepts for various service moments together to form "storyboard / scenario" that demonstrate what the pathways through the service will be. Big idea for the service in written and visual form.

References and further readings

• Dan Saffer, "Designing for Interaction: Creating Innovative Applications and Devices", 2nd Edition, (2009), chapter 7
• The rest of the summary of Chapter 7 "Refinement": The Law and Principles of Interaction Design, Frameworks, Controls and Inputs
• Human-Computer Interaction & Cognition: reading list