Originally published: Oct 13, 2011
"I'm completely shocked at how much our customers actually love our product."
We were driving back from our fourth site visit in two days and that's what the designer in the passenger seat announced. We were each sharing our biggest surprises and he talked about how he's talked to so many angry customers, he naturally assumed they all were that way.
Sitting in his office, he often gets calls when things are really broken. He's the guy that tech support calls on to get them out of the big fixes. It's been that way for years. When he finally talks to the customer, they are pretty pissed (and often he doesn't have good news for them). His entire exposure to customers has been at the receiving end of this awful experience.
Until now. Suddenly, he's out with us in the field, visiting customers who really love the product. These customers kept telling us how it's changed their business and how they couldn't live without it. They love it. It was a complete shock to the designer.
That's not to say the customers didn't have problems or frustrations. They had a ton. And they'd spent time on the phone. In some cases, they were the angry customers that the designer had talked to. But, overall, they were really pleased.
This is one of the things I love about taking designers into the field to meet their customers: They see a completely different world than they are used to. And once they get over the shock of the differences, they start to see their designs in action and future possibilities.
Of all the work I do, field visits are the most fun. For the teams I take, they are incredibly invigorating and energizing. Teams that are beaten down and demoralized by the drudgery of day-to-day production are suddenly pumped up with an energy that they haven't experienced in years. Ideas and insights are flowing from every corner. It's everything I can do to keep them from running off and redesigning everything (which, frankly, might not be so bad).
Recently, I've been reflecting on why field visits are so much fun for me and the teams. Here's what I've come up with:
"Oh my God! That was SO interesting!" are frequently the first words I hear from a designer walking out of their first customer visit. They have that expression that a kid gets, having ridden their first roller-coaster ride. I almost expect "Again! Let's do that AGAIN!"
It almost doesn't matter what we watched the users do. (In a recent visit, we spent an hour watching a network manager redistribute the HTTP requests across a farm of 400 servers. It was riveting. Seriously.) When it's your design you've slaved over for months (or years) and people are really using it, it's likely the most fascinating thing you'll probably ever see.
Next comes the sudden realization of how frustrating the design is for the users. (It's true that not all designs are frustrating for all users, but if a team has never seen their own users before, the designs they produce are prone to be difficult to use.)
The first time a designer sees a user become frustrated, the knee-jerk reaction is to blame the user. "Oh, they just weren't trained properly." It doesn't take too long before that opinion evolves into the critical epiphany: "We're not making it easy on them. We're creating obstacles and hurdles that don't need to be there."
That's where I get to see one of the best designer qualities: empathy. When an entire team hits this point, it's awesome, because suddenly they're on the side of the user. Insights start to emerge. Brain cells are rubbing together in new ways and the neurons are firing rapidly.
This is especially true when you take those hard-to-convince stubborn team members out. Suddenly, they see that all the things they were convinced were facts are not as solid or true as they thought. The world is a messy place and their neat little this-is-the-way-it-has-gotta-be distortion field has been breached.
I particularly love it when little surprises grow into big ideas. Recently, we were talking with a small business owner about how she calculates her payroll for her 12 employees, something she does every week. As it turns out, for her, it's a 3-hour process. She dumps the hours worked into a spreadsheet, then she calculates commissions on products sold, then she pumps it into a word processing document, which she then sends to the payroll company. Somewhere in there she makes an anonymized poster to report to the employees who the top performers are.
The thing was, all that work could be done by a computer in about 3 minutes. But the shop owner spent 3 hours each week. Three hours multiplied by 52 weeks is 156 hours. She could get more than 3 weeks of her life back each year with a little automation. Wow! Talk about an opportunity! The team was all over it.
We regularly see stuff like this in our field visits. And each revelation comes with excitement and energy. It's really fun to be around teams when they do this for the first time.
Even though we do the standard stuff—take pictures of each person we visit and write up the key findings we see—the critical data lives in the heads of the team members. What the users did and said becomes embossed in their minds. They can use that information to make important design decisions going forward.
One of the first agenda items upon return to the mother ship is to capture the scenarios we observed. What did users try to do and why were they trying to do it? These turn out to be really powerful for making design decisions going forward. Summoning one of these scenarios in the design process, to compare against the ideas we have, helps us answer the question, "Are we making that user's life better?"
Once the scenarios are captured, we turn our attention to the patterns we saw. What kept happening across the different sites we visited? Some are obvious, but some take a little time to emerge.
For one team, it took us a bit of study to uncover that almost every large installation had a person assigned to the job of fixing other people's mistakes. These individuals, at least one at almost every site, did nothing but go through the application's data and correct typos, missing data items, and math errors. Not only could much of this work be detected and corrected by the software, there could be a slew of tools put in place to make this person's work much easier.
Often when the team discovers a new pattern, there's another burst of energy and excitement. It's as good a scientific discovery as a design team will ever have. I love seeing that happen.
Probably my favorite part is watching the team bond over this common activity. We've all been a part of corporate team-building workshops, where we do trust falls and build towers out of playing cards and egg shells. Taking a team on field visits makes those group workshops look like a teddy bear tea party.
Suddenly, the team has shared experiences that are directly related to the work they do daily. They can evoke their shared experience to solve important problems and make critical decisions.
Now there's discovered data to supplant the strongly-held-but-uninformed opinions that previously dominated discussions. We can take the scenarios we collected in the field and validate our ideas, at a level of detail and precision previously unseen.
This is especially true for teams that usually work remotely. Recently, I had the opportunity to work with teams who had never met until they showed up for the first visits. Upon returning to their remote offices, they had this common experience to bind them together. I could see the productivity and effectiveness increase before my very eyes.
If you're looking to energize your team and strengthen their bonds, then I recommend a simple prescription: take them out to visit your users. It'll be a blast, I assure you.
If you've always wanted to go on your own field visits, you'll want to get the best techniques from Steve Portigal, who is a master at these things. His User Interface 16 Conference full-day workshop will be a ton of fun. You'll go on your own site visit and analyze the results - an amazing education. Check out how much fun it'll be.
Read related articles: