Sylvia Zimmerman — founder of UPA Switzerland, is in charge of the Swiss Institute for Software Ergonomy and Usability in Zurich, and became a UPA vice-president in 2008. She is also co-organizer of the European Conference of UPA in usability and design.

Ronnie Battista — Director of Certification at Usability Professionals Association – International, UPA NJ Chapter, executive director of MISI Company, where he leads the team responsible for Experience Design account management, growth and go-to-market strategy.  He has co-conceived, developed and coined the term Strategic Experience Alignment, which is the alignment of all people and systems with the expereience you want your customers and employees to have in order to achieved strategic business objectives.

Zoll Data Systems makes a touchscreen electronic medical record program for fire and rescue and Emergency Medical Services (EMS) professionals working in the field. Their previous version was outdated and difficult to use. When the company followed a user-centered design process for the first time, the new version fixed a number of critical usability issues and resulted in an extremely successful user experience and a financial success for the company.

The software runs on Windows-based touchscreen tablet and notebook computers. The previous version was successful, but was built on old architecture and technology. The interface was an old-style Windows desktop application, with no workflow. It was not conducive to touchscreen use in emergency vehicles by users wearing gloves and caring for patients, often with severe medical situations.

The previous user interface (shown in Figure 1), used standard Windows desktop interface elements that were inappropriate for a touchscreen interface. Many of the interface elements were difficult to use. For example, there were over thirty icons in the toolbar, making it difficult to remember the functionality associated with each icon. Two rows of small tabs also made it awkward to navigate through the interface, especially using the touchscreen. The text area was also very small. Finally, many non-standard, custom controls were created for common data-entry UI elements, such as dates and times. These custom controls caused many usability problems.

Screen image of the previous interface. It is a busy Windows screen.
The previous interface

The previous interface

Phase 1 – Field Observation and Requirements Gathering

As a usability consultant, I acted as usability team lead for the new user-centered design process. We started by collecting f unctional and usability requirements from existing and new customers and users. The project manager and I rode in ambulances and fire and rescue vehicles in Florida and Texas for four days. We observed EMS and fire and rescue professionals using the product in the field, and gathered their feedback on the user interface. The results from this phase were used to further refine functional and user requirements.

One key observation was that a large number of EMS and fire and rescue professionals, like many others in healthcare fields, are not comfortable with computers and electronic data collection. Their primary role is to care for and transport patients in emergency situations. Many are used to using paper documentation rather than electronic data collection systems (see Figure 2). This observation led us to define additional user requirements regarding training, intuitiveness, and directed workflow navigation.

Photo showing EMS staff in an ambulance using paper system
Paper-based data collection in the field

Paper-based data collection in the field

Phase 2 – Interface Design and Prototyping

The project’s design phase involved iteratively creating and reviewing conceptual and functional prototypes. We also achieved tremendous end-user input and involvement through conferences, blogs, and design reviews. The new design incorporated these key interface design and usability concepts:

* System-driven UI for common tasks (wizard). The new design allows users to enter data in a customer-customizable, field-level and screen-level workflow. Users can also navigate the UI independent of the workflow.
* Auto-advance to the next field or screen when appropriate for tasks. Single-selection fields allow users to enter data and to quickly and automatically navigate to the next field or screen.
* High-contrast color palette (for daylight use). We conducted extensive research on interface design colors, fonts, and contrast for use in extreme indoor and outdoor lighting conditions.
* Buttons, icons, controls, and selectable items are large enough for easy touchscreen access.
* All list selection is made using large-font lists with custom scroll buttons (no drop-down lists). All lists are displayed with large, selectable targets. Large scroll buttons allow page up/down and top/bottom of list navigation.
* Data entry can be delayed until a more convenient time. A customizable “Quick Log” screen allows medics to time-stamp procedures with one click. Then, at any time, users can go back and complete the required information for each entered procedure.
* Immediate validation with hyperlink to error fields. When a patient record is completed, a validation screen displays a list of errors or incomplete fields. By clicking on an item in the list, the user is taken directly to the appropriate field for action.
* Configurable screens and a database-driven UI.

Phase 3 – Final Product Design

