The Problem with Problems

“The Ultimate Answer to Life, The Universe and Everything is…42!”
― Deep Thought, in Hitchhiker’s Guide to the Galaxy by Douglas Adams

As human beings, we like solutions. Solutions are fun – they feel like accomplishments. They are neat and tidy. They make us feel smart. Unfortunately, problems are just the opposite.  They feel unfinished. They’re messy and complicated.  They make us feel dumb. As a result, we often find ourselves running straight towards “the answer” without taking a moment to consider what the question was.

Creating a solution without first defining problem leads to a great deal of rework and failed projects. And yet we still do it. In large part because we don’t know how to go about defining problems.

Defining Problems

So how do we approach problem definition?  At it’s simplest, a problem lies in the difference between the CURRENT state of a system and the DESIRED state of a system. The details of that difference may manifest in things like:

  • Frustrations
  • Inefficiencies
  • Overlaps
  • Low-skill, high-frequency tasks

But how do we uncover these things? And once we uncover them, how do we define them?  To create good problems, you can follow these simple steps:

  1. Research
  2. Analysis
  3. Definition


It may be tempting to assume we “know” them based on our own experiences, but personal experience is anecdotal at best and not a substitute for real observations. To find out what problems might exist in the space you are exploring you must do (cue ominous music) RESEARCH. Through interviews and observations you must gather data, on what your user is experiencing.

Some tips for interviews:

  • Assume nothing! The key to a good interview is OPEN – open-ended question, open minds.
  • Do not start to formulate a solution or hypothesis.
  • Be friendly-neutral. You are gathering information, not giving it. Do not talk about yourself or your product.
  • Dig. Be prepared to ask why (or a form of it) five times. “Tell me more about that” and “Help me understand why that…” are both good phrases to use.
    • What is happening that is not ideal?
    • When is it happening?
    • Where is it happening?
    • Who is involved?
    • What do you think causes this to happen?
    • What does “ideal” look like?
  • “That’s interesting” makes your subjects feel like rock stars. Everyone loves to be listened to.
  • Include observations of their emotional reactions in your notes along with their words. Were they frustrated, laughing, sad, apathetic, angry?
  • Use at least 2 people – 1 to take notes, and 1 to run the interview.


Once you have your data, it’s time to examine it. By breaking it apart, you can start to look for patterns and commonalities.  Remember, even though we are looking for patterns, do not start to formulate a solution or hypothesis. Trying to leap to a solution before you’ve analyzed the data will cause you to ignore or overlook items in the data. Things to identify during analysis include:

  • Context -When/where/under what circumstances does the action happen? It is outside or inside or both? Do the participants walk or run during this activity? Do they sit? Is their environment noisy or quiet? Are they trying to do other things at the same time? Is this activity confined to a short period of time – if so what triggers it?
  • Motivations/interests -Why do people do this activity? What leads them to it and what benefit do they gain from it?
  • Definition of success -In a perfect world, how long does this activity take? What things should come out of this activity (what results)? How accurate should it be?
  • Severity -For the pain points within the activity, how bad are they? Is this a stubbed toe or a broken bone? Are we losing hundreds of dollars in contracts in a million dollar business or tens of thousands of dollars in a million dollar business?
  • Impact -What impact does this pain have on the business? How about on the efficiency and effectiveness of the user? What does that translate into in business terms? Are we losing conversions, revenue, time, etc?
  • Variables -What changes or can be changed? What do we need to account for that might not hold steady from day to day? How much do they change?
  • Constants -What can we count on to remain constant and steady?


Finally, it’s time to create your problem story.  Remember this is still not a solution! Take the items you’ve identified during your analysis and use this template:

When CONTEXT, ACTOR wants/needs to ACTION for RESULT but they are prevented by BARRIER which causes IMPACT that SEVERITY. CONSTANTS remain steady. However, VARIABLES changes DELTA.

Here’s an example:

When on the high seas, Bluebeard wants to attack ships filled with gold doubloons, but is prevented by poor visibility into the cargo holds of target ships which causes him to attack less desirable ships leading to wasting 20% of his overall attack capability on ships with plastic children’s toys. The number of doubloon carrying ships and Bluebeard’s capacity for successful attacks remains steady. However, toy carrying ships increase to 75% of total mercantile shipping during November and December.

