Corporate life expects us to be experts, to know the answer to every question. We make “requirements”, which turn out to really be assumptions, but because we never call them assumptions, we never go about testing them. This is as much a social political issue as anything. The higher you are in the organization, the more you’re expected to just know the answer.

In this episode, Jared and Richard Banfield explore the role of design sprints in cultivating an environment where it is ok to say “I don’t know”. Allowing yourself to admit this, and allowing your teammates to as well, leads to greater collaboration as you explore the answers together.

Richard Banfield is joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. He’s teaching a daylong workshop on facilitating collaboration across your organization bypassing the usual politics. For more information, visit uxi16.com.

• The Westgate Hotel - 0.1 miles away - +1 (619) 238-1818

• US Grant Hotel - 0.2 miles away - +1 (619) 837-4270

• The Sofia Hotel - 0.2 miles away - +1 (619) 234-9200

• Bristol Hotel - 0.2 miles away - +1 (619) 232-6141

And don't forget the airbnb option as well. Just be sure to search for Gaslamp Quarter, San Diego, CA, United States.

Storytelling is a powerful way to measure our understanding of our users and their experiences. But unfortunately, we don't always get the story right. User experience rests more on listening to what the users want to tell us rather than the stories research teams and designers tell themselves within the confines of their organizations. Perhaps it’s time to first try story listening before recanting the tales.

In this episode, we hear a story from Mike Monteiro about design going wrong. Jared Spool then talks to Marc Rettig about how the team could employ a technique, the Collective Story Harvest, to take apart the problem and come to new insights. All by listening to a story.

Marc Rettig is joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. He’s teaching a daylong workshop on research techniques for gaining deeper insights. For more information, visit uxi16.com.

That’s where the car’s ignition system comes in. Turning the key supplies electrical power to a second motor, called the starter, which in turn, turns the crank shaft and moves the pistons. The car then starts firing the spark plugs, which ignite the fuel, and the combustion engine takes over from there.

In today’s cars, it’s all done automatically and takes a split second — we hardly ever think about it. Yet, without that ignition system, the car would never get going on its journey.

Design Sprints Act Like An Ignition System for Project Teams

Project teams have the same problem. A well-formed project team may sail nicely, once they get going. But starting from a standstill can be a big problem. If the team doesn’t start the project right, it will sputter for quite a while and may never come up to speed.

This is where a design sprint can be helpful. The activities of the sprint inject a concentrated burst of energy into the team, giving it the push it needs to get going in the right direction at a good pace.

Recently, I’ve been talking a lot about design sprints with Richard Banfield, who along with his co-authors, C. Todd Lombardo and Trace Wax, have just come out with a new book on the subject, coincidentally named Design Sprint. Richard explained to me that the design sprint is a series of user experience activities that take a team from understanding the projects goals, to brainstorming possible ideas, through prototyping the best of those ideas and finally validating the assumptions that underlie the project. A typical sprint can take a week (and occasionally even less), and get the project off to a fantastic start.

Ignition Sequence #1: Getting the Team in the Same Room

I asked Richard how design sprints are a great project starter. He told me one reason is they get everyone on the team in the same room for the duration of the sprint.

“We’ve had recently a situation where the leads of certain products and certain departments were in a conversation with us about the design sprint process. One of the project managers came to me afterwards and said, ‘That’s the first time we’ve all been in a room together in about three months.’ Just the fact that they were all in the room together was a good starting point.

“This is not an elixir for all problems, but if you just get people into the room together and start talking about these things, amazing things happen. We’re talking to each other. We’re actually having a conversation. We’re not just sending each other emails or doing Google Docs. We’re actually talking to each other about the things that are important.”

In many projects, people ramp up slowly, finishing up their old obligations before starting. Without having everyone in the same room and focused, the project takes forever to get to speed.

With a design sprint, everyone starts at the same time with this focused activity on the new project. Even if, the following week, they have to return to their previous project to tie up loose ends, the sprint has given the team this focused burst to start with.

Ignition Sequence #2: Acknowledging We Don’t Know The Answers

Another reason design sprints kick a project off so well is they actively acknowledge that we don’t know all the answers. In many projects, people’s roles force them to act like they know the important answers, even when they really don’t. This starts these projects on a false platform of unverified assumptions, which makes it hard to recover from when the truth starts to emerge.

Richard explained it this way:

“People come to us and say, ‘We’ve got this problem,’ and we’re immediately assuming that they’re asking us to come up with a solution. Whereas, the right answer is to say, ‘That’s an amazing problem. I don’t know the answer. Let’s figure that out together. Let’s work on that together. Let’s figure out what the best solution might be.”

“We just don’t have the confidence to do that, because we were told right from the get go when we start school, that there’s only one answer for something. You get given a math test, and the math test says there’s a right answer and a wrong answer. You get given an English test and there’s a right answer and a wrong answer.”

