Table of Contents
This is a case study for use in a class like Software Design (see session 8 for this case’s reference in that class).
A Season of Change & Disruption
“HVAC in a Hurry” (HinH) is now itself in a hurry. After decades of happy existence as a prosperous regional supplier of heating & air conditioning services, its industry is consolidating. The CEO, Mary Condor, feels they need to either scale, combine with another firm, or gradually be out-competed into insolvency. Scaling is her first choice.
She’s brought in Frangelico DeWitt to lead a change management and digital transformation program. His charter was to take the best of what HinH has learned and to use it to improve existing operations and facilitate rapid expansion into new regions (possibly through a franchising model). While resources are scarcer than he would like, DeWitt feels up to the challenge (with a first name like Frangelico, you have to be resilient).
Solving the Right Problem
After exploring various roles/personas and tasks/problem-scenarios, it looked to DeWitt like the most valuable early wins were probably in and around the interface between dispatch and the HVAC field technicians. Specifically, how the company might create more of a self-service environment for the technicians.
Based on some customer discovery with the field technicians, he decided to focus on this particular problem scenario:
Getting replacement parts to a job site.
Currently, the jobs of identifying a part, determining its pricing & availability, getting agreement on ordering it from the customer, and planning next steps were cumbersome. Frangelico and his team were currently focused on this epic user story:
‘As Ted the HVAC technician, I want to identify a part that needs replacing so I can decide my next steps.’
Based on their observations in the field, Frangelico’s team thought through the user experience of the epic with the following storyboard: 
From the storyboard, they detailed out the following child stories:
User Story |
Test Cases |
| ‘I know the part number and I want to find it on the system so I can figure out next steps on the repair.’ | Make sure it’s possible to search by part number. Make sure descriptive info. appears as the search narrows (photo?) to help avoid error. |
| ‘I don’t know the part number and I want to try to identify it online so I can move the job forward.’ | Make sure it’s possible to search by make/model of units Make sure it’s possible to search by type |
| ‘I don’t know the part number and I can’t determine it and I want help so I can move the job forward.’ | Make sure an estimate of the turnaround time for an expert to review is available |
| ‘I want to see the cost of the part and time to receive it so I decide on next steps and get agreement from the customer.’ | Make sure it’s possible to dispatch a request by email to the customer in case they order their own parts and/or carry their own inventory of spares. NOTE: How would the customer respond so we can help structure the next steps as we would otherwise? |
| Make sure it’s possible to indicate priority Make sure cost associated with priority delivery are available |
|
| ‘I want to order the part so that we can move forward with the repair.’ |
Getting Useful Software out the Door Quickly
HinH’s existing enterprise platform offered services & machine interfaces (API’s) where could access pricing and availability of replacement parts. The team’s job now was to get a responsive (mobile-friendly) web application out the door quickly to see if it would move the needle with the field technicians.
DeWitt and his team had access to a contract visual designer to clean up their work, but unfortunately, they did not have anyone with formal user interface training. Luckily, DeWitt knew a little about best practices in this domain. What he wanted the team to do was to find applicable patterns and comparables so they did not re-invent the wheel. Following this activity, they planned to start wireframing and prototyping alternatives. After that, they would begin user testing with the prototypes.
As he thought about these activities, DeWitt wondered how his team should categorize the different types of tasks in current user stories in general user interface patterns (text-based search, saving a list, etc.). What do you think?
What types of interface elements might a user be expecting to accomplish a task, like, say, searching for a part?
What existing user interface pattern examples (from whatever site/application) might be applicable to that functional space?