Notice, we still haven’t come up with a solution yet. However, we’ve identified and quantified the problem sufficiently when we create a solution, we should immediately be able to see whether it will be successful and how we can measure that success.

Problem definition is key in reducing time and costs, and is the critical first step to effective product development. Without problems, we end up creating solutions in search of a problem. And that’s a problem.


Excerpt from the Epilogue

Integrating design work in agile can be done in a number of ways. Lean UX, Agile UX[1], and Design Sprints[2] all approach the problem differently with varying levels of success. The approached used in this book is a Design-Infused approach.

The following process outlines the expected activities and deliverables at each stage of a design-infused agile process.

Discovery and Planning

During discovery and planning, the team explores the market opportunities and pain points of their end users. Research and analysis happens during this phase, gathering sufficient information to ensure that things go smoothly once development begins. The idea funnel starts very wide at this stage, and mistakes are cheap to correct. Sufficient time must be spent in this phase to avoid expensive mistakes and badly timed or targeted releases. Investing in this phase ensures quality and efficiency. This phase can be broken down into the following stages:

  • Discovery and Ideation
  • Product Solution Definition
  • Business Opportunity Assessment
  • Vision and Validation
  • Scope and Acceptance

Discovery and Ideation

During this stage, product management investigates the current business landscape, assessing the potential opportunities and risks in the market place, interviewing customers, and understanding the competitors. The output of this investigation is business cases, also known as problem definitions.

Product Solution Definition

Business cases provide the perspective of the market and the customer. Product solutions should solve the problems stated in the business cases, but should take the perspective of the user – frequently a different person from the customer with different motivations in enterprise software. To create effective product solutions, product designers, working closely with technical leads and product manager, should own the solution definition, ensuring that it is technically feasible and will solve for the stated business problem.

Business Opportunity Assessment

Once the product and business research has been completed, product management, design, and development can collaboratively evaluate the opportunities and provide significant detail to enable an accurate scoring of the business opportunities available.

Vision and Validation

During this stage, the detailed design directions are solidified and vetted. Primary workflows and architecture should be defined, technical approaches solidified, and success criteria determined at the epic level, as well as potential measurement opportunities. Approaches are play-tested with customers[3], and effort estimations are done at the Epic level.

Scope and Acceptance

During this stage, detailed stories are written, estimated, and groomed for the backlog. The backlog is prioritized, acceptance criteria are finalized, and release dates are determined. Potential dependencies and risks are identified. It is important to note that stories are created for ALL team members – design and development.

For a design-infused agile sprint cycle, design and development work together in two types of sprints: Foundational and Functional.

  • Foundational sprints create items necessary for the Functional sprints such as wireframes and visual comps, back-end services, APIs, etc.
  • Functional sprints use items from the Foundational sprints to create an MVP.
  • Functional sprints cannot start until at least one Foundational sprint has been run.
  • All team members may participate in Foundational sprints.

Foundational and Functional Sprints

During the foundational sprint, dependency items are created – wireframes, visual comps, prototypes, back-end services, tech debt, etc. This type of sprint enables the regular functional sprint. Foundational sprints include sprint reviews, planning, and estimation just like traditional agile sprints.

Functional sprints are simply traditional Agile sprints[4], with the expected outputs and functions.





Excerpt from Chapter 8

Max glanced over at him “Storyteller, huh?” The other man smiled, shaking his head slightly.

“Yeah, yeah, I know. Super hokey.” He looked down at his feet for a minute, then up at Max, serious. “But it works, you know? We’re kind of…everyone thinks they’re really really good at communicating. But that’s not true. We’re really really bad at it, but because we think we’re good at it, we just assume other people are stupid or worse that we know what they really want. I still screw up all the time, but the story templates help me get back on track. Make me think about how other people see it and how to help them see what I’m saying. It’s not the solution to world hunger or anything, for sure. But it does make talking to someone else easier. And it keeps you honest about your own…filters.”[1]

The elevator doors opened onto an underground corridor. Cold air rushed to meet them, causing Max to shiver slightly. The underground had been part of downtown Dallas for as long as he could remember. But when the zombies came, it became an easily fortifiable way to connect a multitude of businesses together. While other restauraunts and shops struggled to adjust to securing their storefronts, those located in the underground thrived. They quickly walked down a ramp that opened into a large food court. Trevor gestured at the coffee shop, and they made their way through a milling crowd to place their orders.