“We grow up with this belief that there are only answers. Instead of saying, ‘I don’t know, but here’s something else that we could consider.’ Or, ‘Let’s talk about that and come up with the best answer.’ We’re predisposed to think that for every problem out there, there has to be an answer and we’re supposed to carry that in our back pocket.”

“Whereas in truth, we don’t know what the answers are, especially in this ambiguous future. How could I have possibly known that there were going to be this many devices available in 2016? How was I supposed to know that entire industries’ markets were going to be disrupted by simple ideas?”

Using Design Sprints to Start the Engine

Organizations rely on their teams to create the innovations that will drive their future competitiveness. As those teams initiate their innovation projects, they need to ensure they are starting them at full speed. Design sprints offer a simple, yet effective way to make that happen.

Assembling a team and leading a design sprint is an essential skill for today’s UX professionals. We’re excited about Richard Banfield’s full-day workshop, Leading Design Sprints to Jump-Start Team Collaboration, at the UX Immersion: Interactions conference in San Diego, April 18–20. If producing innovative results is on your mission for this year, you’ll want to spend the day with Richard to fill your leadership toolbox with great team project tools.

There are cooked cakes, which we enjoy. And there are uncooked cakes, which need to become the cooked cakes. Batter and cake. The two states of a cake.

This metaphor breaks pretty quickly, so let me get through it as fast as I can (which is typically how I tackle a cake). Without batter, there can be no cake. Yet batter is different from the cake. Batter looks and feels different from cake. It serves a different purpose.

The cake state is ready to be eaten. The batter state is about being made. Sure, you can eat some of the batter (who hasn’t licked the mixer beaters?), but baking the batter into the cake is the real objective.

Batter is about constant change. As you mix in the ingredients, the nature of the batter shifts. Cake, on the other hand, is static. Once it becomes cake, it remains cake. (Let’s not talk about drying out and becoming stale, as that is where the metaphor breaks. At least, I hope it breaks there.)

In design, we have something similar to the two states of a cake: artifacts and deliverables. If deliverables represent the fully-baked ideas in our design, artifacts represent the half-baked ones still forming.

The distinction between artifacts and deliverables is very important, yet something we never find ourselves discussing, just like the multiple states of cakes. If we create one when we think we’re creating the other, it will lead to confusion that wastes time and convolutes the team’s efforts. We need to understand how they work and what makes each one valuable.

Before and after the decision-made point

Artifacts and deliverables are very similar. In fact, they can sometimes take exactly the same form.

A wireframe, for example, can act both as an artifact or a deliverable. Same with a persona description, a user scenario, a journey map, or design sketch.

For artifacts and deliverables, the state changes when the design decisions are made. Before the decisions are made, a design sketch or user scenario is just an idea — a proposition that helps us understand the problem better.

After the decisions are made, a design sketch tells us what direction the design is taking. The user scenario informs the team on what problems the design wants to solve.

Deliverables are for communicating intention

Deliverables are how we tell the story of what the design will be. Of course, the classic deliverable is the finished product itself. Nothing tells the story of the design better than the product.

In the days of old, the finished product was the only deliverable. There were no plans or blueprints, just what the craftsman completed.

Collaboration across the organization changed all that. Others needed to know our intention — what we wanted the design to be. Thus, intermediate deliverables were born.

Deliverables have historically taken the form of descriptive specifications. Because representative prototypes have only become a reality in recent times, we relied on documents filled with descriptive prose and flat, two-dimensional sketches to communicate our intent for the final design.

Only in the last few decades have we started to understand the notion of a prototype as a deliverable. Architects started making little models of the skyscrapers they wanted to build. Car designers made clay models of the vehicles they sought to put into production.

In the online world, we use site maps and wireframes to specify what we’d like to see built. When the designer is not the person who will implement their design, we need ways to draw out what we’re doing.

The lean push to eliminate deliverables

Recently, “deliverables” has become a naughty word in the design community. We’re told we need to stop working on creating deliverables, and focus on building the product itself. The argument is deliverables can’t be shipped and anything we need to specify can be embedded in the product’s code — the ultimate specification, we’re told.

There’s a lot of logic to this argument. For example, to specify the colors of a design, the designer could code up the color values directly into the CSS. Developers on the team can use those CSS specifications directly in the code. If the designer wants to then change the color, they simply change the CSS and everything propagates in the next release. No need for the developer to check a non-shippable Photoshop file to get the color values.

But deliverables aren’t only used to communicate to the developers the specifications of what to build. They are seen by stakeholders and others in the organization, to understand the direction of the design. Sometimes it’s to show progress is happening. Other times it’s to give insight into specifics others need, like how to plan the product’s marketing messages. In an organization that has many parallel activities leading to the product’s release, deliverables communicate how the jello is being nailed to the wall.

