Human-Computer Interaction Course in Short, week 3 — Rapid Prototyping

Igor Goncharov
5 min readMar 23, 2016

--

Key thoughts from Scott Klemmer’s HCI course on Coursera, October 2015.

Rapid Prototyping

On choosing the right prototyping tool

One of the easiest mistakes is starting to make an interface before focusing on a task this interface is going to support.

Example of a storyboard

Storyboards

Storyboarding isn’t about “pretty pictures”, it’s about communicating ideas.

Storyboards should convey

Setting:

  • People involved,
  • Environment,
  • Task being accomplished.

Sequence:

  • What steps are involved?
  • What leads someone to use the app?
  • What task is being illustrated?

Satisfaction:

  • What motivates people to use this system?
  • What does it enable people to accomplish?
  • What need does the system fill?

Benefits of storyboarding:

  • Holistic focus: Helps emphasize how an interface accomplishes task;
  • Avoids commitment to a particular user interface (no buttons yet);
  • Helps get all the stakeholders on the same page in terms of the goal.

Set a strict time limit for making a storyboard, like 10 minutes. It should be rough sketches, so the attention would be paid to the content only.

Paper prototyping

Materials:

  • Widgets: paper, cardboard, transparencies, post-it notes;
  • Connectors: tape, glue, rubber cement (removable ones are useful for changing components quickly);
  • Drawing: pens, pencils, markers (preferable to use thick ones as they’re more legible);
  • Stack of index cards to simulate tabbed dialog boxes;
  • etc.

Tips and tricks:

  • Keep all the materials in one place (not to get them lost or damaged);
  • Work quickly and make reusable components (e.g. buttons);
  • Verbally describe the interaction that is hard to simulate (e.g. progress indicators, context menus);
  • Use backgrounds to get the context to the user (and contain the prototype itself). It could be a photo of the device or the device itself;
  • When appropriate, add context by including familiar OS elements;
  • Test multiple prototypes simultaneously to get most value.

Get users and other stakeholders to help design. Scaffold their efforts — give them a pen!

Wizard of Oz Technique

(by Steven Dow)

  1. Make an interactive application without (much) code
  • front-end interface;
  • (remote) wizard controls UI;
  • make sense when it’s faster/cheaper/easier than making a real thing.

2. Get feedback from users

  • hi-fidelity: users think it’s more real;
  • low-fidelity: more license to suggest changes.

Making a wizard-powered prototype:

  1. Map out scenarios and application flow (what should happen in response to user behaviour?);
  2. Put together interface ‘skeletons’;
  3. Develop ‘hooks’ for wizard input;
  4. Figure out where and how the wizard will provide input (e.g. selecting the next screen, entering text, entering a zone, recognizing speech) — later you’ll need to replace this with computer!
  5. Rehearse wizard role with a colleague.

Running wizard-powered prototypes:

  • Practice with a friend first;
  • Once you’re comfortable, recruit ‘users’.

Two roles:

  • Facilitator provides tasks (paper) and takes notes;
  • Wizard operates the interface (more authentic if hidden or remote).

User feedback:

  • Think aloud (speak freely as performing tasks);
  • Retrospective (best when think aloud distracts);
  • Heuristic evaluation (works with experts too);
  • Debrief users (reveal wizard if needed).

Wizards can be used throughout all the development process to fill the gap what hasn’t been developed yet.

Advantages of wizards:

  • Fast (faster) and thus cheaper and more iterative prototypes;
  • Creating multiple variations is easy;
  • More ‘real’ than paper prototyping;
  • Identifies bugs and problems with current designs;
  • Places the user at the center of development;
  • Can envision challenging-to-build app;
  • Designers learn by playing wizard.

Video Prototyping

Pretty much similar to a storyboard, but with more details and context. Can be any fidelity.

Benefits:

  • Cheap and fast;
  • Great communication tool: helps achieve common ground; portable and self-explanatory (ideally);
  • Can serve as a ‘spec’ for developers.

Ties interface design to tasks:

  • Aligns and orients design choices;
  • Makes sure you have a complete interface;
  • And that there’s nothing extra.

What should be on the video?

  • Like the storyboard, the whole task, including motivation and success (establishing shots and narrative help);
  • Draw on tasks you’ve observed;
  • Illustrate important tasks your system enables;
  • Can help scope an MVP (what’s not on video shouldn’t be in the product);
  • Changes what design team argue about (in a good way).

Steps to create:

  1. An outline (or storyboards);
  2. Fine to extemporize;
  3. Equipment:
  • Camera (could be a phone or even a laptop camera; fancy gadgets can be distracting),
  • People,
  • Realistic location.

In general, focus on message more than production values.

Other considerations:

  • Instead of audio maybe use title cards (post-it or something);
  • Interface can be paper, mockups, code, or invisible (just showing the task);
  • Can show both success or failure (of your interface or others’);
  • Edit as little as possible.
Parallel vs. serial prototyping

Creating and Comparing Alternatives

Parallel design got more clicks and more time spent on a webpage. Why?

It separates Ego from Artifact. People don’t stick to the idea. It encourages comparison and transfer.

Sharing multiple designs leads to more clicks in comparison with sharing best or sharing one.

Also these are the benefits:

  • More individual exploration;
  • More feature sharing;
  • More controversial turns;
  • Better consensus;
  • Increase in group rapport.

Alternatives provide a vocabulary for talking about the space of possible designs.

--

--