Coffee in hand, they wandered over to one of the metal tables scattered about the food court. Trevor looked pensive as he sipped his cold brew.

“You know,” Max started “The drone thing…I think it’s got potential. Do you think we can get a hold of the inventors and check some things? I mean, the specifications we’ve got have it being really heavy. Is that something we can work with?”

Trevor nodded, thoughtfully. “I’m a software guy, but I think the angle is right – with the current constraints, the system is unusable for the type of targeting the RFP has listed. The question isn’t so much can we do it – it’s tech and that’s about as close to magic as you can get – it’s whether it’s cost-effective. One thing our Product Manager has pounded into our heads is cost. Everything’s possible if you have unlimited resources.”

“Tell me about it – Justin is all about ‘cost’ and ‘marketability’. He’s a total kill-joy sometimes. He never gets excited about improving the usability of something – I mean, we’ve got some seriously clunky workflows that I’d love to overhaul! But if it’s not going to sell more product, he doesn’t care.” Max stopped and corrected himself “That’s not entirely true. He does care. It just doesn’t make a difference when he’s putting in his vote on what we spend time on.”

Trevor shrugged sympathetically “Yeah, same with us. But I get it. Making products, it’s a balancing act, y’know? You could make the coolest thing in the world, but if no one wants to buy it, well..” he paused, fishing out a pen from his pocket. He started drawing a Venn diagram on a napkin “You’ve got to have three things for a product to be successful. It’s got to be usable – that’s us. It’s got to be possible – that’s dev. And it’s got to be saleable – that’s product. If you only have one or two, the product is worthless. For example, if it’s possible and usable, you still can’t sell it. If it’s sellable and possible, you can’t use it. And if it’s sellable and usable, it may be impossible.”

Max studied the napkin. It made sense. He remembered a product he’d conspired to make with Owen, their lead developer, on the side. A mobile app that let you message your friends when you spotted a zombie. He and Owen were convinced they had the new market disrupter and worked weekends and after hours to make a prototype. It was beautiful, elegant, efficient – everything they wanted it to be. They brought it to Justin, full of righteous pride in their baby. And he proceeded to tear it to pieces from a marekt perspective. They’d been unaware there were other apps on the market that did precisely what they were proposing – and had been for at least a year. And that those apps were doing poorly as the social media giants already had plugins to capture this particular use case. Also, they hadn’t thought past the initial release. What would come next? How would they expand the market once they had captured it? The following lecture on pricing structure still left Max with a headache. It had been an unpleasant lesson in the need for market research and understanding.

“You’re right,” Max sighed. “We need to pull Justin in on this as well as Owen and see what kind of cost we’re looking at. But,” he paused, sipping his latte “it may not matter. The targeting problem is a big one, and the largest issue is the hardware. If we can’t make that more agile, the software won’t matter.”

“I agree” Trevor said. “We need to keep an open mind though. We can’t let the stories take over. “

Max sat back, surprised “Wait, I thought you were all about the stories! What’s this – second thoughts?”

Trevor chuckled, “Nah, you know it’s just that anything good can be bad too, right? It’s like…” he, paused, searching for words “so stories are great because they help you communicate your ideas. And that’s super important right? But the thing is, when you tell a story, you’re communicating YOUR idea in a way that is easy to understand and easy to latch on to. But, maybe you aren’t telling the whole story. Maybe, you only told the part that makes me want to believe in what you believe. When we create stories without data, and without multiple perspectives, we stop being able to think logicially about things. It’s like that balancing act between dev, product, and design we talked about earlier.” He pulled out his pen and started drawing another sketch.

“See, the more solution-oriented a story is” he drew a graph, showing ‘solution’ on the y-axis “The more likely we are to believe it, without checking our facts “ he labeled the x-axis ‘belief’. “The problem is that the actual facts lie somewhere closer to the beginning.”

“As a result, we have to be careful to not tell ourselves super detailed stories about the solution until we get all the facts. Solution stories are the most seductive ones, since our brains naturally want resolution. “

“But” Max protested, “What about the story Manisha told? And the horror stories we wrote? Aren’t we likely to do the same thing with those?”

