I’m in the middle of reading Switch: How to Change When Change is Hard (highly recommend) is Hard by Chip and Dan Heath. It’s a really great read about behavior change. A key piece to behavior change as Chip and Dan describe is addressing the two parts of our brain, the Elephant and Rider.
Think of the Elephant as the emotional part of our brain. It’s often look for the quick payoff. The Elephant is impulsive. It’s the part of our brain that rationalizes hitting the snooze button or binge eating ice cream at night.
The Rider is the rationale side of the brain. It’s capable of looking at the pros and cons and sacrificing short-term gratification for long-term gain. The Rider excels at planning beyond the moment. Where as the Elephant is impulsive, the Rider is deliberate.
Compared to our impulsive Elephant, the Rider is relatively small. That’s the problem. In a pinch, when we’re exhausted and driving home from work after a long day, the Elephant can easily overpower the Rider forcing us to drive right past the gym and into the drive-thru at McDonald’s.
What in the world does this have to do with developers and end-users?
Throughout the book, the authors have placed little clinics, essentially practice thought exercises that let you apply the material to real-world scenarios. One of those clinics, in particular, caught my eye as it posted this exact question: How can you make developers care about the end-user?
(Tangent: This question implies that developers don’t care about the end-user, which isn’t true. I think the question could be better phrased as “How can we better pass along feedback from users to developers?”)
The authors go on to describe a situation I’ve found myself in before. Developers work very hard to launch new products and features. A seemingly simple development to the end-user could require months of work and planning on the back-end.
When developers pour in tons of energy and enthusiasm into a project, they become a bit attached. You can likely relate from personal experience as well right? Think back to the last time you really poured yourself into something, gave it all you had. You were probably ecstatic to get it out into the world and show someone.
Now, imagine that someone you showed your precious project to just didn’t get it. Maybe they didn’t like it or even acknowledge how hard you must have worked for this all to come together. You would feel a bit hurt right? Rather than listen to this person’s feedback, you might get a bit defensive. Now you know how developers feel when they launch a big project.
Developers do care about the end-user. However, they’ve invested a ton of time into the project and have a good idea about how things should work. When support pros interact with users and hear critical feedback, there’s a natural tension. Developers receive a ton of feedback about why the feature isn’t working or what’s broken. Just like the last time you felt really invested in a project though, negative feedback can be hard to stomach.
How can support pros communicate that feedback in a way that’s actionable and easily digestible for their development teams? Here are some points Chip and Dan lay out in Switch.
Direct the Rider
The Rider in this scenario is the rationale, long-term thinker. Riders respond to analytics, actionable steps, etc.
Point to the destination.
We should paint a picture of the group glory that will result from a successful product launch…Listening carefully to the customer is simply a way to accelerate that glory.
Keeping the goal in mind (happy users) is always helpful. It might be a bit painful, but getting there is what matters.
Script the critical moves.
Imagine that we tell them [developers] that their program’s “ease of use” is rated as “poor.” What in the world can they do with that?
Nothing.
The critical moves for success need to be actionable. Even surfacing something a simple as “We get lots of questions about XYZ” isn’t helpful. What about XYZ is difficult?
Take the extra time to compile a detailed report. Collect direct quotes from users compiled from support interactions. Film users using the exact feature. Organize and prioritize a list of bugs. The next steps have to be very clear.
Motivate the Elephant
Remember, the Elephant is the often-impulsive, feelings-based part of our brain.
Find the feeling.
The Elephant runs on emotion so in order for us to motivate the elephant, we need to tap into that emotional side. Developers (and everyone in the organization) needs to feel the issue.
Dan and Chip give one example of accomplishing this using a one-way mirror with a user test on one side and a developer on the other. That could probably work, but it sounds rather complicated.
Instead, I would recommend having everyone in your organization help out in support every week. It’s a simple way for developers to see recurring issues that pop up. If possible, have them work in support directly after a big launch to see what issues come up right off the bat.
Grow your people.
The authors mention that part of the issue is how critical customer feedback reflects on the developer. If you spend a few months building out this new feature and users hate it, does that mean you’re a terrible developer? No, of course not.
We should stress that the test of a great developer isn’t the quality of his or her first-draft code; it’s how well the developer codes around the inevitable roadblocks. (p. 112)
Create a culture where solving issues and fixing bugs is appreciated. Push development teams to write post-mortems after launch about what could go better next time around. Circling back to the point above about destination, the end goal is happy users. The goal is to get there; rough first drafts are to be expected.
Shape the Path
The last part of the change process covered in Switch is called shaping the path, basically setting up the environment for the behavioral change to be successful.
What looks like a people problem is often a situation problem. (p. 18)
They use the example of movie popcorn buckets. Simply shrinking popcorn buckets in the theatre has been shown to decrease popcorn consumption. You’re changing the environment to increase the likelihood of success.
Build habits.
To avoid running into this issue of developers launch -> customers give a big dose of critical feedback, you can build habits throughout your organization that strive to surface feedback earlier in the development process. Get developers feedback about the new product or feature when the feedback is actionable and before everything is 99% finished.
Here are a few suggestions based on how we work at Automattic that you might implement.
Setup a public testing environment. We recently created Horizon Feedback, which is a testing environment open to the public. Developers can post about a new feature and ask for feedback directly from our users to address critical issues early on.
Setup clear testing instructions for new features. Our development teams have improved tremendously with their calls for testing. Every new feature has an internal post stating what’s changing, how you can test, and what you should expect to see as the end-user. From a support perspective, it’s incredibly helpful to have these instructions and increases the likelihood that support will dig in and take the new feature for a spin.
Tweak the environment.
If you’re developing something on a brand new Mac with the latest version of Chrome with most of your user-base running Windows 8 with an archaic version of Internet Explorer, you’re going to run into issues. Your users aren’t exactly like you. Even something as simple as developing on Mac with a Windows user-base can make a big difference.
Setting aside time to work on the connection speed or operating system that your users work with is important for developing empathy. (Sidenote: I’ve heard Design for Real Life is a good book on this subject, but I haven’t read it yet.)