Post

Using Mental Models for Troubleshooting

5 comments

When a user reports an issue they’re having with the product you support, how do you know what to do next? How do you identify the source of the issue? How do you know where to start investigating?

I’ve mulled over these questions countless times as I tried to explain to coworkers how I troubleshoot. When someone describes an issue, it always seems like the possible causes just pop into my head, unbidden. But of course that isn’t it at all — I have gotten better at troubleshooting our products over time, and that didn’t happen by chance.

When I read Jim Grey’s post How to Hire an Entry-Level Tester, his key traits for testers meshed with how I understand troubleshooting and this trait stood out:

Create mental models:  Building a mental model of a system, even if it’s incomplete or partially inaccurate, helps a tester orient themselves to a problem and generate ideas on how to work through it.

When I look at a problem, I fit it into my mental model of the product and use that model to start investigating. On my team, I’ve started to explicitly discuss mental models, how to build and expand them, and how to use them to get better at supporting and troubleshooting our products. Rather than trying to summarize the things we’ve talked about on my team, I’ll share the introduction to mental models I wrote recently, as part of a troubleshooting training I’m developing for WordPress.com support.


Mental Models

mental model is “an explanation of someone’s thought process about how something works in the real world” (Wikipedia). In other words, a mental model is how you understand or represent a real thing in a more simplified or abstract way.

Mental Model of a Bicycle

To get a better sense of mental models, let’s look at an example: Bicycles. Not everyone understands every part of a bicycle, but even if you just ride a bicycle now and then you probably have a concept of what it is and — at least to some extent — how it works. That is your mental model.

A user’s mental model

As a bicycle user, your mental model might be very simple — all you need to know are the parts you interact with or a general sense of what makes a bicycle different from, say, a tricycle or a car. In this simple mental model, you’ll see that the bicycle includes a frame, handlebars, a seat, and two wheels:

bicycle-simple

Post

Building a career in support

We need to build our support teams to add value across the company. We’re all expert communicators. We know not just the ins-and-outs of our product but how to convey our expertise in a way that’s relatable to our customers. That’s an immensely valuable skill. Our next step must be communicating back to the company what we learn from customers and from each other.

It’s that next step where we all too often come up short in support. We’re great at communicating with customers but, at times, terrible communicating internally to other teams at our companies. How many times do you hear about a development team not being on the same page with support? Or a sales team that makes promises to customers which support knows they can’t do? Those are real problems. And while they’re hard problems they’re solved with clear, consistent communication across teams. That’s our specialty!

Andrew Spittle — Building a career in support

Post

Report a Bug — Start a Conversation

Today at Automattic, I gave a presentation called Life Cycle of a Bug Report. Ostensibly, it was about the elements of an effective bug report and what happens to a bug report after it is opened. Ultimately, though, it was about how Happiness Engineers fit in to the rest of Automattic (or, more generally, how a support team fits in to the rest of a company), and how reporting bugs and other feedback can lead to better communication between support and product teams.

Here’s how customer support can sometimes look:

Dev-User-HE-Brokenloop.png

  1. The product team launches a product to the users.
  2. The users use the product, and when they have questions they reach out for support.
  3. Folks in support help users solve their immediate problems.

Ideally, however, there is a complete feedback loop:

Dev-User-HE-Loop.png

  1. The product team launches a product to the users.
  2. The users use the product, and when they have questions they reach out for support.
  3. Folks in support help users solve their immediate problems and communicate bugs, pain points, and other feedback to the product team.

In that complete loop, the people who spend the most time talking with users can advocate for those users and help set priorities for addressing pain points. Support folks also get an opportunity to connect more with the people who spend the most time creating and improving the product, to better understand existing priorities and resources.

When I write a bug report, I’m not just dumping a problem on someone else’s lap or giving someone a hard time for the product they created. I am pointing out a source of pain for the product’s users and starting a conversation about how to address it, in the context of everything else a product team is working on. In the process, I develop stronger relationships with our product teams and, as a result, can provide better, more informed support to our users.

Post

Embracing Openness

An exciting part of working at Automattic is the open source philosophy. It’s thrilling to help open source projects like Calypso (the new WordPress.com), even in a small way. I spent a chunk of time last year reviewing open bug reports, enhancement requests, and the like before the project was open sourced — it’s fun to see (and help with) new issues that come up as more people work with, get inspired by, and contribute to Calypso.

Open source isn’t just about developers, either — I do a lot of my day-to-day work in the open. I used to mainly provide support out in the open, helping users in the WordPress.com forums. These days I spend most of my time in the WordPress app repos, reporting and testing issues in the open there. (If you’d like to get involved, I also started posting calls for testing the WordPress apps over at Make WordPress Mobile.)

In the spirit of open testing, Automattic also recently released the WordPress.com Automated end-to-end tests into the open. I’m so glad we can share the awesome work that our QA and testing folks are doing. I’d also highly recommend checking out my coworker Alister’s blog WatirMelon for more testing talk.

Openness can really be part of everyone’s work — from open source, to open testing, and open support. Being open helps us learn from each other, inspire each other, and keep us aware of and oriented toward the wider community in which we work.