Setting the Stage

I work for FieldCentrix, which provides field service automation software on mobile devices. We have several industry solutions, including one for the building trades. This particular solution supports repair people who service heating, air conditioning, ventilation, and refrigeration. Our product allows them to use mobile devices to do tasks such as receiving a work order, tracking work, getting recommended repairs for a problem, updating parts inventory, and capturing the customer signature in the field so invoicing can immediately start. The full solution is actually five applications, with a total of about 150 screens. The solution has been in commercial use for over four years, running on handheld PCs (HPCs). Our application replaces all paper associated with the remote user; they no longer need any paper forms, and they rarely need to return to the office.

In response to market demand, we needed to start running on the Pocket PC (PPCs), not surprising since HPCs cost around $2500, PPCs are under $500. We had three months to get to the beta, and two months after that for the commercial release. That would challenging enough, but the added design challenge was that we were going from the handheld PC’s 1/2 VGA display to the Pocket PC’s 320×240 display. That’s 50% less screen real estate, and as you might imagine the impact on usability was a concern. As you’ll read below, we actually improved the usability in the new, smaller interface—in some cases it was significantly improved.

First things first: analyzing the existing application

The team working on the specification for the PPC version consisted of two marketing product managers and a technical communications writer. One of the product managers had been trained on Contextual Design (CD), but none had experience actually using it. I served as their CD mentor, coming in and out as the project required to show them how to use a technique. We started by doing a reverse User Environment Design (UED) of the existing applications. (Editor’s note: To learn more about User Environment Designs see Using a Floor Plan as a Metaphor for Design).

We did find some problems in the reverse UED, so we identified those as clear opportunities for improvement in the new solution. We’d previously spent a lot of time collecting our users’ workflows, so we walked the workflows through the reverse UED. This isn’t the same as collecting field data with Contextual Inquiry customer interviews, but it was a tradeoff we decided to make. The reverse UED and workflow walkthrough also let reconfirm which focus areas and screens should be together in the applications.

The Reverse UED

Refactoring the screens leads to better usability

Our next step was to refactor the screens to work in the smaller 320×240 display. Here’s where our reverse UED analysis started to pay off right away. In several cases were able to reduce both the number of screens and the number of clicks. For example, the screen for opening a work order went from three screens to one; the number of clicks was reduced from 10 to four. The time to open a workorder had been one of the pain points with our users — it’s very hard to compete with the speed of paper. We combined some screens (using the workflows to identify functionality that belonged together) to get a better UI experience. Due to the slow processors in handheld devices, removing screens and reducing clicks was very important. Unexpectedly, we were getting better usability in the smaller display.

Walking (literally) the new design

We then turned the newly designed screens into a paper prototype, which we tacked up on a wall. At this point we had a shared User Environment Design for both the handheld PC and Pocket PC versions. Many of the focus areas were the same, so we just marked which ones existed on one platform but not the other. We tacked the UED diagrams up high on the wall, and tacked the paper prototypes of the Pocket PC version underneath them.

The Design on the Wall

We then took our user scenarios (the equivalent of use cases) and walked them through the new UI. As expected, this led to some revisions of the UED and the paper prototypes. Working in paper let the team literally stand in front of the application and walk the cases through it. When the team works like this, communication is enhanced since everyone can see what is happening. If we tried to do this with an online prototype it would not have had the same effect. The turnaround time on changes would have been much slower, and we would not have been able to collaborate. This step revealed low-level fixes to the UI that we normally don’t find until much later. After completing these steps, we brought in some FieldCentrix employees with more experience in field service and had them walk through the UED and paper prototype. They also found some problems that we were able to fix.

Reviewing the design with customers before beta

Once we had our design, we needed to get customer feedback. We didn’t have the budget for travel, so our only in-person paper prototype interview was with one local customer. The rest of the customer feedback came from online meetings using WebEx, where we had both end users and their managers review the screens. We included the managers since they had been field users before, and were sometimes called in to do actual work. We also needed management buy-in on the platform.

Demonstrating progress, getting internal buy in, and leveraging the design room into a sales tool

At the same time we were reviewing the design with customers, our sales force coincidentally came into town for a sales meeting. We brought them into the design room to see the re-designed screens posted on the wall and walked them through the design with user scenarios. In a word, the sales force was thrilled. They had been pushing hard for the Pocket PC version because some sales were contingent on delivering on this platform. We were able to show them the progress we were making and that we would be able to hit the date, so of course that was important. Just as important, by walking them through the design with user scenarios, we could focus the conversation on how the design would support what customers really do, not imaginary “what if” stories that weren’t grounded in actual customer work or needs. The Sales organization now used the design room to show new sales representatives and prospective customers how we use customer-centered design to create products that truly meet customer need. (Editor’s note: For other ideas about how to get communicate out and use your design and design room as internal and external sales room, see The Hidden Value of Contextual Design and Are You Hiding Your Project Behind Closed Doors.)

Passing the big test: a very successful product release

When the Pocket PC version launched, the market feedback was overwhelmingly positive. For example, after one week one client wanted to replace all of their handheld PCs with Pocket PCs. And, so far we’ve only had to make one minor UI change. Our Pocket PC version has been released for about six months. We’ve had some enhancement requests, but for nothing critical. We were able to use Contextual Design to focus our design and development effort on key areas and get the release out on time. Happy developers, happy sales people, and happy customers — it’s been a real success story for us.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]