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 work Having a vague idea that you should conduct some sort of user testing on software products will be swept aside if time pressures mount Scheduling 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 sal·vo. sal·vo 1. a discharge of artillery or other firearms in regular succession, often performed as a salute. 2. a round of cheers or applause. Websters 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: Its hard to document all user-system interactions Needs change while system is under development Systems affect user actions in unexpected ways Its better to approach UI design with a model that plans for iteration, for example: Artillery SALVOs last until the targets destroyed SALVOs 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 whats 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 types Command-line and menu-based UIs Graphical user interfaces (GUIs) Web user interfaces (WUIs)
The Five SALVO Steps Planning processes Arrows indicate iteration paths; bold arrows show the major paths where iteration typically occurs Testing process S Specify UI Determinants A Adopt System Standards L Leverage User Abilities V Visualize Before Creating O Observe After Creating
S Specify UI Determinants
S Specify Determinants Intro Specify means: Write it down in simple terms Be specific; no abstractions or generalization Determinants are: Factors that research and experience have found to be important in determining UI design Major determinant categories relate to: Task User Environment
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 it Be specific, providing actual data if needed for interaction and scenarios that situate each task Include simple and complex tasks Choose 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 vision Language skills Prior experience Dont 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 clients 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 applications Avoid 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, 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 sets Keeping the set of required skills to a minimum Using the same skill whenever possible where circumstances (contexts) are similar Using 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 dont overlap among subgroups, you should build in distinct support for subgroups AVERAGE USER NOVICE USERS EXPERIENCED USERS AVERAGE USER NOVICE USERS EXPERIENCED USERS No overlap; support both subgroups
V Visualize Before Coding
V Visualization Intro Visualization is used to: Speed up development processes Increase opportunity to explore design options Two visualization methods are especially useful in UI design: Cocktail napkin visualization Mock-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 window Use 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 unstable Over-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 application Vertical UI mock-ups provide detailed view of a specific part of the application UI mock-ups may be produced on paper or by using rapid development tools, e.g. Visual Studio Missing 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 actions Assists 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 cant progress without help Backtracking – user retraces steps due to uncertainty of how to proceed Misappropriation – user attempts to use wrong tool or access method Accessing 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, Ill 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 stages But projects with few users offer less benefits from continued iteration than project with many And 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 Sals a professional, so hell be okay as long as he performs perfectly... Just one slip and its a 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