After prototyping each functional area of the application and each type of documentation data entry, we turned the prototype and a functional specification over to the development team. As the usability team lead, I worked closely with the developers to review the application interface and interaction as development progressed. We also asked existing customers to review the new application as it was built.

After market introduction, the new product has been extremely well-received by customers and users. Two years of user and business feedback shows that the return on investment (ROI) for the company has been tremendous.

The new product in use

A photo of EMS staff working with a patient in the field, and an overlay of the final product, with a swivelling monitor
The new product in use

The product has received rave reviews and exceptional user acceptance. Training time and costs have been greatly reduced, which is a major selling feature for products in this field where there is high employee turnover. Training time was reduced from one week to three hours. One large customer could not get a competitor’s product up and running for a year. With Zoll’s new product design, the customer went “live” in two weeks without any training.

The interface redesign project cost approximately one million US dollars. Within two years, the new product design enabled the company to gain new and larger clients. They doubled the product’s customer base, more than doubled the number of licenses, and more than tripled the product’s revenue for the company. This success also allowed Zoll to increase the product’s price and offer additional product modules that contributed to the overall product revenue.

While usability improvements often improve a product’s acceptance, the company actually closed many new deals specifically because of the product’s usability and user interface.

Because of the success of this project, new major products or product redesigns within the company follow the user-centered process described here, and incorporate ongoing end-user involvement.
The Evolution of the Design
1. High-level screen layout and navigation area prototype

Screen image showing controls around the outside edges

The new design introduced a new page layout with navigation areas designed to provide consistent and intuitive button location and interaction, while maximizing the main work area of the application.

* Top-level navigation buttons across the top
* Sub-section buttons displayed down the left side
* Application navigation to the inbox and to major actions, such as completing a call, accessing the Quick Log, Scratch Pad, and Options on the bottom of the screen
* Page navigation in the bottom-right corner

2. Prototype screen for specifying the patient’s gender

Screen image showing form to select gender

The vertical area in the left on the main area displays a summary of the data fields in the particular section.

Color highlighting helps users see the status of the data.

* Green fields indicate already entered data
* White shows fields that had not been entered
* Blue highlights the current field.

Selecting a value for the field automatically advances to the next data element in the workflow.
3. Inbox Screen

Screen image showing calls waiting for the ambulance team

The first screen shown after logging in displays the Crew’s Inbox, detailing a list of their current assignments.
Double-tapping an item or pressing the Open button opens that patient’s documentation screens.
4. Data Entry Screen

Screen image with a selection list and on-screen touch keyboard
In this typical screen, the user is filling in the name of the state where the patient was picked up. A list may default to the appropriate state if the company works in one state. A long list, such as state, displays an on-screen keyboard for users to enter letters to more quickly navigate than using the scroll bar area.
5. Graphical Body Navigation

Screen image showing a front and rear view ofa generic body to use for navigation. A list of symptoms is on the left.

Users were most excited about the new design’s use of body illustrations for graphical assessment, navigation, and selection. Users can touch a specific body area to navigate further or to select that area.
6. Body Type Selection Screen

The body type selection screen shows 4 options: male, female, child and infant

Users were able to select the appropriate body type for their assessment. Touching the Body Type button displayed a pop-up window showing male, female, child, and infant body types.

All illustrations courtesy of Zoll Data Systems

About the Author:
Theo Mandel’s background includes over twenty years in the field of user interface design and usability. He earned an M.A. and Ph.D. in Cognitive and Quantitative Psychology from the University of Colorado. He spent eleven years at IBM conducting software interface research, establishing industry-wide guidelines in graphical user interfaces and object-oriented user interfaces (OOUIs), and conducting hardware and software usability evaluations. He’s written two well-respected books in our field. The most recent is The Elements of User Interface Design (Wiley & Sons, 1997). Since 1992, he’s worked as an independent software usability consultant. He was also a co-founder and the chief usability officer for an electronic medical records software company in the late 1990’s. He serves as the healthcare chairman for World Usability Day 2007 and kicked off WUD 2007 at the UPA conference with the case study described in this article. He has worked in healthcare usability for the past ten years.