It’s unlikely these deliverables can be eliminated. The marketing folks aren’t going to look at the code-in-progress to see what’s been decided, so they need to get the intention in another form.

Intermediate deliverables that show the designers’ intent will always have a place in large organizations. No amount of wishing will make them go away.

However, we can always ask ourselves if a non-code deliverable is the best way to communicate to our audience. We can design deliverables specifically to the needs of the audience. This means we need to be fully versed in all the different techniques and flavors deliverables can take.

Artifacts form a common understanding

Artifacts represent our current thinking about upcoming design decisions.

Sometimes, we produce a ton of artifacts very quickly. Take a design studio, for example. In the process of a few hours, the team will produce dozens, if not hundreds, of sketches. Each sketch explores an idea or two about potential solutions.

What’s interesting about the design studio artifacts, like all good artifacts, is the discussion they encourage. The team can look critically at each artifact and develop a vocabulary about the problem.

Most artifacts are thrown away, having the ideas in them deemed ‘not worthy of further contemplation.’ But, the process of creating them, critiquing them, and discussing their implications lives on. They become the basis to the teams common understanding of the problem.

The disorientation of hunkering

Artifacts are most useful when working amongst a cross-disciplinary team. Creating the artifact gets the creator’s ideas out into a common place where it can be inspected and discussed.

This is a form of hunkering, where we take an idea and put it into the world, to see how it works when it’s not just in our own imagination. Seeing a design like this is disorienting for the creator, because the reality of seeing it is very different from just imagining it. It points out flaws in the idea, but it also can spawn inspiration.

When people with different perspectives hunker around a design idea, the discussion creates a useful vocabulary about what the team is trying to do. It can lead to new directions. Repeating this frequently can generate whole new approaches to the problem that wouldn’t be considered otherwise.

Artifacts and deliverables each tell the story differently

Not all artifacts should be discarded once the team has milked it for all they can learn. They provide a rich history of the thinking process.

A design’s story isn’t just its final outcome. The story also needs to include the journey the team took to arrive at that outcome.

Artifacts are useful for communicating that journey. In fact, it can make for a very powerful presentation to stakeholders to show some of the artifacts that demonstrate the constraints, challenges, and thinking behind the final design.

Surfacing the effort can be both enlightening and entertaining. (After all, who doesn’t like the behind-the-scenes footage found in the DVD extras?)

Deliverables tell the story of what we think the design should be. Artifacts tell the story of how we got there. Each are powerful storytelling tools.

Serving different purposes

Just understanding the difference between artifacts and deliverables can make a team more productive. Knowing which they are working with, at any given point in the design process, is critical to getting the most out of them.

Artifacts are often best in a rough form, when many are produced quickly. Deliverables often want more refinement and are iterated over to accurately represent the team’s thinking.

Deliverables are often horrible tools for debating options. The team really wants to have settled on their decisions before they construct their deliverables.

Artifacts, on the other hand, are perfect for debate and discussion. Their lightweight and short-term view makes them the perfect straw man proposal to test ideas and explore the problems. It doesn’t make sense to refine most artifacts. Instead, you just throw them aside and start anew.

The challenges of being clear about malleability

We can’t tell which we’re looking at by just looking at the artifact or deliverable we’ve made. It’s easy for a wireframe to be a deliverable, showing the developers what we want the page to look like. But a wireframe can also be the starting point of a discussion about the design, with no intention it’ll be implemented as is.

It’s the context of where the wireframe is being used that determines what it is. Is it before decisions have been made or after?

As a practice, we’re not very good about being clear on this. And when there’s a lack of clarity, confusion sets in.

We’ve played with the fidelity of our tools as a convention. For example, making a rough design mockup with a tool like Balsamiq gives the impression the design is still under consideration, versus something that can look photo-realistic like an HTML prototype. Lower fidelity says artifact, while higher fidelity suggests deliverable. But not all types of artifacts and deliverables have a fidelity dimension to play with.

What makes this even more complex is, in a project of any reasonable size, design decisions aren’t made all at once. They are distributed throughout the project timeline, with some decisions cast into stone while others are still awaiting exploration.

Showing which decisions have been made, when some are still pending, can lead to challenges. We need to develop tools and processes to communicate where we are in the decision making process for a given design.

There’s still plenty of thinking we need to do around artifacts and deliverables. I’m looking forward to more discussion and examples of how teams are solving these important challenges.

We need to embrace our half-baked artifacts and understand better how to utilize our fully-baked deliverables. This kind of introspective approach to our design process will make us better designers and produce great designs.

Prototypes are both great artifacts and great deliverables, depending on how you choose to use them. That’s why we asked Chris Risdon, who is teaching a full-day workshop to show us the best ways to use them. Take a deep dive into the hows and whys behind solid prototyping techniques, to get the most out of your design process. Check out Chris’ workshop right here.

