Vance Wilson, Ph.D. James Connolly, Ph.D. © 2009, E. Vance Wilson - All Rights Reserved The SALVO Method for User Interface Development Hosted by Sal.

Vance Wilson, Ph.D.James Connolly, Ph.D.© 2009, E. Vance Wilson - All Rights Reserved

The SALVO Method for User Interface Development

Hosted by Hosted by Sal VolareSal Volare, , the plucky the plucky

cartoon cartoon cannonballcannonball

Why Adopt a UI Development Process?

SALVO outlines an iterative 5-step process to plan and test usability of software products

Scheduled work drives out unscheduled workHaving a vague idea that you should conduct some sort of “user testing” on software products will be swept aside if time pressures mountScheduling a UI process as part of the overall development plan increases the priority UI planning and user testing

An effective process can avoid UI problems

Examples of UI problems . . .

From the Windows 95 Operating System

Source: Interface Hall of Shame

From the MS Office Development Kit

Source: Interface Hall of Shame

From Pretty Good Privacy Software

Source: Interface Hall of Shame

?

Definition of the term SALVO

salsal··vovo 1. a discharge of artillery or other firearms in regular succession, often performed as a salute. 2. a round of cheers or applause..Webster’s New Universal Dictionary

Why develop UIs with SALVO?

“Perfect Engineering” is a poor model for UI design; designers who work from good user requirements still produce mediocre UIs:

It’s hard to document all user-system interactions Needs change while system is under developmentSystems affect user actions in unexpected ways

It’s better to approach UI design with a model that plans for iteration, for example:

Artillery SALVOs last until the target’s destroyedSALVOs of applause arise to suit the occasion

The SALVO Approach to UI:

Be prepared to “Fire another SALVO” as long as the need exists for continued development

So what’s the SALVO Method?

A basic five-step framework for quickly planning, implementing, and evaluating user interfaces (UIs)

Based on key principles developed by Human-Computer Interaction researchers

Adaptable to all UI typesCommand-line and menu-based UIsGraphical user interfaces (GUIs)Web user interfaces (WUIs)

The Five SALVO Steps

Planningprocesse

s

Arrows indicateiteration paths; bold arrows show the major paths whereiteration typically occurs

Testingprocess

SSpecifyUI Determinants

AAdopt System Standards

LLeverageUser Abilities

VVisualizeBefore Creating

OObserveAfter Creating

S Specify UI Determinants

S Specify Determinants Intro

Specify means:Write it down in simple termsBe specific; no abstractions or generalization

Determinants are:Factors that research and experience have found to be important in determining UI designMajor determinant categories relate to:

TaskUserEnvironment

S Task Determinants

Identify a set of tasks that will be performed using the UI

State what the user is to do, not how to do itBe specific, providing actual data if needed for interaction and scenarios that situate each taskInclude simple and complex tasksChoose representative tasks rather than trying to document all the tasks that are possible

Your task specifications will be used as user instructions during the Observe step

S User Determinants

Seek out user characteristics that your UI design could hinder or help, for example:

Visual acuity and color visionLanguage skillsPrior experience

Don’t assume everyone is similar to you

Talk with real users, not just their managers

S Environmental Determinants

Typical environmental determinants include:Technology – typically included, as the platform that is chosen determines aspects of the UI

Legal & regulatory – may enforce UI standards

Industry practices – may require nonstandard jargon or interaction methods to be included

Security practices – may preclude some actions

Environmental determinants should be included only where you feel they will place significant constraints on the UI design

S How to Specify Determinants

Create an initial list of determinants you expect to be important to the UI

Use this list as a guide of topics to discuss with system users

As new determinants arise during these discussions, add them to the list

Task Determinants

Create a new user account

Modify an existing

User Determinants

Task Determinants

1.Create a new client account

2.Update an existing client’s address

3.Issue an invoice to a client

4.Modify an existing invoice to correct a returned item that was not correctly reported

5.Record a client payment on account

6.Generate a monthly sales report for Oklahoma client accounts

7.Create a mailing list for...

A Adopt System Standards

A Adopt Standards Intro

Technical environmental determinants from the Specify step should guide the choice of operating system

In virtually all cases, the operating system UI standards should guide your design