Trevor shook his head “It’s always a risk – like, we could make a horror story so visceral that we lose track of the fact that it’s unlikely to happen and is just an edge case. And that happened to us a lot when we first started using stories, so it’s a good thing to be on the look out for. But, “ he tapped the napkin for emphasis, “Solutions are always a trouble spot. We love a good puzzle because we love finding the solution. Once we find one, it’s hard for us to let go and see other possibilities. Also, you start to try to make the facts fit your solution instead of the other way around.”[2]

“Hmmm….” Max thought about it.

[1] Stories have been shown again and again to be an effective communication tool when conveying unfamiliar or difficult subject matter. For an interesting review of the arguments for and against using narratives to convey fact-based information, see

[2] Good stories can skip the logical part of your brain and go straight for the emotional center. For this reason, it’s important to make sure you have all the facts, or at least as many as you can reasonably gather, prior to making your solution story. For more information on the dark side of stories, see

Excerpt From Chapter 4: A Visit

Nodding slowly, Max conceded, “Just like that. I’m not totally convinced stories will help that, but I guess I’m willing to try.” He looked back at the board. “I just wish I had a better grasp of the use cases. I want to get moving on this. We’ll see what the research team comes up with. Meanwhile, we might as well get moving on our own part of the research by looking at potential competitors[1].” He paused, “Where’d Trevor go? He’s going to want to be in on this.”

Manisha pulled out her phone “I’ll text him – he’s probably scoping out the break room for caffeine.”

Max pulled out his laptop and started searching for ‘weapon software interface’. Results quickly filled his screen and he read through the first few:

  • Weapon store management: Inventory control for weapons store
  • Ration Software integrates older air weapons with drones, FAAC reports
  • ORKON International weapons systems: Integration of modern day weapons with cutting edge technology
  • Launcher and weapon interoperability – common interfaces: RFP for study on instituting a common interface for weapons launch software

He felt Manisha pull up a chair behind him. She smelled like spiced tea and apples, making him think incongruously of his autumns on campus as a student at MIT. He mentally shook himself free of the odd memory.

“Competitive analysis? Good call.” She said, reading over his shoulder. “Check out the ORKON system. They’ll be competing with us for sure.”

Max pulled up the ORKON site. Their landing page was impressive – slick background videos showed soldiers in AR goggles stalking through targets and shooting them with complete accuracy. Testimonials and POV videos of the software filled the page.

Manisha nodded at the information. “Good set up for a mobile solution, but the AR isn’t really necessary for targeting with the weapon system as we understand it. It’d be cool, but not effective.”

“Agreed. ” Max said, making some notes and returning to his search. Next he brought up the study on launcher and weapon interoperability. The paper had a lengthy description of the study parameters, and some interesting diagrams showing key areas of consideration when providing targeting displays for weapons use.

Trevor walked in and set his laptop down beside Max’s. After a couple of false starts, they had a solid list of current work, possible competitors, and highlighted items of interest from cross-over technology. Unsurprisingly, several gaming interfaces featured on the list, highlighting interactive styles and techniques that could prove useful.

Max leaned back in his chair, stretching. “This is a good start but…” He was cut off as alarms blared through the building. A harsh female voice repeatedly bleated over the PA system:

[1] Competitive analysis has two distinct parts. In the first, designers look for inspiration and context by seeing how others in the same or near spaces have solved the problem. For example, a designer trying to solve the problem of the best interface for dog adoption might review other adoption websites but they would also look at Tinder and Amazon. The second part is a more rigorous analysis of strengths and weaknesses from the user experience standpoint. This approach parallels the product management Strength Weakness Opportunity Threat analysis but focuses on the UX of the product rather than the market positioning. For more information on conducting a competitive analysis, see

Excerpt from Chapter 3 “The Plan”

“We need to flesh out the characters, observe the weaponry in use to understand any unstated limitations and requirements, and then determine what our happy ending looks like. Ben, can you walk us through how you’ll use the story to inform the research approach?”

Ben unfolded from his seat and strode to the white board, accepting the marker from Manisha. He started by writing “Characters” and underlining near the top of the white board. Max noticed it was a good foot higher than Manisha’s “Problem”.