When your user gets value from your design, they’ll likely make using it into a habit. They’ll keep coming back, forming more habits as they continue to get results.

When we add new features, we often force them to break the habits they’ve carefully formed. That’s what makes our users upset when we change the design unexpectedly. Their old habits no longer deliver the value they once did, and now they have to form new ones.

In this episode, Jared learns from Amy Jo Kim how game designers approach the problem of introducing new levels, weapons, and other features. Amy Jo shows how the way game designers think can be easily applied to your designs.

Amy Jo will be joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. She’ll be teaching a daylong workshop on using game design approaches. For more information, visit uxi16.com.

Five Overall Benefits:

1. Conquer chaos and confusion with simpler designs.
2. Lead the team and stakeholders to dynamic collaboration.
3. Overcome daunting requirements and functionality by tackling scale.
4. Identify opportunities and inspire growth by driving strategy.
5. Eliminate the need to hire outside UX personnel.

Proven Techniques and Best Practices for UX Designers

Go beyond inspiration and immerse yourself in groundbreaking interaction design skills you won’t find anywhere else. Get your team on the same page with proven UX methods, tools and clear-cut direction on specific actions and skills. Attend two full-day workshops and a day of talks to learn the latest strategies and techniques for building great products.

Tackle Critical UX Topics and Move Projects Forward

• Dive deep into the best techniques for building prototypes at every stage of the design.
• Surface the connections in your customer’s underlying social systems to develop richer design scenarios.
• Learn the framework of triggers, rules, feedback, loops, and modes to create seamless designs.
• Choose a user-oriented approached to design based on how your users think, not how the data is structured
• Use simple gamification tricks to effective engagement techniques that promote user growth.
• Maximize team collaboration and learn core leadership techniques to empower your team with an immersive design process.

Summary of Costs

Use promo code UXIBen to save $300 on your full conference registration.

Download This as a PDF

There’s a saying that you can’t know where you are going unless you know where you come from. Designing navigation for enterprise applications is a journey unto itself. One that UX Immersion speaker, Hagan Rivers is quite familiar with.

In this podcast, listen as Jared Spool discusses the importance of clear navigation systems in enterprise applications with special guest Hagan Rivers. They explore techniques for tackling complex navigation, how screen codes are perfect for those with in-depth experience, and how a balance with ease-of-learning is critical.

When you’re sitting face to face with the wilderness that is an enterprise application, a map and compass would serve you well. Unless you’re a tracker, know which side moss grows on a tree, or can follow the stars, you’re likely not going to be able to navigate through on your own, much less find shortcuts and become proficient.

Hagan will be joining us in San Diego, CA on April 18–20 for our UX Immersion: Interactions conference. She’ll be teaching a daylong workshop on how to guide users through the wilderness. For more information, visit uxi16.com.

Prototyping Phase: Render a working version (even if it’s all smoke and mirrors or just a paper mockup) of the best ideas in a plausible design to test our assumptions.

Validating Phase: Put our prototype in front of real users, and watch them give it a spin. We validate our assumptions, learning even more about their needs.

The nature of the design sprint is these phases happen very quickly, with a series of activities guided by a trained facilitator. The activities themselves are fun and productive, but the real value comes from their inherent qualities that lead to a shared understanding. It’s these critical qualities that help prevent future executive swooping and pooping.

Shifting Self Design to Activity-Focused Design

Self design is a decision making style where an individual makes choices based on how they’d want the design for themselves. It’s a common style for people who haven’t had much experience doing design, or when seasoned designers don’t have a lot of other information to go by. They put themselves in the role of the user and ask, “How would I want this design to work?”

Executives, without any of information, will often approach a design this way. If what the team has presented doesn’t match their own perception, they’ll questions the decisions and suggest their own alternatives.

In many cases where the executive’s attention is disruptive to the team, it’s because the team themselves have also used a self design approach to arrive at the current design. (Or worse, they used another style, unintentional design, where they hadn’t put much thought into the design at all.)

This is where a design sprint helps. The design sprint’s structure forces the team away from self design or unintentional design approaches. Instead, the team engages in activity-focused design, basing their decisions on researched activities of the user. When the team invites real users to try a prototype, they’re collecting data of what the users needs, which gives a more solid footing on what the design should be.

When the executive shows up, the team can present this data along with the design that emerged from it. Having real data behind the design decisions reduces the influence the executive can assert, and smart executives will embrace the approach.

Exposing the Team to Real Users

Teams who have regular opportunities to meet with, talk to, and most importantly, observe their users turn out better designs. We’ve found if team members spend two hours every six weeks watching their users, they bring that knowledge to their design decisions.

