Even though a task seems “rote” or “straightforward” from afar, the reality on the ground may be quite different. At a large Fortune 500 company with a national presence, service centers are spread across the country. Further, these service centers are far removed from the office buildings where users may be designing and building the tools that users need to use every day to their jobs.
My role was to research how these service center staff were using the suite of tools the company created to support them. Plenty of quantitative data was available. Using that to help generate hypotheses, I created some studies and went out into the field to observe and interview service staff— and then to bring those findings back to the rest of the product team.
The most insightful observations came out of some contextual studies. I saw that the service center staff, using the software to perform the same tasks and collecting the same data, each did it a completely different way. Newer staff would look to senior staff for advice on how to setup their systems for success. Once on the ground performing the work, staff would develop their own highly personalized and sometimes eccentric ways to get the job done.Between training and mastery, a user would bend the software to their mental models. It was clear that a rigid software approach wasn’t going to get the job done.
The challenge of contextual— bringing the findings back to the team…
To bring this insight to the rest of the team, I created and executed a sketch study to help teams better see what I was observing.
In a separate room away from their desks, I interviewed staff about their day-to-day work and how they felt about the work they did. I then asked them to sketch how they setup.
I collected, aggregated, and presented the results of this study to the rest of the team back at the corporate office.