Agile UX?

newsletter #25 | 20-Jun-2017

Last week I apparently caused a short Denial of Service attack on my own website when I asked listeners at the Agile UX Virtual Conference to look at the problem/solution diagram on my website. Once everyone was able to see it, I described how I see the difference between the mode of working where you’re trying to come up with ideas & designs for your organization support people (solution space) and the mode of working where you’re trying to understand people’s purposes and inner reasoning (problem space). I also described the two kinds of empathy that I find most helpful in UX (out of many types of empathy described in psychology literature), as well as what criticisms are out there, how sympathy and emotional empathy are different, and how problem space vocabulary is different than the solution space. And I called attention to the fact that most teams who want to use empathy are trying to apply it without developing it first.

Then I answered questions. Here are a few that I think are valuable to share.

Q: Do you have any advice when it comes to how to encourage Product Owners and other business entities who are still in the “business first” mentality? How do we get them to understand and view how important designing for real people is?

A: Leaders and entrepreneurs love the idea of understanding their “users,” but they are used to doing “user research” in one-day sprints. To spend weeks getting to know people and pulling together patterns from the data shocks them. So speed is one issue I run up against. Another is the universal trust in the “risk-free clarity” of numbers. Businesses have been successful in the past doing Six Sigma kinds of work to increase quality and reduce production costs. Finding out how people make decisions based on emotional reactions, inner thinking, and philosophies seems worthless because it can’t be converted to numbers.

The way I approach these two barriers, speed and risk-free numbers, is to separate the process of understanding people-as-people from the process of ideation, creation, and delivery. The latter is the cycle that has been the subject of attention for the last few decades. (Agile, lean, etc.) The former needs more attention. Today, the successes we see in software and service design are based on luck, really. It has been a developing market with lots of people thinking up their own “killer idea” and throwing it at the wall like pasta to see if it will stick. Customers use these offerings because there’s not a lot else to choose from. (For example: I use Mailchimp even through the experience is painful and time-consuming for me. I’m not who they designed for. But I don’t have a lot of choice.) The markets are maturing now, and it takes a LOT more than a “killer idea” to be successful. You need nuanced support for the real people you think will be using your offerings.

You can help the “business entities” feel more confident in their decisions and plans for the product. Help them get successful in this more nuanced market. Introduce them to the range of approaches to understanding people and the problem space. Prove to them that taking the time now is helping research the risk out of their product decisions because you’re giving them a solid foundation of understanding, a validated strategic roadmap of paths ahead, and a heap of opportunities to explore.

Q: Have you try to connect Mental Models with Agile User Story mapping? If so, how can you help Agile teams create better user stories?

A: In the solution space, in either the ideas or the design phase, use the behavioral audience segments to define a character and use a tower from the mental model diagram to select a context for the purpose, then select a situation for this character+context and write a story. Memorable stories have an arc. Don’t forget to include the struggle, crisis, climax, and resolution.

Q: Do you advocate for looping in the development team directly into user research activities? If so, how?

A: Anyone is welcome to participate in the problem space exploration at any time. The development team is made up of individuals. Some of them will be interested in the process of developing empathy through listening sessions, combing through the transcripts, and building patterns of the concepts therein. Others won’t be interested. Spend time getting to know each individual so you know when to loop them in. Some will be happy to be involved from the start or from the middle or … Everyone doesn’t have to get involved to the same degree.

Q: The empathetic mental models you’re talking about are really specific — how do you decide which cases to fully explore, or when to stop the exercise & start building?

A: You don’t need to do any problem space research if you aren’t trying to innovate as an organization, if you already know of several directions to take in the future, if your assumptions are no great risk, and if you already support specific thinking styles with different offerings. (I’m not being facetious; these situations do exist.:) When you don’t know any one of these things, then you choose to research an area based on:

• your organization’s history
• what your near-term goal or intent is
• a particular audience segment (thinking style) you want to support better
• because of prior problem space research that points out a gap in your knowledge