“Using the story, we can identify three explicit characters that need to be mapped and one implied. The explicit characters are, of course, the squad members who will be the direct users of the product, the uninfected non-military humans who will not interact directly with the product but will benefit from it and may react to it’s use in unpredictable ways, and the zombies that will be the target of the product. “

Reaching up, he wrote “Explicit” under “Characters” and listed each of the characters, each with its own stick figure.

“We also consider software and hardware “characters” for this exercise so we can keep them in context.” He listed the weapon and each type of software next.

“Implicit characters are those implied by the narrative, but not directly mentioned. In this case we have implied that they have the equipment they need to do the job, so there is an implied outfitter who would have provided and configured the product for the team before they entered the situation. Also, I want to point out that we have made the implied assumption, through what isn’t on the requirements list” he nodded to the list under problems, “that field configuration is not currently on the table for the RFP. “

Trevor spoke up “Maybe not, but it’s a good point – we need to make sure we have an alternate timeline that handles that so we keep it in mind for future iterations.”

Everyone started talking at once. Max stayed quiet trying to decide what kind of whacky science fiction “alternate timeline” would take them down.

Ben raised his voice “Folks, hang on, one at a time! Trevor, you’re right, we should start notes for an alternate timeline. Quick definition – an alternate timeline is how we term stories that cover features we want to consider including but aren’t part of our scope for a given release. They are things that we need to keep in mind to provide room for them in the future – they keep us from inadvertently boxing ourselves into a solution that isn’t extensible or losing ideas that come to light during ideation.”

On the white board, he wrote “Implicit” and listed the outfitter with his own stick figure. Then next to that he wrote “Alternates” and started a bulleted list with “Field configuration” as the first item.

“Now wait, “ Max said thinking out loud. “there could be an infinite number of rabbit holes we run down with this. How do we keep it from getting crazy? I don’t want to end up putting a cup holder on this thing because someone might want a cold one in the middle of a shoot out!”

The room laughed and Ben, smiling broadly, nodded. “Great question! You don’t really need to keep them in line from a practical standpoint because we’re not actually going to do anything with them at the moment. So if you have a crazy what-if idea, we write it down to acknowledge it. That’s the important part. It’s a way not only to keep things in mind but to also clear the board so we can concentrate on what we have to do for the current problem.”

Max sat back, crossing his arms. “Ok…let’s see how this goes.”

Ben turned back to the board “Now that we’ve identified the characters and started an alternate timeline, we need to determine the best research approach for this situation. Let’s list the unknowns.”

“This is a new weapon system, so the usage is completely unknown” Next to the weapon system he drew a circle and colored it in completely.

“Next we have the zombies – zombie behavior in these situations is pretty predictable, at least for our software. Otherwise we’d all be out of jobs!” a smattering of laughter greeted this assertion. He drew a circle next to the zombie that was not colored at all. “Same with our software.”

“But the shooters and outfitter are both new personas for us, so we need to see how they work – what environment are they operating in and what types of interactions they’re currently dealing with within the context of our story. We don’t need a complete picture of what they’re doing when not on a mission.” Squad had a half colored in circle.

“The non-infected folks need to be researched from a tangential point of view – we can rely on some interviews with squad members that have been through these types of situations and don’t need to do direct observations.” The non-infected happy stick figure got a circle with a quarter of it colored in.

“Using this, we can easily see we need to do get a demo of the weapons system in use and interview squad members and the outfitter as well as review any video we can grab that shows them preparing for and dealing with zombies. Fortunately, I got a call back this morning from our government contact and we should be able to have a demo later this afternoon. I’ve also got inteviews lined up with three people on the first squad that is in line as an early adopter of the weapon after the demo. I haven’t gotten an outfitter yet, but I’m hoping we can get in touch with one later today. The government has been very helpful in getting us the contacts we need.”

Sylvia sprang up, moving quickly to the board.

“So, if I’ve got this right, this is the identification formula you’re using.” She snatched the marker from Ben’s stunned hand and started writing.[1]