In our experience, the first exposure is the hardest for the team. Design sprints help tremendously, because usability tests are built into the process. Once a team has that initial influx of data, subsequent sessions become easier to execute. When the executive shows up to review the design, the team will have the data from their repeated exposures to bring to the table.

It’s even better if, while the design is evolving, the executive is also exposed to real users, along with the team. The executive will have their own exposure experience to draw on, instead of just relying on their own gut feelings about what the design should be.

Converting Requirements into Assumptions

The conventional approach for designing products and services starts with a list of requirements gathered from stakeholders and subject matter experts. The team then takes these requirements as truths, and tries to address them in their design.

The problem comes when the requirements turn out to be false. Unfortunately, because there’s usually no validation process built into the conventional design process, it isn’t until late (sometimes as late as when the product ships) that the team learns they went down the wrong rabbit hole.

Often times, it’s when an executive comes in for review that the team is first learning about problems with the requirements. While this appears to be a swoop and poop maneuver, it’s actually a course correction. Unfortunately, it’s happening too late in the process to be effective.

Using a design sprint approach, the team converts requirements into assumptions, then validates them. The assumptions are documented up front, prioritized, then as the sprint continues, tested against the realities of the world.

This gives the team fodder when they meet up later with the executive. They can intercept the swoop and poop in mid-flight, sharing what they learned from the assumption validations.

Neutralizing the Politics

It’s a bonus when the executive partakes in the design sprint directly. Not only do they see the rigor of the process, they can contribute their knowledge and experience first hand.

The beauty of the design sprint process is its special attention to neutralizing the politics in the room. Through each phase, the facilitator leads the activities using techniques designed to empower each participant, regardless of role power. Ideas and contributions from the sprint team’s lowest ranking member are equal to that of any executive or other high-ranking members.

A skilled facilitator makes this feel seamless and invisible. Everyone feels they’re being heard. More importantly, all ideas are open for equal consideration, making progress happen quickly and innovation more likely.

Because the executive contributed as part of the team, they’ll understand the underlying rationale of the design decisions. It’s a great way to prevent future swoop and poop operations from occurring.

Creating A Culture of Continual Learning

Trying out what seems like a great idea and discovering that you’re wrong is a fantastic way to learn. Doing it quickly and early in the process mitigates the risks associated with heading down the wrong paths, delivering more educational value to your organization at a lower cost.

Design sprints start with an innocent questioning of everything. Quickly your team learns that many of the assumptions you’d been basing their decisions on are not as rock solid as you thought. However, with each smashed assumption comes a new perspective on what the users need from the design.

Over the course of the sprint, a team learns a raft of new information. Smart teams don’t let that attitude of learning end when the sprint ends. Instead they build it into their culture, continuing to identify each new assumption and validate it, learning more as they go.

Building a culture of continual learning is probably the most valuable benefit of well-run design sprints. It doesn’t hurt that it builds the teams knowledge and confidence for when an executive shows up, ready to swoop. Knowledge about the users and what they’re trying to do makes for a solid poop umbrella.

Using Design Sprints to Prevent the Swoop And Poop

Design sprints aren’t the only way to prevent a swoop and poop incident. Nor are they guaranteed to stop them 100%.

Yet, the rising popularity of design sprints is warranted. They bring a lot of advantages to a team, delivering a shared understanding and solid basis of knowledge on what design they should be building.

When an organization integrates design sprints into projects, they see a dramatic decrease in outside influencer disruptions and an increase in their design quality. That a well-facilitated design sprint can help deflect an executive swoop and poop is just a very welcome extra benefit.

Design sprints are a powerful technique for bringing innovative new products and services to your customers faster. The best way to learn them is to experience them, which is why we've asked Richard Banfield, co-author of the new O'Reilly book Design Sprint, to lead a full-day workshop at UX Immersion: Interactions. You'll come back with everything you need to bring design sprints into your process. Check it out: uxi16.com.

Being Generative: Exploring Outside Our Comfort Zone

These two variations were obvious. The first idea, then the inverse of the first idea. Chris’s recommendation is you don’t stop there. Instead you study the problem a bit more and see where the journey takes you.

In both of these variations, searching tutors and putting in your account information are discrete, unconnected activities. What if we merged them, making them less discrete?

What if we built the parent’s profile by using the choices they make as they refine the tutors? We could glean their location, their child’s age, and the topics they desire help on, all by just seeing how they filter the list. That information could become smart defaults in their account profile.

Voilà! A third variation is now born!

Pushing beyond the obvious alternatives is what Chris calls “leaving the comfort zone.” Sometimes, by giving ourselves a little time and space, we can find additional variations that didn’t suggest themselves immediately, and these can have elements which are better than what we originally came up with.

We use these generative design techniques to explore possibilities. We haven’t spent a lot of time on each one, so we have more time to generate new variations. In turn, we learn more about the problem’s landscape.