Using operating system standards will:Maximize consistency among applicationsAvoid time and expense for designers to invent new functions and for users to learn how to use them

A How to Adopt Standards

Acquire the appropriate UI standards guide for your operating system and use it as a reference during UI development

Examples: Microsoft Windows User Experience, Microsoft Press, 1999 Web Content Accessibility Guidelines 2.0, http://nelson.w3.org/WAI/

General UI guides are NOT satisfactory substitutes for operating system standards

L Leverage User Abilities

L Leverage Abilities Intro

Leveraging is achieved by:Building on users’ skill setsKeeping the set of required skills to a minimumUsing the same skill whenever possible where circumstances (contexts) are similarUsing feedback to reinforce similar contexts and distinguish ones that are dissimilar

Leveraging takes advantage of knowledge and skills users already have and explicitly supports users’ deficiencies

L How to Leverage Abilities

Look for abilities to leverage by reviewing the user determinants you specified earlier

Consider both the average abilities of the entire user group as well as abilities of individual users and subgroups

If abilities don’t overlap among subgroups, you should build in distinct support for subgroups

AVERAGEUSER

NOVICEUSERS

EXPERIENCEDUSERS

AVERAGEUSER

NOVICEUSERS

EXPERIENCEDUSERS

No overlap; support both subgroups

V Visualize Before Coding

V Visualization Intro

Visualization is used to:Speed up development processesIncrease opportunity to explore design options

Two visualization methods are especially useful in UI design:

Cocktail napkin visualizationMock-up visualization

Both methods aim to avoid the time and expense of coding UI elements that will have to be replaced later

V Cocktail Napkin Visualization

Quickly draw a rough draft for UI design:The goal is to develop a basic layout for your entire UI, window by windowUse small paper size for each window (¼- to ½-page) Work in private; this is not a group technique

Cocktail napkin visualization avoids:Over-reliance on mental models, which are frequently incomplete and unstableOver-investing in details of a particular design, which leads to premature freezing

V Mock-up Visualization

Substitutes a representation of system parts in place of actual functionality

Horizontal UI mock-ups show broad appearance of overall applicationVertical UI mock-ups provide detailed view of a specific part of the applicationUI mock-ups may be produced on paper or by using rapid development tools, e.g. Visual StudioMissing functionality is represented using the Wizard of Oz technique, in which each function is verbally described when the UI is accessed

V How to Visualize

Cocktail napkin visualization is conducted prior to writing any code

Resulting designs should be annotated to aid memory and can be cleaned up to share with development group and project stakeholders

Mock-up visualization is conducted throughout the UI design process

Avoids necessity of completing all functionality before observing user actionsAssists in getting users’ feedback as soon as possible, avoiding costly rework

O Observe Before Releasing

O Observe Intro

The goal of observation is to completely understand where users have a problem with the UI, whether they are aware of it or not

Problem indicators include:Blocking – user can’t progress without helpBacktracking – user retraces steps due to uncertainty of how to proceedMisappropriation – user attempts to use wrong tool or access methodAccessing help – from observer or on-line source

O How to Observe

Use the think-aloud method:Give user a task scenario and set of tasks

Explain the key points of thinking aloud:

“Say aloud what you are thinking about the system and your actions as you work”

“If you quit talking, I’ll remind you to start”

“The system is being tested, not you”

Observe the user and note problem indicators

When significant problems are noted, return to the appropriate SALVO step and iterate

When to Stop Iterating

Stop Iterating When . . .Stop iterating when the costs of continuing are greater than the benefits; consider that:

The cost of fixing errors after product shipment may be 100 times larger than in design stagesBut projects with few users offer less benefits from continued iteration than project with manyAnd you may run out of users for observation

Stop iterating when it seems safe to put the next SALVO into a planned new release

Consider incorporating planned iterations of the Observe step into each UI development project

Reflections on the Process

Life Without Iterative SALVOs

Sal’s a professional,

so he’ll be okay as long as he performsperfectly . . . Just one slip and it’sa long way down!

Life With SALVO Iteration

But in UI Design,“Slips Happen!”

SALVO provides a safety net that gives Sal the freedom to be creative and even take a few risks.This also takes a load off his mind and puts a smile on his face!

Questions and Discussion . . .

In planned UI development you can always

“Fire another SALVO”