Over the last five years or so, there has been a shift in the practices and attitudes of the software development community to be more user-centric. [Good blogging means avoiding big long text-only posts, so I will attempt to illustrate this with some really janky SmartArt below.] We used to invest a great deal of time trying to figure out how our software should work to benefit the business. The presumption was that we have a pretty good idea of what will work--the real challenge was designing software that can be developed, tested, and deployed efficiently. Let's call this feature-driven software planning.
The flaw in this approach is that the user was a afterthought. Release after release happened without anything but the most ad-hoc, reactionary user input. So we thought we'd bring the user's point of view into planning, and things got better. We realized that if we start with the user in mind, and did our best to avoid focusing on systems, features, or capabilities, we end up doing the more important work and avoiding lots of unneeded work we otherwise would have attempted. Our definition of “user” expanded to include everyone who uses our software, even indirectly. Let's call this software planning. (There’s lots out on the web on the benefits of user stories; also, see Cohn’s User Stories Applied.)
Things got much better, but we still relied on our own ideas and biases to form our concept of what the user wants. It helped to gather feedback and survey data about our users, but we soon found out that just implementing what the user says they want leads to strange features and unbalanced software. We shifted to thinking more about what the user truly needs—what they are trying to get done.
The key to better planning, then, is not user feedback or user input, but getting better at user empathy. We have to put ourselves in the user’s shoes. We need to listen and observe our users, and get really good ideas from what they do, not simply what they say (or yell). We need to combine insights from user empathy with our own vision of the software as a whole, always allowing the user’s needs to override, tweak, or confirm our vision.
David Hussman, at the Code Freeze 2013 conference, spoke on user empathy. Hussman outlined a few techniques and attitudes we can use to get better at having user empathy. The assumption is that better user empathy will lead to more business value, because meeting the users’ true needs will lead them to value your product and use it (and your other products) more.
First, let’s stop asking ourselves, “What can I make for my users?” and instead ask “Where can I take my users?” No software product is an end in itself—they all take the user closer to something: to making money, to saving money, to a entertaining experience, or to buying a valuable product.
One way I try to do this is by avoiding business-speak in planning, and trying to shift the dialog into the user’s terms. I’d rather not talk about what the marketing department has named “engagement actions”, but instead “helping the user enjoy the browsing experience” or “helping the user learn and enjoy the food-preparation process”. In the end, the functionality resulting may be similar with both attitudes, but more often then not, the latter attitude yields software with better usefulness and fewer unimportant, unused, or underused features.
As a more specific example for a food site, rather than providing a better web component to display a recipe with higher usability, I’d rather ensure the user can view a recipe in ways that help them to cook it, get ideas from it, and share it. I’d try to avoid discussion the feature of displaying a recipe before I start to think of where I want to take the user who happens to be using this feature. Where else could the user go?
Secondly, we need to inject some humility into our software planning. I don’t know our users, and neither do you know yours.One effective and inexpensive way to do this is with real user testing over the web. Another way to refine what you already know is with user personas, which can be brainstormed in just an hour or so to help guide your planning process. While personas do make explicit what you already know about a user, they also reveal what you don’t know sooner.
If someone calls me arrogant, I get defensive and argumentative. Let us define arrogance as the difference between what we think we know and what we actually know—if we do, it is easy to acknowledge that we all have some arrogance, right? We must make the assumption that “I am by nature arrogant about my users” part of our attitude in software planning.
Thirdly, our very thinking needs to be story-based. There are two sides to this—first, we need to be thinking in “User Stories”, rather than features, as mentioned earlier. Once we’ve started to do that, however, we also need to be thinking of actual user stories in the proper sense of the English words—a short narrative about what a user does or did, and what happened as a result. These stories are probably best told orally, with a beginning, a middle, and an end. They might have plot, characters, dialog, and a theme. In other words, we can learn more about our users from a informal story about them and their experience, rather than starting with formalized user stories. Hussman recommended finding the best storyteller that interacts with the users. Some people are naturally gifted at storytelling. Sometimes, this person is marginally technical—even better. Have that person start telling the story, and pause to write out actual formal user stories from which you can start to develop software—remembering that a formal user story is just the beginning of a conversation that leads to working software).
Too often, teams write user stories as just gussied-up requirements (“As a user, I want the system to…”), which totally misses the point. Starting with a real storyteller can help us to avoid this feature-itis. Other times, we form well-written stories from the user’s point of view, but we didn’t spend enough effort to consider what’s truly important for the user—we only converted our feature requests into good “user” stories, without actually caring about the user. Using these techniques and many others, I hope we can increase our user empathy in ways that drastically change our planning meetings and lead to better, truly user-centric stories and software.
These stories can be created by and/or visualized in a story map, where the stories are layed out in the order the user experiences them and with relative importance/depth. Now think back to the original question, “Where can I take my users?” Find the most important or valuable paths through the story map. Hussman called this a slice or customer journey. Identifying the user journeys (several stories that together make a valuable accomplishment) can help you figure out what the priorities and releases should be in a user-centric way. [Hussman and his company, DevJam, are working on a yet-unreleased web tool called CardBoard to enable this mapping on the web.]
So, how’s the customer/user empathy on your project? Let’s make it better!