Fall in love with the problem, a good Jedi designer does.

Getting Feedback: Listening to the Voices Around Us

Multiple variations deliver a big advantage by helping us collect richer feedback than when we only have one version to show. We can get our peers and stakeholders to move beyond the “I like it” / “I don’t like it” twins, neither of which helps us learn what to do differently next time.

With multiple variations, we can ask our reviewers to compare the versions. We can hone in on our intention for each iteration. We can see if one intention does a better job of solving the problem than others. Most importantly, we can explore why the variations solve the problem (or don’t), using that new understanding for future iterations.

Still, there are more traps to avoid, such as the obvious question of Which version do you like best? We don’t care about whether someone likes a variation. We care about whether the variation does what it intends to do.

Our first variation of the tutor finder was about getting the profile built, so the user could start with better tailored search results. Given that was its intention, we can ask reviewers how well our variation achieves that goal.

What is it about Variation One that makes it better at getting users onboard than the other two variations? Why?

Where does Variation One fall short, compared to the other two variations, in getting users on board quickly? Why?

Each variation should have its own intentions, separate from the other variations to make it unique. As the team discusses the different intentions, a language emerges to describe the problem and its possible solutions. This deep exploration makes us all smarter about our designs.

The cool thing is using multiple variations doesn’t require a radical change to our process. It’s a way to keep us from falling into the trap of getting too involved with a single direction before we fully understand the problem.

Find more about his workshop, which you don’t want to miss

This focus on features let design fall to the wayside, making it less important than the application’s perceived capabilities. Now, you’re forced to stare at a screen straight out of 1995. You’ve become a time traveler, whether you were aware of it or not.

We’ve come across other time travelers in our journey. You aren’t alone. One such person is Hagan Rivers, who has worked tirelessly to bring these enterprise applications into modern time, if not the future.

In this podcast, listen to Jared Spool weave a tale of time travel with special guests Hagan Rivers and Dana Chisnell.

Hagan will be joining us in San Diego, CA on April 18-20 for our UX Immersion: Interactions conference. She’ll be teaching a daylong workshop on how to tackle what travails time travelers. For more information, visit uxi16.com.

Dan Saffer is an expert on microinteractions. In fact, he wrote the book on it. He says that microinteractions essentially operate based on triggers, rules, feedback, loops, and modes. For example, when you engage a scrollbar, how fast does it scroll? Or when you click a volume up button, what percent increase is each click?

Just think of a car. In the broadest terms, a car is a car. But the styling of the interior, leather seats, placement of cupholders, and how the in car stereo system works all help differentiate one car from another. These are often subtle differences, but as with microinteractions, these small differences are crucial to the overall feel and experience.

You don't want to miss Dan's UX Immersion: Interactions full-day workshop that goes right to heart of challenging design problems, delivering astonishingly elegant solutions.

These days, collecting all the necessary details to make a smart flight purchase is very challenging. These are challenges external to Hipmunk’s team, yet they’ve done a good job of using it’s novel visual display and sorting algorithms to reduce those challenges. We call these goal challenges, because they are inherent challenges the user faces in the meeting of their goal.

But novelty comes with a price. Because people aren’t familiar with this display of their information, they need to learn how to read it. When it comes time to customize the information, such as to indicate flexibility in departure times or to hone in on only non-stop flights, the user needs a method to control the display. If Hipmunk’s users are distracted by controlling the interface, they can’t pay attention to the thing they came to do: book the best flight.

Hipmunk’s designers don’t want more challenges because of their interface design choices. When they do, we call these tool challenges. Tool Challenges are obstacles created by the designers, due to their choices in the design.

An important design goal for any productivity tool is to simplify goal challenges without creating any new tool challenges. Any productivity tool, whether it’s to schedule appointments, identify supply chain backlogs, or discover new chemical interactions, have goal challenges. These tools need to ensure they don’t also add tool challenges.

Turning to Game Design

Designers of Productivity tools aren’t the only ones who have to find the best balance of goal challenges and tool challenges. Game designers do too.

In game design, you want the user to focus on the challenges inherent in the objectives of the game. Yet, to play the game, it has to be easy to manipulate the game pieces on the board, to ensure the player doesn’t get distracted by the mechanics.

Take a puzzle game like Two Dots. The basic play of the game is simple: draw a connection between two or more dots. Each level of the game adds challenges to accomplish that, which is what makes the game fun for its players.

Two Dots’ designers also needed to put in tools to control the play of the game, such as changing levels, turning off the sound or music, and adjusting colors for color blind players. These tools must be easy to find and use, not a challenge like the game play itself.

Game designers are experts at ensuring goal challenges remain in the users’ focus, while ensuring that tool challenges are minimized or eliminated. By studying how the best game designers have made these tradeoffs, we can learn how to improve the productivity tools we’re designing.