Be careful when choosing a scope for a particular study.* It’s a Goldilocks kind of problem-the study has to be just the right scope. If the scope is too big then you won’t find patterns; if the scope is too small then you won’t get information you don’t already know. Scoping is also difficult because people are accustomed to scoping “user” research in the solution space. A problem space study scope has to focus on the purpose a person has, having nothing at all to do with your organization, nor the tools a person might use. For a study within a team responsible for refrigerator design, you wouldn’t ask about storing food. You’d frame the study as understanding how people obtained ingredients and prepared for meals over the past two or three weeks. You’d need to narrow it to a particular approach to cooking so that you’re not looking for patterns between people who have little time for meals but obsess about certain things, people who love cooking, and people aren’t that attached to the concept of “meal,” for example.

Q: How often or when would you know when you need to revisit your mental models?

A: The answer to this is the same as the answer above, especially with respect to the fourth bullet point. You choose to go into problem space exploration when you need to explore an assumption, seek out new opportunities, adjust your product strategy, or understand a specific thinking style in order to support it more deeply.

Q: What is the time limit to stay in problem space before making a conclusion for solution space?

You’d stay in problem space exploration only long enough to get a solid feeling for the patterns. If you do this informally, it will take probably three weeks to figure out the scope, recruit participants, conduct listening sessions, and create a sketch of a mental model diagram in sticky note form. If you do this formally, for a 10 person study it will take 10 weeks, and you will have good initial behavioral audience segments and a solid mental model diagram that can be added to over time and where each item can be traced back to a transcript if future context is needed. (Times listed are dependent on smooth recruiting, etc.)

Q: What is the value, really, of a sales rep’s or product manager’s “street smarts”? They tend to make confident assertions, based on their direct experience. How do we validate what they say?

A: It depends on the sales rep or product manager. Do you know them and their thinking style well? Their “street smarts” could be based on extensive listening sessions with their potential customers. Or it could be bravado … or something much more complex and human. To know them is halfway to validating their knowledge. Spend time with them. Dig for details about the customers’ contexts that the rep would have trouble inventing. See if the rep volunteers discrepancies and similarities between customer thinking styles. Good sales reps are tuned in to customer nuances.

If you conclude that the knowledge is not based on the sales rep actually listening to people, then (carefully, respectful of their sense of self worth, and so you don’t set off political quakes) select a scope of study, recruit a particular set of people and conduct listening sessions. Once you have the transcripts, look for patterns. See if these match what the sales rep has asserted. If the patterns match, then you have validated the rep’s assertions. If the patterns don’t match, make sure your scope and participants represent what the sales rep was referring to. It might be a case of mistaken communication. If it’s all good, though, then you have invalided their assertions. It depends on the internal politics where you take it next.

Q: Is empathy a skill you can prove? A “skill” in the sense that makes you a valuable addition to a team, for example?

A: Hmm. There are many forms of empathy, but most of them result in the bearer being:

• open minded (reasonably comfortable with new ideas)
• happy to be convinced that other perspectives are valid (not terribly judgmental)
• mindful that assumptions are always lurking in their thinking

As far as making the bearer a valuable addition to a team, there are myriad ways of measuring each team member’s value. I don’t think empathy would trump another metric. But I guess if the power-players on a team were all close-minded, then the product and process decisions would all serve those individuals’ thinking styles and no one else’s, and that would certainly reduce the success of those products and processes. These decision-makers would be taking risks based on assumptions they were unaware of.

…

There were a couple of questions about using Myers-Briggs or Questions & Empathy for cataloging people. I do not use any of these cataloging tools. I’ve heard people refer to these tools as “astrology for businesses,” and I agree. Additionally, empathy maps can be mis-used if you are just making up the data. There are no shortcuts to getting to know a person … luckily getting to know a person is a lot more rewarding than you might imagine. Please see the next section of this newsletter for more about these kinds of cataloging tools.

* I encourage folks to do lots of small studies with 8–10 participants each, 3–10 weeks each, focused narrowly on a scope + audience segment. This way you can make incremental progress and put the results to use. Problem space research data never goes stale, so each iteration adds to the last and increases the breadth and depth of your perspective.