Method

Our method for using HTML in early UI prototyping consists of 4 steps. At each step the prototype consists of an HTML page that can be viewed in an HTML editor or web browser.

Step 1: Address Issues of Provided Functionality and Content

• Make a rough outline of functions provided by the system.
• Group related functions together.
• Identify classes of users.
• Make initial assumptions about available resources: I/O hardware, events, and conditions.
• HTML constructs used:
  • A single page of indented text, unformated.
  • Optional: Links into requirements documents.
• Evaluation:
  • Do you cover all functions needed for common user tasks?
  • Are there critical tasks that you have not considered?
  • Are the available resources sufficient?

Step 2: Break Content into Screens

• Use HTML horizontal rules to break content into screens. Start with one screen per major function.
• Add additional transition and confirmation screens as needed.
• Define logical user interface events that should be detected on each screen.
• HTML constructs used:
  • Horizontal rules.
  • Anchors defined for each screen.
  • Bracketed terms label events. (e.g., [CashRemoved] or [TimeOut])
  • Optional: Links into discussion of tradeoffs and open issues.
• Evaluation:
  • Are there too many screens?
  • Are individual screens too complex?
  • Can needed events be detected? (e.g., an ATM knows when you remove your cash)

Step 3: Address Issues of Screen Flow

• Define links between events and resulting screens.
• "Run" the prototype in any web browser.
• Move content among screens to improve screen flow.
• HTML constructs used:
  • Local links.
• Evaluation:
  • Is the length of a typical session too long?
  • Are there too many steps needed for common tasks? (e.g., withdraw $40)
  • Is navigation straightforward? Are provided navigational aids sufficient?

Step 4: Address Issues of Presentation

• Format screens to roughly look like finished product.
• Bind some logical events to physical buttons.
• HTML constructs used:
  • Tables with fixed sizes.
  • Optional: Use images to increase fidelity of key screens.
• Evaluation:
  • Is there enough space to show all information on a given screen?
  • Is the rough layout of each screen clear? Consistent?
  • Are key screen elements easy to find?
  • Are messages phrased clearly? Appropriate for context?

Step 5: Gather Metrics and Feedback from More Evaluators

• Break screens into separate HTML pages.
• Visualize overall UI structure using web site mapping tools.
• Add hit counters to pages or use other monitoring techniques.
• Use email links or HTML forms to gather feedback from evaluators.
• Invite a wide range of people to evaluate the prototype.
• HTML contructs used:
  • Multiple HTML pages.
  • Hit counters.
  • email links.
  • Optional: HTML forms.
• Evaluation:
  • Does the site map reveal sequences that are too long? dead ends? parallel structures?
  • Which pages get the most traffic?
  • Which pages get the least traffic? Which are never used?
  • What are do the evaluators have to say?

At any step: Make use of HTML and the web

• Placing UI protoypes on web pages allows people other than the author to access and evaluate them more easily.
• Use text to annotate the prototype.
• Use links to connect key parts of the prototype to requirements or discussion of open issues.
• Place the page on a web site (internet or intranet) to make it more accessible to evaluators.
• Add email links to direct feedback from users to the author.