By Theo Mandel, Ph.D.
All rights reserved

Source

Source

Source

Source

Stop this process

Zaur Giyasov: Wow! In some cases user can do more than expects.

Article is written specially for the conference by request of organizers. October, 2009

One of the things I’ve been saying for years is that just because applications or services or device types change, the basic principles and methods that we use for UX have not and should not change. And, applying them when more and more every-day users are involved becomes even more important. We should still do good UCD and good user research and good user testing/evaluation/validation. But, what has changed over the years is how those things can and should be done for the most return on investment (ROI). Two things really matter when looking at which activities to perform and when: the cost of those activities, and the expected improvements you will get or the potential lost that might result by not doing them. In general, we’ve never had enough time or money or resources to do everything we wanted to do, so picking carefully, no matter what kind of project you are on, makes good business sense.

Discount Methods

Discount methods have been proposed and championed by such folks as Jakob Nielsen and Jared Spool for over 20 years now, saying, for example, that “the best results come from testing no more than 5 users and running as many small tests as you can afford.” (1)

The basic idea here is this: qualitative studies are less expensive to run than quantitative studies, and deliver faster, cheaper ROI. As Nielsen states: “you don’t have to measure usability to improve it…….When you see several people being stumped by the same design element, you don’t really need to know how much the users are being delayed.” (2) For example, in one of my tests this past year, we observed 2 users fail with the same task. Here, we didn’t even wait to test the other 3 users, but instead, revised the design, and began testing again with the new design. The next 3 users were successful in the task.

So, doing heavy-weight methods, even if you can, may not be the best approach. And, what matters more and more to the business is not just doing something right, but doing the right thing. It’s entirely possible to produce a product that is very usable, but is not one that your users want to use because it doesn’t do what they want to do. Being able to actually influence what is built in addition to how it is built is where we can have the most impact. And, to do that we need to be talking to our users. Early. Often. Continuously. And, three methods that are the most useful in discount usability are:

• Rapid usability testing using qualitative methods
• Quick-and-dirty prototypes to get things in front of users rapidly – paper is very good here
• Heuristic evaluation by your own team – you can catch a lot of things yourself

Now, the one thing missing from this list above is basic user research (e.g., task analysis, contextual inquiry, observation, interviews). As Hurst says, without talking to your users and knowing the direction to set for the discount methods, it’s a matter of “Ready-Fire-Aim” or, doing good things for the wrong reason. (3) User research has traditionally taken a lot of up-front time and does not fit in well with rapid iterations. But what if you start combining the methods, or at least combining their use with the same users in a single session?

While methodological purists may cringe (and even when I teach, I teach them separately), over years of experience, I’ve been blurring the lines more and more between doing user research and doing user testing. Recently, I’ve noticed others have been going in the same direction, so my assumption is that it has a lot to do with our evolving role and how we do our work.

In a recent article, Chisnell talks about using usability testing as more of a formative tool than how we usually think about it as a more summative tool. She asserts that usability testing should be done “wherever and whenever users normally do the task they’re trying to do…” (4) While I do believe that usability testing is a powerful tool for us to have in our UX toolbox, I’ve thought for years that testing in a lab is an artificial environment. You have to ask yourself how accurate the data is for everyday use of a product. Will those things that come up during normal use come up during your lab test using your scenario? Is it even less true for more consumer-type products? And, for that reason I really like trying to do more of this kind of evaluation on site with users in their own work environment.

Let’s take an example. Suppose you have an existing product that you need to do some major re-design for. In order to do that, you really need to find out what is critical to keep and what can be discarded – critical to what the user needs to do, that is. So, how might you go about that? Well, one way might be to do some site visits with your current users. Watch them use the current product for awhile. Then begin asking them questions about what they are doing, why they doing that, what they cannot do that they would like to, and the like. Then, moving from more of a user research stance to a testing stance, you might put a few alternative designs in front of them and ask if any of these might help them with that task or make it easier. Engage them in a bit of participatory design as well as a bit of evaluation of what you are proposing. Does it make it better? What else might they suggest? One of the really cool things about having a more open set of alternatives is that the users are generally more willing to engage in a conversation about their needs and wants as opposed to being presented with one design which they tend to say “yes” or “no” to.