[1] Discovery/observational research includes ethnographic studies and other forms of in –context research that require researchers to observe the subjects in their environment. Contextual inquiry/interviews involve speaking with end users to elicit specific information. Both of these are qualitative research methods ( Secondary research includes non-direct research forms such as a literature review or reading through reports.(Byrnman A., Bell E. (2015) Business Research Methods pp 320 Oxford University Press, Oxford, UK)

Horror Stories: The Importance of Defining the “Not-So-Happy” Path

Considering the messy extremes is critical to good user experience design. Whether it is planning for a million records instead of the five that fit neatly onto your screen, use of a 20 item navigation menu on a mobile phone, or how a dark backdrop with white text performs with glare during outside use, good design accounts for non-ideal situations, ensuring that the solution is scalable, extensible, and accessible under a variety of conditions.

Following is an excerpt from my upcoming book “Agile UX Storytelling”. Here, we see our team grappling with understanding how to think about designing for when things go wrong, starting with understanding the potential problems.

Max cleared his throat, trying to put his misgivings into words. “It’s a lot of moving parts with very little information.” He said finally. “I can see how we’ve got an ideal case, but there’s so much we don’t know…”

“Exactly!” Justin nearly shouted his interruption. “This is a total shot in the dark! How can you just make up a story like that and expect us to believe it will work? I mean, where’s the research? We should be planning this for months before we try to make a move! We don’t know if it will work at all.”

Manisha waited for Justin to wind down before she said “That’s an interesting perspective. Tell me, what information do you feel like is missing?”

Justin spluttered, gesticulating wildly in the air as he jerked back. “Market analysis! Problem verification! System compatibility!” he jumped up from his seat and started to pace. “I mean, sure, it’s an RFP so the market is pretty locked down, I guess. But problem verification is huge – you said yourself we need to keep it open-ended to make sure we’re solving the real problem, not what they imagine the problem is. And that takes time we just don’t have. I don’t see how we can get that to a high degree of confidence before we have to start coding the proof of concept. And then the system compatibility issues! What if we can’t make our software talk to each other? What if we can’t make it talk to the firmware the weapon has installed? What if…” he trailed off as he looked over at Angie. Max turned to see a slightly guilty smile on her face.

Justin stared “Angie….?”

She shrugged from where she sat, perched on the table “Hey, you guys didn’t think I made this decision in a vacuum did you? We did our due diligence prior to the acquisition. Have some faith in Owen and Ward – they’re smart guys. The firmware interface is another matter, but we’re doing investigations on that as we speak.” She turned to face them both. “Guys, this is an opportunity. A HUGE opportunity. And we are in a position to move quickly and take advantage of it. I know it seems fast, but we’ve all done things like this before. I’ll admit – there’s a risk. But it’s a calculated risk, not a foolhardy one. I need you both to get your running shoes on and stop belly aching about the fact that I moved your cheese.” She hopped down and started walking towards the door. “You know your stuff – you got this.” And then she was gone.

Max stared open mouthed at the empty doorway before shaking himself and turning back to Justin and Manisha.

“Well, that’s that, I guess.” He said with a shake of his head. “She’s right, of course. I’m more caught off guard than anything. “

Manisha smiled and nodded her understanding. “I’ve been involved since the beginning, so it’s a lot less of a surprise to me. I definitely understand how disconcerting all this can be.”

Justin crossed his arms with a frown. “Yeah, well, ‘disconcerting’ is sugar-coating it. I’d say fu…”

“Justin!” Max interrupted, cutting his eyes at Manisha.

“What? I can’t even express an opinon any more? Screw that! I’m out of here!” Justin stomped out of the room, muttering under his breath.

Max sighed. “He’ll cool down in an hour or two. This product is his baby and he just needs some time to get used to the idea.” He paused. “But he’s right that we’ve just got the happy path. How do we account for the not-so-happy paths?”

Manisha nodded “Horror stories. Right. We should be able to knock out a few of them now. We’ll be able to get more once the research team gets back with the contextual work so we have a better understanding of the current challenges.” She reached for the white board marker and started a new list titled ‘Trouble.’

“First, let’s list out potential failure points we’ll need to consider. Off the top of my head there’s visbility – the risk that they cannot see the targeting screen due to lighting conditions. Equipment failure – how do we handle an error within the hardware or software.”

Max chimed in. “Multiple targets, multiple users…oh, wait that’s not so much a failure point as a use case.”

Manisha started a second list title ‘Use Cases’. “Exactly. And we need to capture those too. Keep ‘em coming.”

After about 15 minutes they had added environmental factors (rain, cold, heat, etc.) and interference (enemy control of weapon) to their failure points. The use cases were proving harder.

“I just don’t have a good feel for the workflow on this.” Max grumbled. “And how are we going to turn this into …what did you call it?…’horror stories’?”

Manisha laughed. “Again, it’s not as hard as it seems. Let’s take visibility for example. We need to make stories that cover using the system when it is very bright, very dark, or the person using it is otherwise unable to see the interface.” She paused for a moment. “Take our original story, the dead squad in the high rise. You’ll remember the power is out and it’s poorly lit. Now, let’s add a line to the story about the gunner for this weapon. He wears prescription glasses and in the initial rush into the building they are knocked off his head and break.”

Max sighed. “Sounds a bit hokey, but ok, I’m game. So he can’t see well both due to lighting and losing his glasses.”

Manisha nodded “Once we get everyone back together, we can test that scenario out and see if it holds. If it does, we write requirements for eyes-free operation.”

Max was unconvinced. “Look, I don’t want to be disrespectful, but it seems to me that this is a lot of extra window dressing without a good return. I mean, I like a good story as much as anyone! I’m just not getting it.”

Manisha again, just nodded. “I know, it’s hard to see the value at first. It seems silly and like extra work for no reason. The return comes when you get multiple people involved. That’s the point when you need stories the most. It keeps everyone on the same page and ensures you’re seeing things the same way – or at least know that you are not seeing things the same way.” She paused, thinking. “Have you ever designed something perfectly to Justin’s specifications but had him come back and tell you that wasn’t what he asked for?”

Max looked down, a bit uncomfortable. “Well, sure. All the designers I know have that problem. Product managers are just…well, they aren’t always that good at writing requirements, you know? Plus they’re always coming up with new stuff to push into it and…” he trailed off, starting to understand.

Manisha prompted “And it’s like they aren’t on the same page as you? Like they have a different idea in their head?”

Nodding slowly, Max conceded, “Just like that. I’m not totally convinced stories will help that, but I guess I’m willing to try.”

Look for monthly excerpts – the book is coming out in 2017!

Defining Problems

Defining problems is a key and often overlooked step in software development.  Everyone like to solve problems – but determining what the problem is first can save time and ensure the solution is something extraordinary.

Excerpt from Chapter 2 of Agile UX Storytelling:

Max nearly choked on his bagel. After scalding his mouth on the coffee in an attempt to get the rest of the bagel down, he sputtered “One MONTH? To integrate two completely different code bases with a hardware interface? And that doesn’t even begin to touch on the workflow integration for a system that has to be field ready for God-only-knows what user base?  Are you INSANE?”

The lead developer barked a laugh which turned into a cough as Ben elbowed his ribs. Manisha nodded her head sympathetically. “I know it’s a lot to take in, but I’m confident that if we follow our story process, we’ll be able to come up with POC that will not only satisfy the government requirements, but that will give us the blue print we  need to make a really great product.”

Max just stared at her open-mouthed.  She didn’t seem like a crazy person, but what she just said was, without a doubt, crazy.

Angie snickered “Close your mouth, Max, before you start catching flies!”

Manisha smiled, nodding to the white board wall behind him. “Let me explain.”

She walked up to the wall, snagging a marker on her way past the table. She started to draw as she talked.

“Since humans first started to communicate, they have done so in stories. “

She drew two stick figures facing each other.

“Stories give us, not just the facts, but how the person telling the story sees those facts.  They give us context” She drew a blob between the people and gave each person  a thought bubble – one had a circle in it, the other a square. Then the person with the circle started talking and had a speech bubble with the blob = circle.

“By telling each other stories, we are able to see things from other people’s perspectives and help other people see our perspective.”

She added a circle to the thought bubble with a square and put an equals with a question mark over it.

“This lets us come to a common understanding a move forward”

She erased the blob and made a square with rounded corners, replacing the contents of the thought bubbles with the same shape.

“Stories also help us understand patterns”

Now she drew two new stick figures. One had a speech bubble with three stars, one circle and three more stars.  The other had a thought bubble with three stars, one circle, three stars, one circle and then three dots.

“…even if we can’t see the patterns ourselves.”

Max nodded his head reluctantly. “OK, that’s all nice but how is that going to make this insanity you guys have cooked up doable?”

Manisha erased her drawings and wrote ‘Problem’ as high as she could reach. It was not very high. Then she turned to Max “To tell a story, first you need to know the problem that the characters are trying to solve.  So, let’s talk about what our problem is.”

Max leaned back, thinking. This was a lot like some of the design sprints they had run at the game studio he’d worked at prior to Where’s The Zombie.  You had to define the problem before you could get on with the solution.

“OK – talk me through the problem.”

Manisha took a moment to take a drink from her thermos before continuing. The elaborate scrollwork on the metal seemed a stark and artful contrast to the somewhat sterile conference table, and Max wondered what she was drinking. Tea? If he had to bet, he would bet it was tea.

“We have several problems, “ Manisha said, returning to the white board. “Let’s start with how we’re defining problems.

For our purpose, a problem is a situation or event that we want to change to achieve a different result.  The problem definition should include both the problem statement – that is what the situation or event is – as well as the desired result. The important thing is to avoid trying to solve the problem in the problem definition.”

Max nodded vigorously, glancing sidelong at Angie.  She was studying her shoes, deliberately not looking up. This was an old argument they’d had many times – she had a tendency to want to jump straight into problem solving mode and had a hard time understanding why that was an issue.

“Exactly” Max said, “It’s like asking someone to build you a car instead of asking them to build you a way to transport individuals and their belongings from one point to another.”

Manisha smiled again “Precisely. By defining the problem, you determine all of the requirements. In your example, you would need to define how many individuals would need to be transported at one time, under what circumstances, how frequently, and so on.”

“But,” Angie interjected looking a bit miffed “Then you might design a bicycle or a scooter or something!  And I wanted a car!”

“Do you?” Manisha asked, unperturbed by the interruption.”By defining your requirements well without suggesting a solution, you might end up getting a teleportation device or something equally amazing. There are a number of excellent examples of how well-defined problems lead to superior solutions from the oil industry to medical research[1]. Defining a problem well is both difficult and rewarding.  It can lead to true innovation or could identify new directions. It ensures that you are creating a solution that has no problem.

At Virtual Zombie, we’ve discovered that creating stories helps us better define problems.  Let me show you what I mean.”

On the board, she drew three large squares, like a cartoon series. In the first, she drew a stick figure with it’s hands in the air and a thought bubble that said “oh no! Zombies” with another angry looking stick figure reaching for it.  In the second square, she drew the same two figures, with a third pointing a gun with the label “new” at the zombie saying “I’ll save you”. The third box had the zombie sticking it’s tongue out at the figure with the gun saying “Missed me sucker!”

Max snorted. “So our problem is that zombies are sassy?”

Manisha laughed “If only!  Our problem is that we need to protect people from zombies. We want to use the governments invention, but the new weapon does not do a good job of targeting. It’s not very mobile or easy to use, like a rifle or a handgun.”

Intrigued, Max asked “What are the specifications?”

“Good question!” Jolene slid a stack of papers over to him.  Justin scooted a chair over to take a look. Max started reading through the papers. The weapon was unwieldy and heavy – it had to be mounted on something that could move it around.  Accuracy was important for disruption of the zombie but shooting innocent civilians wouldn’t be an issue as the pulse was not harmful to regular humans.

Justin looked up “So, why don’t they just widen the beam? It says here that tests on humans showed no reaction – why not just make it like a big area effect?”

Jolene nodded at the papers “Keep reading.”

Max had already reached the answer “Look here “he pointed to a diagram” It’s effectiveness becomes diluted as the beam becomes larger. Larger than a basketball and it becomes useless. It’s got to be…let’s see… 2 inches in diameter for optimal effect.” He looked up at Manisha and Jolene in surprise. “That’s tight! How accurate can you be with the VZ software?”

The lead developer, a young man with long dark hair spoke up – Max tried to remember his name…Winston? Wesley? William? Definition a W-something…

“Accuracy won’t be the issue in a single case – it’s scaling it to large groups that require retargeting that hits our limit. We can model singular zombie movements to within tolerance.”

Manisha moved back to the board and under Problem she wrote ‘protect humans from zombies’. Under that she started a bulleted list titled Requirements ‘use government weapon’ ‘retargeting’ ‘accuracy to 2 inches’.