My focus is on making software, coaching Agile/Scrum teams, and being a husband and father--definitely not on blogging--so please do not expect very frequent posts here.

Wednesday, January 16, 2013

Artifacts that can improve UX

Yesterday at work, we gathered in a conference room to hear from Jay Mathews of Straight Line Media on user experience and software design. 
How can any of us understand a design from a list of requirements or even user stories? How can we hope to communicate with product owners and stakeholders what we propose to build? Mathews suggested these artifacts:
  • Low-fidelity sketches (6-8 hours for many) of a proposed GUI are typically created with a whiteboard and can quickly generate and communicate ideas and discussions to try to find a working approach. Drawing out several sketches can allow us to combine vastly different GUI approaches to come up with a better visual design than we can fathom via requirements alone.
  • A vision document (2-8 hours) answers the question “what are we building” at a high level. Perhaps it is just an overall definition of the system, four meaningful paragraphs of detail, and/or a visualization of the system we intend to build.
  • An experience map (10-15 hours) can describe the end-to-end experience for users
  • I discussed personas in earlier blog posts – formalizing our personas help us understand about our users and get on the same page.  It helps get us out of our own experience and bias and reveal what we don’t know about
  • Much like a user story map slice or customer journey, a scenario a set of interactions that a persona would interact with the software system.  Scenarios are story-driven, told in human terms, focus on what the user can accomplish with a yet-undeveloped system.  The user’s outcome, overall experience, and emotions are the focus here—not merely what they can do with the system.
  • A conceptual architecture diagram (15-20 hours) answers “how is the overall system going to work". It overviews both the concepts and the core structure of the proposed system.
  • Detailed site architecture diagram – depicts all unique pages/screens of an application and where each lives in the application’s hierarchy.
  • A user flow diagram details the path a user follows to complete a specific task.
  • Wireframes (3-6 hours each) communicate fundamental details about the functionality, content, navigation, and interactivity of a screen or a page. This sometimes is the final deliverable of a design.
  • Prototypes (8-20 hours) help us to visualize a specific interaction with actually functioning software.
(Mathews mentioned that Agile “user stories” are “more like requirements” and thus differ from scenarios. I’d argue that the distinction between requirements and user stories is very important; indeed, both are different from scenarios.)
I believe that the best software results when we value working software over comprehensive documentation. That doesn’t mean we dismiss creating these artifacts, as some misunderstand Agile to demand. Instead, we create just enough of these artifacts as needed to create good software, and no more. We must constantly be examining ourselves to see if more documents would be useful. These documents can be highly polished or quick-and-dirty, whatever is appropriate for your purpose.
Mathews also encouraged us to do usability testing, and I completely agree. He said, “Small improvements can yield big results.” Testing with even just a few users can reveal flaws that are crucially important to fix. He recommended a formal session with a trained facilitator, but any usability testing is better than none. I’ve seen numerous ways of doing real user testing; one promising service is YouEye, where you can in mere minutes get a usability test going for any public web site.
To Mathews, UX expertise is nothing but the intersection of empathy, analysis, and intuition about our users.  We must visualize our projects—the visualizations don’t have to look pretty, but they do have to communicate what we are going to build.
Mathews recommended Goodwin’s Designing for the Digital Age for more on these topics.

Monday, January 14, 2013

Customer Empathy

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?

imageSecondly, 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 order

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!