Further down the road a bit, once you have something that is actually mocked up or coded, having them try to use it in their own environment with a task they were just doing also tends to tease out a bit more of the things they would encounter day-to-day rather than testing something rather more disjointed in the lab. One of the things I discovered, for example, is how much interruption one of my user sets was encountering. So, when they finally came back to the product to continue what they were doing, they could not recall where they were or what they had selected to get there. This highlighted quickly and clearly the need for more onscreen noting of these sorts of things so they could remain “grounded” in their task, something that had never come up in the lab. And users tend to tell you lots of stories about things like the last time Y happened to them. The stories are really powerful collateral for the design work.

Roughly 10 years ago, I started using more and more user stories and storytelling in my work. (5) The words and experiences of the actual users have a power to help us understand their needs and activities more deeply, and to more effectively be able to relate to them, and to communicate those experiences with others on our teams. Simply telling a developer to add Feature A is not nearly as compelling as telling them the story about how User X is currently doing their task, what frustrations they are going through, and what happened the last time they tried to Task B. It makes it more real.

How do you get user stories? From the users of course! In doing user research, you can prompt for them during contextual inquiry or interviews, and, you can also prompt for them during evaluations as I mentioned earlier.

Stories influence user scenarios and use cases, and can fit nicely into our development processes. But, then development processes for many teams changed as they adopted agile development methods.

How and Why Does Agile Change Things?

Agile software development processes vary, but generally they have in common the following factors:

• Customer input on an ongoing basis
• Rapid iterations
• Delivering work value quickly

UCD/UX designers, while they certainly favor customer input on an ongoing basis, also tend to work with a lot of up-front design and user research, hopefully well before development begins. So, when agile development mixes analysis, design, development, and delivery throughout the process, it means that the UX person’s work will necessarily need to adapt to this new model.

Now while there are some folks who believe that UX and agile development are at odds with each other, I look at it as a marvelous opportunity to have the kind of input and focus we’ve been wanting for years. How many times have you found something that is highly desired by the users but you are told by the development team that it will need to wait for the next version?

With agile development and doing re-prioritizing and planning for each iteration, it is much easier to get those important items considered and included. It also lowers our risk of delivering a bad user interface as we have early user input and several iterations to make substantial improvements. Using the concept of parallel UX and development tracks makes this whole process much easier. And, a similar process can work for UX consultants who are not part of the team as they can work on items in a separate-but-linked manner.

Working as I have been doing on an agile team has almost forced combining different activities in the same time slot with the same user. When we do a usability test in our lab, for example, we might do a number of things with each user while they are there. We might get their input on some design alternatives for features for the next iteration. These are usually done in lower fidelity to encourage discussion. And, we might get their input on some of the features for the current iteration – perhaps we have a couple of questions about some implementation details. And, we might have them test some coded tasks from the previous iteration to evaluate if it meets their needs and our goals.

The use of stories fits in nicely as we are supposed to be developing things that the user actually needs, in priority order. And, stories do one more thing really well: they help the team to look at the whole user experience for coherence instead of just looking at a single feature or iteration.

And those discount methods we talked about earlier? They actually work very well with the agile methods because you can test with a small number of users once or more per iteration, and, with many iterations, you end up running a lot of tests but refining and evolving your designs as you go. And, in agile development, as with the earlier waterfall method, using discount methods are a way to assist the UX person in their design work quickly and at more economical costs.

References

1. Nielsen, Jakob (2000). Why you only need to test with 5 users. Alertbox March 19, useit.com

2. Nielsen, Jakob (2006). Quantitative Studies: How many users to test? Alertbox June 26, useit.com

3. Hurst, Mark (2009). A lesson in strategy, taught by a Cat. Good Experience, September 24, goodexperience.com

4. Chisnell, Dana (2009). Testing in the Wild, Seizing Opportunity. In UIEtips, August 12, www.uie.com

5. Daniel Gruen; Thyra Rauch; Sarah Redpath; Stefan Reuettinger (2002). “The Use of Stories in User Experience Design” The International Journal of Human-Computer Interaction.