CX done well is User Research: A case against siloing.

“What if they’re force-quitting the app?” I said.

“No way, why would they do that? It’s a background app,” an engineer said.

“It explains the drop off, and is the only answer that fits all the information we have.”

“You really think they’r force-quitting it and expecting it to run at the same time?”

“I don’t think they know they’re doing it.” This was not a new discussion. Again, I was standing in a room full of engineers, trying to get to the bottom of The Bug That Wasn’t.

“There are fewer issues on iOS because the actions to force quit are clearer: you double-tap, and then swipe the app off the screen. On Android, you just hit the home button and swipe.”

I was faced with another room full of puzzled faces.

I was about three months into my job at rapidly growing mobile app startup MileIQ. We were less than 20 people, newly past our Series A funding. I was 23, four months out of university, but familiar enough with my role as one part of a two-person Customer Experience team to make decent judgment calls. MileIQ’s product is a mobile app that tracks mileage for those who need to report it on their taxes. It’s vitally important it capture all drives, and it’s generally very accurate. For a small subset of mostly Android users, it wasn’t.

Our CX team was set up to see most actions a user takes and events that occur on a user’s device. I could see them drop off, then re-appear a few minutes later as the app re-started as designed.

I didn’t yet know the term ‘user research.’ I began doing it because I needed to test a hypothesis, and help the gaggle of users that was emailing me every few days saying the app just quit and they didn’t know why.

I started to send out a response to impacted users asking them if they were tapping the right hand home button, and swiping it off the screen.

The answer was a resounding yes, from enough users to be statistically significant. Many users didn’t know that this force-quit the app. Many more didn’t know there were other options for moving from one app to another; the concept of background apps hadn’t ever been explained.

It shouldn’t have to be explained. This was a combination of UX failures with the Android platform, and our app.

The engineering team was incredulous when I presented my research findings. This seemed like such basic knowledge to them. I can’t fault them for that. They were some of the most brilliant, empathetic, and artful engineers I’ve had the privlege of working with. This is just an example of UX designers and engineers having very different worldviews and roles.

In response, we added better onboarding material and support articles, which almost completely resolved the issue.

At this point in my career I hadn’t heard the terms UX design and User Research, but in retrospect they became the core of the problems I faced and solutions I needed to support our userbase when things went awry. Very few of our issues were bugs. Many could be resolved with better research and design.

I left Customer Experience because I wanted to be on the problem solving side as well as the problem diagnosis side of software development, but my time in CX makes me a better UX designer. I will maintain close contact with the support team at any company I work with, and if that isn’t feasable I will strongly question why.

Though this instance is a very basic example of user research, I did something no one else had done at scale; I surveyed users who were having this issue, identified a problematic behavior, educated them, and then followed and tracked their progress. Some have argued that this was out of scope for a support team, but I disagree. In any user-focused company, the CX team’s job is s to effectively address any problem a user may face, or direct it to the person who can effectively help them.

Engineering teams and designers are not often the target users, and thus run afoul of their own assumptions and understanding of the world when designing and building. The members of the team most likely to understand the user’s needs best are those who address their problems directly every day. Know your support team well, and actively resepect their unique expertise. Teach them user research and UX skills so that everyone on the team shares a common language. It’ll help their career, and give you vital stepping stones toward a truly user-focused product.