We are fascinated by the way smart game designers approach hard problems. We’ve been following the captivating work of Amy Jo Kim, who researches how game designers create immersive engaging games, regularly pushing the edges of interaction, visual, and information design. She’s developed practical frameworks that apply game design approaches to the kind of design work we do all the time.

Join us for Amy Jo’s full-day workshop at UX Immersion: Interactions in April, 2016. You’ll walk away a slew of new techniques that will forever change how you design your applications.

I turned around and noticed the other 50 or so JetBlue passengers staring intently out of the airport window, their gaze fixed on a plane—our plane—which was now pulling away from the gate with none of us on it. I turned back to the gate agent in front of me and said, “Our plane is pushing back.”

“Yes,” he said without looking up from his terminal, “it’s on the way to the maintenance hanger. We have to get the gate area ready for the 8 o’clock, which just landed.”

None of this surprised me. At 7:15, when the captain and crew from the 7 o’clock flight—the flight I and all these other passengers were booked on—unceremoniously walked out the jetway door and away from the gate, I figured we weren’t going anywhere. While I noticed their quiet egress, most of the other passengers hadn’t. Without any additional announcements from the gate agents, everybody was still in the dark about whether the 7 o’clock would ever leave. Now the disappearing plane seemed to confirm their worst fears.

I kept wondering: Could the design team at JetBlue create a solution that would have dealt with this? How would you design a great experience around a plane that suddenly needs maintenance? (These days, I spend a lot of time waiting for planes to be fixed. I think about this a lot.)

Small Percentages and the Rule of Large Numbers

JetBlue, like all airlines, will tell you this is rare. They’ll say 99% of their flights take off on time without any maintenance delays.

And they are correct. In a typical day, JetBlue puts their planes in the air 1,000 times. In that day, they might only have 10 maintenance issues that cause a serious delay of more than a a few minutes. (When talking about delayed flights, the takeoff isn’t as important as the landing. A serious delay is one that puts passengers at risk for missing a connection or other important event.)

But, across a year, that’s 3,650 seriously delayed planes. With an average of 170 passengers per flight, that’s 620,500 JetBlue passengers each year that will likely have a less-than-desirable flying experience. JetBlue is only one airline, one which has amongst the smallest number of flights and amongst the newest fleets (that should be more reliable).

When dealing with large numbers, small percentages are also large numbers. (That’s the rule of large numbers.) One percent maintenance failure, when applied to every passenger on every plane that has that failure, is still a large number of passengers.

It makes sense that an airline design team would want to help their 620,500 customers have a better experience when problems come from a maintenance delay. It’s not hard to see where you could improve the experience. You could deliver better communication of what’s going on, automatic rebooking to the final destination (even when it’s through a different airline), automatic baggage routing and notification, and automatic “distressed traveler” accommodations for lodging and meals (which the airline may be obligated to provide). Computers could do these things, as long as someone designed and built a system to do so.

What would those solutions look like? How would the airline’s already heavily-burdened IT systems know to make these arrangements and communicate them to the passengers?

Complexity from Systems

I made it onto the 8 o’clock flight. Other passengers weren’t as lucky. Checking the flight status, the original 7 o’clock finally left the airport at 9:42.

There were several groups of JetBlue people involved in this flight: the gate agents, the pilots, and the flight attendants were who I saw. There were also maintenance people and airport operations teams involved. JetBlue’s flight operations team was dealing with the inevitable downstream effects of the delay. And there were the passengers. (We can’t forget the passengers.)

Part of what made the experience frustrating for the passengers was how these groups weren’t talking to each other. The pilot and crew left the flight, not saying a word to the gate agents. The digital flight board, 20 minutes after it’s planned departure time, still said the flight was leaving at 7 o’clock—nobody from flight operations had updated it with a new time.

Each group is an independent system, doing its own thing to make this flight happen. The mechanics are working with one set of procedures, rules, and constraints. The pilots have their own, as do the gate agents and flight operations. Each of these independent systems have been finely coordinated to work well when everything happens as planned.

These independent systems are not finely coordinated when they encounter the maintenance delay. They are an edge condition, an instance of system coordination that happens outside the norm.

While it’s relatively simple to design processes, procedures, and support tools for independent systems working well together, designing for edge conditions is a level of complexity most teams aren’t ready for. More importantly, they don’t have the tools to make it happen.

Falling in Love with a Complex Problem

There’s an old saying: Great designers don’t fall in love with their solution. Great designers fall in love with the problem.

It would be easy to imagine a collaborative tool, on smart phones and other portable devices, that each team could use. Mechanics could describe what they think the problem is. They could put in an estimate on what it will take to fix it. Pilots and gate agents could see that information and relay it to the passengers. Or the information could find its way directly to the passenger’s own devices.

We’d also need to help with the rebooking issue. How do we get passengers on their way with a minimum of disruptions? Rebooking passengers en masse creates a further communication problem (how does a passenger know to run to a gate elsewhere?) and puts strain on the system. Plus, the mechanic’s estimates are known to be fallible. A problem that looks bad can often be fixed by simply rebooting the plane. (A comforting thought, eh?)

If the design team focuses on solutions for when passengers experience a delay before the team figures out how the independent systems work, their solutions will fail. They need to spend time researching the independent systems to see where the failure points are and form a rich understanding of the constraints and interactions. They need to fall in love with each of the independent systems and the problems they create.

Observations and Interviews Can’t Get Us There

Our go-to tools for user research are the old standards of observation and interviews. We march into the field and see the problem as it happens. We interview the people involved, to understand their context and how they think of it.

For edge conditions, seeing the problem occur is, well, a problem. The JetBlue team could wait in an airport concourse until one of their flights suffers a maintenance delay, but that’s cost inefficient. Being there to observe the problem in progress, even when so many happen, near impossible.

If they understood the situation, they could interview the mechanics, pilots, gate agents, and operations personnel after the fact. However, that presents its own problems. It’s hard to ask the right questions to get to a deep understanding when you don’t know what questions you need to ask.

The old tried-and-true methods of observation and interviews won’t cut it. We need something else to get us the deep insights that will tell us how to design for complex independent systems dealing with infrequent, edge condition issues.

Collective Story Harvest

Marc Rettig has seen problems like this JetBlue problem before. In his work at Fit Associates, he regularly works with organizations that need to solve gnarly independent system interaction issues. His clients have a good handle on how to make things work when all the systems are functioning normally. It’s the edge conditions that get them, and that’s where Marc comes in.

I asked Marc how he’d try to understand what’s happening in this problem. He told me he’d employ one of his favorite techniques: a Collective Story Harvest.

When Marc facilitates this technique, he invites all the project influencers together, including the design team, stakeholders, implementers, and others who will have a say in how the final solutions will look. He then invites storytellers—individuals who have experienced the problems the group is trying to solve. In the JetBlue problem, storytellers would be mechanics, pilots, gate agents, flight operations staff, and even passengers who have experienced a maintenance delay.

Marc then divides the project influencer group into smaller groups, with one storyteller in each. He’ll ask each of the project influencers to take on a lens to listen through. One lens might be the story narrative, while another might be the breakthrough moments, and another might be the principles that could be learned from the story.

As the storytellers relives their experience of a maintenance delay, each group member listens intently while they focus on their assigned lens. After the storytellers finish, the group reflects what they heard, repeating back to the storytellers the important elements they learned.

Marc next asks each project member assigned to each lens to compare their notes with everyone else assigned that lens. All the narrative folks share the different narratives they heard, while all the folks who were listening for breakthrough moments compare theirs. Each team member shares the story they heard to the rest, looking for similarities and contrasts, and strong patterns emerge.

What comes from a Collective Story Harvest session is a deep, rich understanding of the problem. The Storytellers, after hearing what the team learned, report they also learned new things about their experiences. And the project influencers walk away with a much better understanding of the dimensions of the problem and how the independent systems interact (or don’t) when the edge condition occurs.

Storytelling: Unleashing the Power of Retrospection

We’re taught in User Research 101 that you should not listen to our users. That what our users say isn’t as important as what they do. That’s why we focus on observing their behavior.

Yet, when dealing with edge conditions, our observations won’t work. This is why techniques like Collective Story Harvest are so important. (And there’s a bunch of techniques that are just like a Collective Story Harvest.)

These techniques don’t ask the users to solve the problem. Instead, the techniques use the power of story to take apart what makes these problem complicated. By asking a storyteller to relive a difficult experience, you hear it through their point of view.

It’s when we compare the points of view of different storytellers that we start to see the patterns. When we ask people to reflect on what has happened, and apply different lenses while we listen, we create an environment of retrospection that’s very rich. From that environment emerges the details, subtleties, and nuances that will help us come to a shared understanding of the problems we’re trying solve.

We’re not asking our participants to tell us what to build. We’re integrating the stories they tell of their experiences into our collective understanding of the problem. We’re on our way to loving the problem more than we can ever love the solution.

Fantastically Exciting News: The Collective Story Harvest is one technique Marc will teach in a brand new workshop at our brand new UX Immersion: Interactions conference in April. The workshop, which will be hugely interactive, will introduce you to other methods, like the World Café and Situational Modeling—all to help you get to a deeper understanding of the problems you’re designing for. We can’t wait to learn to use these methods on our toughest projects. You’ll want to too.

Here’s where you can find out more about UX Immersion: Interactions.