The Conference Blog & Podcasts

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.

Transcript

Jared Spool: Welcome to the UX Immersion podcast, I’m Jared Spool.

Being a designer, leading a design project, means putting it out there, making the calls. Everyone expects great things from us. And, it’s scary. Very scary.

That stops us from doing the right thing. From admitting the truth.

Richard Banfield: We are so scared of being wrong, we’re so scared of saying, “I don’t know,” that we’d rather just not have the conversation.

I’m Richard Banfield, the Chief Executive Officer of Fresh Tilled Soil. I’m the guy at the office that everybody wants to avoid having in a conversation, because I’m the highest paid opinion. That’s not very useful.

Jared: Richard’s been studying what happens when people avoid these conversations. He’s found the fear of being exposed as a fraud simply by saying “I don’t know” and allowing for that conversation to occur, is very real.

For example, take how we start a project. The conventional approach is to create a list of requirements. More often than not, these requirements turn out to be assumptions. We’re just assuming our customers need the things that are in that list.

Richard: As my very good friend, Dave Cancel often says, “The worst thing you can do is make these assumptions, because none of us are right any of the time.”

Jared: Even though we’re not right, we continue the practice of listing out requirements and making demands.

A large part of the problem lies in the hierarchical structure of organizations. The higher you are in the organization, the more you’re expected to just know the answer. It’s good to be king, most of the time. Sometimes, when that fear of exposure rears it’s head, you don’t want to seem like the one who’s got shit all over them. Even when someone sits at the top of the hierarchy and is expected to have the answers, they can still be wrong.

Richard: The hierarchy may disincentivize them to talk to each other, but it also might be political. It might be that there are these victims that people are protecting, also protecting their personal space, their jobs, their titles.

In any system that has some kind of complexity or hierarchy, there is an inferred politic. There is a structure that decides who has the last word or who has the most say in any conversation.

In our organizations that we work in, the typical business, there is a hierarchy that is dictated to by somebody’s title, their longevity with the organization, their domain knowledge, their gender, their age. All of those things help people understand where they fit into those conversations.

Even in the most non-political organizations out there, there is still some kind of societal influence or cultural influence over the politics.

Jared: Politics exist anywhere there is more than one person. If you’re the sole inhabitant of your desert island, then your reign is supreme and everything you do pleases everyone, because, everyone is you. But, as soon as there are competing ideas from multiple people, they must discuss them to arrive at a consensus, and to evolve the those ideas. The trick is finding the right tactic to advance these discussions.

This is where design sprints come in. A design sprint is an alternative to the conventional requirements gathering process. The project leader brings a team together to list assumptions and validate them with real users and customers. The nature of the design sprint’s structure turns saying “I don’t know” into a good thing. This is because you just saved the organization the pain of going down the wrong path.

Richard: In some kind of accidental way, design sprints turned out to be this UN of design methodology, where you would just get people in a room together and you’d say, “Why are we fighting about this stuff? Don’t we all really want the same things? Are we not trying to make something good for our users, our customers, our marketplace?”

What the design sprint is structured to do or designed to do, is to avoid letting the people who have those big opinions, or as we call them, the HiPPOs, the highest paid opinions, to allow those people to be quantified at the same level that the junior person’s opinion might be.

If you’re the CEO, and you have a strong opinion about something, it will be leveled against the person who has no political strength or power. By doing so, you’ll start to see these things for the neutral arguments that they are.

What we’ve noticed, having done—I think we’ve lost count now—but let’s say 100 design sprints, we’ve noticed that even the people who have a strong opinion, like this idea, because even they know that their opinions are based on assumptions. They secretly don’t want to be found out either, that’s why they speak so vehemently about their own choices.

They also want to know that there’s a system that will validate the choices that they make and not just base it on assumptions. They’re just as scared as everybody else. This design process gives everybody the opportunity to feel safer. Even the CEO. Even the COO. Even the founder of the organization.

Jared: Organizations, as we know them, were modelled after the structure of a military unit, with a commander at the very top. Orders flowed down and were never to be questioned. The commander could never be wrong. That sows dissent in the ranks.

Modern day organizations have inherited this structure without questioning it. This is what gets us into trouble. Those people in charge aren’t any more right than anyone else.

Richard: Somebody recently wrote an article that was entitled, “The Hardest Three Words in the English Language to String Together Are, ‘I don’t know.'” Because we’ve got ourselves into this situation where we’re all assumed, because of our title and our domain knowledge, and the roles that we have, to have answers.

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.

Jared: Freeing ourselves of the dependency of certainty really opens up the possibilities for solutions to challenges the organization is facing. There’s rarely just one way to accomplish anything. There may be preferred ways, or classic ways, but it doesn’t necessarily mean they are the best, or even most applicable for any given situation. Fostering a culture where it is ok to admit that you don’t know the answer instantly develops strong collaboration.

Richard: The thing that we notice most often is that once you’ve given permission to say, “I don’t know,” or, “This is an assumption,” or, “We should go and test that,” or, “These things that we’ve been basing all of our future roadmap decisions on, need to be made into facts, so that we can be clearer and less ambiguous about our future.”

Once that happens, it’s much more free. The conversation tends to open up. There tends to be less fear in the tone of that design or product conversation. That’s the first thing we notice.

The second thing we notice is that, now that they’ve been given an opportunity to work through a process and that process is familiar to them, they immediately start thinking about how else they can use that process in other parts of their organization.

Jared: Allowing yourself to say “I don’t know” is hard, but it is a skill you can learn. You need an environment that not only supports, but encourages it, so you can develop processes that assist in discovering the answer to what it is you don’t know.

Richard: None of my school, or education, or experience could have possibly prepared me for that. What I need is a system or a process that allows me to face that ambiguity with a whole bunch of confidence and say, “I still don’t know the answer, but I do have a process that’s going to get me to the answer.”

Jared: To create great designs, especially those that are innovative in the marketplace, we need knowledge we don’t have today. Knowledge about our users, about how they work, about what they need to make their lives better. If we don’t get this information, or we guess wrong, we’ll fail.

Admitting that we don’t know everything is what fuels our curiosity. Admitting it to ourselves is much easier than admitting to another person, or an entire team, especially when we’ve been designated the expert.

And for those other people we have to collaborate with, we also have to make it safe for them to admit that they don’t know everything. Structured activities, like design sprints, make that possible. When we create safe, collaborative environments, we open ourselves up to learn the things that make our work great.

That’s why we became designers in the first place.

The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which will be April 18th to 20th in San Diego, California.

Richard will teach his full-day workshop, Leading Design Sprints to Jump-Start Team Collaboration. He’ll walk us through what it takes to facilitate a sprint, showing us all the techniques he uses to make the magic happen and kick start projects quickly. We’ve put a detailed description of everything you’ll learn from Richard on the conference web site, uxi16.com.

The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.

We’d like to thank Richard Banfield for being a part of this episode.

You’ve been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.

The UX Immersion: Interactions Conference is nearly upon us. We’re getting excited to see you there. If you have not booked your room for the conference, you should know we sold out of our guest rooms at the Westin San Diego Gaslamp Quarter Hotel. But don't worry, here are four hotels really close to the conference for you to choose from:

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.

Transcript

Jared Spool: This is the UX Immersion Podcast. I'm Jared Spool.

Storytelling is a power tool for user experience professionals. We tell effective, convincing stories to help others connect to the people we’re designing for. We use our words to paint pictures about what frustrates our users and our customers and how we, as the agents of change, can make their lives better. Storytelling is an essential UX skill.

Another essential skill, one we don’t hear about, is story listening. Story listening is how we enhance our own understanding of what it’s like to be a person we’re designing for. It’s an important research technique. One that can push past the barriers of what we can only learn through observation or interviews, to get into situations that are tough to design for.

To explore how truly valuable story listening can be, I asked Mike Monteiro, who runs Mule Design in San Francisco, to share a story about what happens when design goes wrong. The story of Bobbi Duncan.

Mike Monteiro: The way the story goes is Bobbi Duncan was a freshman at UT Austin. She was interested in music. She played the piano. She sang. She got to school, and she decided that she wanted to join some groups, like you do, make new friends. She joined the queer chorus at UT Austin.

Bobbi is a lesbian, and she hadn't come out to her parents. She used Facebook like everybody does, almost everybody.

She managed through some Herculean effort to actually tweak Facebook's privacy settings to make sure that that happened, so that if she wanted to talk about something that hinted at her sexuality she would make sure that she would tag that in a way that her parents couldn't see it.

When she joined the queer chorus at Austin, the president of the group, he had also set up a Facebook group for the chorus. He made it an open group.

Here's the important part. Facebook made a design decision that when something was posted about you in an open group it overrode your own privacy settings. When he announced that Bobbi had joined the queer chorus at UT Austin, it got cross-posted to Bobbi's wall automatically and overrode all of her own privacy settings.

That's how her parents found out about her sexuality. Facebook told them. They were not happy. They disowned her. Her father disowned her. I hope that four years later, they've come to a reconciliation. I don't know. But that's where it was at the time when I read the article.

Jared: Facebook’s design team didn’t set out to destroy Bobbi’s relationship with her parents. They didn’t even know this had happened.

Bobbi had used the privacy settings the way the designers intended. The chorus president also used it the way they intended. The chorus president wasn’t trying to override Bobbi’s intentions. They were both using the system the way they thought it should work, believing the privacy system had their backs.

The interaction of the two settings combined to make a difficult situation. It took a while to understand how this all went down.

As a designer, listening to Mike tell Bobbi’s story shines a strong light on the complexity of Facebook’s privacy system. The story gives a deep background, while also showing where the edges of the problem come together. It’s at the edges that designers do their best work.

Now, Facebook has an excellent user research team. But Facebook’s team had never encountered a situation like this, because user research won’t easily identify this type of problem.

Marc Rettig: If a company is relying on its UX or design researchers to be its ears, to be its connection to what's really going on in the lives of customers. That's not a very sensitive ear.

My name is Marc Rettig. I am Principal of Fit Associates, a firm in Pittsburgh. I teach about creating in social complexity, the Carnegie Mellon School of Design and the School of Visual Arts in New York.

Jared: Delegating all the listening in an organization to a small team of researchers isn’t sensitive enough. Even a large research team, like Facebook has, is still limited, compared to the entire size of their organization.

Marc: In the bigger picture, we can talk about what it means for an organization to be listening, to open its sensors. So that its decision making, its strategy, its designs, its priorities are connected to what's really going on out there as opposed to the stories that everybody tells themselves inside the walls. They repeat these same stories over and over to each other until we believe that's what the world is like.

Jared: Marc believes that teams need to find a way to put aside the stories they keep telling themselves inside their organization’s walls. They need to listen to people who are having a true experience out in the world as they tell their own stories, just like Bobbi Duncan. This is how we get a richer picture of where the design opportunities truly are.

Marc: You can hear it in their voice. Often, when people are telling stories, they overhear themselves saying details that they may not have known they were going to remember until it was in the act of telling.

As they talk about what the story means, they may overhear themselves talking about beliefs or values that show up as they're trying to let us know why that story is important to them, in a way that we wouldn't have thought to ask.

Jared: For the Facebook team to truly get a handle on what happened to Bobbi, Marc recommends they reach out to a bunch of people who were involved in incident: The choir president, other choir members, Bobbi herself, and, if they were amenable, Bobbi’s parents. Maybe they bring in people from Facebook’s own customer service or others who were involved once the situation became a big deal. The team would listen to each person’s story.

However, Marc suggests this has to go beyond just Facebook’s researchers.

Marc: If only the researchers listen, then they have this asking too much of them, responsibility of translating what they've heard to other people in the organization.

If you can bring the security people, the web designers, executives, managers, people from across boundaries in the organization to listen to these people tell the stories, that will change the conversation that you have after your customers leave. It's quite powerful.

Jared: This group of listeners participate in a deep research activity called a Collective Story Harvest. In a collective story harvest, you gather a bunch of people to tell their stories to a group of listeners, who will then harvest the stories they collect for the design insights.

Marc: In general, a collective story harvest, you can use it in lots of different ways. You can have a group of people listen to one or more stories in a way we're talking about in the harvest of learning's, and they ask how do we apply this.

Suppose now you've done that and now you've got a bunch of people from within your company, from within Facebook, and they're wondering what to do about it. Now you can have internal story harvesting.

The security team can tell stories about the choices that they've made in the privacy settings. The executives can tell stories about conversations they've had with advertisers and the importance of real names or something like that. The developers can tell stories about their struggles with these issues.

Now, the organization is listening to itself and you can use the same method for that. There's variations on it where you can listen to a lot of stories at once and compare what you've heard.

Jared: Hearing a story second hand invites the opportunity for personal experiences and biases to manipulate the original telling. It doesn't even have to be in a malicious way. One person's set of experiences to a point in their life will influence an interpretation of a story or event in a way another's might not. Having more people hear the story directly allows for a better understanding through discussion.

Marc: I always feel that way, is one of our terrific systemic issues is that we leap to making and don't leave time for, I would say two steps, listening. Then real reflection.

You think we've watered reflection down to grouping sticky notes on the wall, which is analysis, which is different than reflection. We've watered listening down to data collection.

Jared: What it boils down to is this: our users are people. They aren't bits of data that we compile into a design. Each person is different, and they all have a story.

Marc: Story is really powerful. This is not a new idea. There's been people talking about storytelling organizations for 30 or 40 years.

Jared: Story listening—truly listening to our users and their experiences—is an important way to really understand them. You don't have to guess about their needs or wants. Acting on the information you get from listening, especially with a team of folks, requires patience and careful consideration. Knowing your users and their stories is one thing. Reflecting upon those stories and distilling them into something actionable that can help our users in meaningful ways is another.

The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which will be April 18th to 20th in San Diego, California.

Marc will teach us how to conduct a Collective Story Harvest, by actually doing it in his full-day workshop, User Research Techniques for Uncovering Deeper Insights. He’ll also introduce other great techniques, like a World Café and Situational Modelling. These go way beyond the basic practice of usability testing and field interviews. I selected Marc for this program because spending a day with him will change the way you do research forever. We’ve put a detailed description of everything you’ll learn from Marc on the conference web site, uxi16.com.

The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.

We'd like to thank both Marc Rettig and Mike Monteiro for being a part of this episode.

You’ve been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.

The
piston-based combustion engine, that marvel that powers automobiles and
revolutionized the industrial age, has one major flaw: it can’t start
itself. Once it gets going, the spark plugs ignite the fuel which push
the pistons in sequence, turning the crank and powering the car. But the
engine was never built to get the pistons moving from a standstill.

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.

Cakes exist in two states. We don’t think about this, because we’re
usually focused on only one state. But that state couldn’t exist without
the other one.

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.

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.

As the product owner finished the 20-minute demo, she braced herself, took a deep breath, and said, “Ok, what questions do you have?”

This is the moment she always dreads. The twenty or so high-profile users on the call are an extremely opinionated and critical bunch. No matter what her group has built to please them, they always have list of why it won’t work and how it’ll make their lives more miserable.

Which is why, this time, it was so weird. They weren’t saying anything. She only heard silence.

She knew they were there. They had interrupted the demo with clarifying questions, so she knew they were paying attention. “Hello? Y’all there?”

The phone erupted with twenty or so, “Yup” and “I’m here” pronouncements.

“So, no questions?” she asked staring at the speaker phone as if it was going to jump up and bite her.

A voice replied, “Not from me. It’s exactly what I expected. Good work. I’m excited about where you’re taking this.” Other voices agreed.

She’d silenced the critics. It took her a few minutes to soak that in.

Seeing the Users Work, First Hand

What made this demo different from previous ones wasn’t the demo itself. It wasn’t that they’d built anything different. What made this time different was how much more the team understood about the users’ work processes and activities.

Months earlier, the lone designer on the team had wrangled a site visit. Instead of going by herself, she cajoled a product manager and a couple of developers to go with her.

They showed up in the field office to watch their users, the field representatives, do their jobs. Even though they’d been working on this project for a while—for some, it had been years—this was their first exposure to how the users did their work.

It was amazing to watch. They saw so many things different from what they expected.

Field reps, who often worked directly with the business’s customers in person or on the phone, would often write down important data before entering it into the system. The team learned the fields on the screens showed up in an awkward order. Interviewing the customer, writing down the data, then transferring it to the screen created a more natural conversation.

The team watched field reps frequently write down information that was on the screen, only to fire up another part of the application and type it back in. “Old school cut & paste” they called it. Of course, there was a lot of cut and paste, though you can only move one thing at a time that way, and often the users need to move more than one field’s worth of data.

This was only part of what the team saw on that visit. They witnessed bespoke spreadsheets to make calculations the application expected the users to do in their heads, saw users jumping furiously around screen instead of following the expected flows, and witnessed a lot of cursing when the application did something unexpected.

The team returned energized to make changes to their own process.Developing a Shared Understanding

Upon return, the team noticed something interesting. Developers and product managers who had been in the field were coming up with better design ideas than those who hadn’t been there.

This put a program in place to get every developer and product manager out to watch the field agents work. As each team returned, designs started to improve.

It wasn’t easy, getting all these folks into the field. It took some selling. Because many of the developers were outside contractors, their contracts needed rewriting to give them time away from coding.

Hagan Rivers, who specializes in redesigning complex enterprise apps (we think of her as a enterprise app whisperer of sorts), says meeting with users is essential. ”You have to be touching base with your users regularly, constantly, so that you understand their pain points.”

Better Developer-User Collaboration

The team adjusted their sprints to review each user story for UI related elements. Any story that touched the UI was now reviewed by the high-profile users—those folks who would be on that demo call who were the team’s subject matter experts. The developers would create a mock-up of what they think the design might be, contact a few key users, and go over the story.

Because the developers had been in the field, they knew how to ask the questions and understood the answers they received. The key users continued to help the team with their shared understanding of how the field agents worked.

Injecting Feedback and Learning Throughout the Project

When it was time to present the project in its almost finished state, it was not a surprise this time. The subject matter experts had seen the project evolving. They had injected their experience and knowledge, making the developers smarter.

Most projects wait until the end (and sometimes until they’ve shipped) to learn what the users’ really need. In this project, the visits to the field reps triggered a chain of events, leading to a smarter, more-informed design process. Field visits became a catalyst for better design.

With knowledge of your users and a toolbox filled with design patterns, you can simplify your enterprise applications and ship something that is truly delightful. Join Hagan Rivers in her full-day workshop, Enterprise Apps: To Boldly Simplify Where Nobody Has Simplified Before, to fill up your toolbox with a rich collection of techniques and methods.

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.

Transcript

Jared Spool: Welcome to the UX Immersion Podcast. I’m Jared Spool.

Imagine it’s a day like many other days. You head into the office,
only you’re cutting it close to make that first meeting on time. That’s
when you suddenly realize you don’t know where the meeting is. You fire
up your calendar to find the conference room, and pray it’s not too far
away from your desk.

Only overnight, while you were sleeping, the upgrade fairies swept in
and installed a new version of the calendar application. With a
completely new interface. And it all works differently now.

That's a problem. You didn't ask for a new interface, but now you have to deal with one, at a most inconvenient moment.

Amy Jo Kim: There's a really, really simple
solution, which is just create a different product for the newcomers,
and let the old timers either opt in or not. Photoshop's been fighting
that battle for years. Their answer is come out with something
different. The old one isn't broken.

I'm Amy Jo Kim.

I am an entrepreneur, startup coach, and social game designer.

Jared: Abrupt, wholesale changes are a surefire way to alienate, and likely frustrate your primary users. Using the product has become habitual. Now your users are forced into a new landscape with no guidance or transition period. To quote the great American philosopher, Homer Simpson, “Going cold turkey isn’t as delicious as it sounds.”

This is a problem that application designers have been dealing with
for eons. But there’s a different community of designers who have
developed successful approaches. Games designers.

Amy Jo: In game design, skill building and mastery
are the through line in the sense of a narrative or a movie, because
your experience over time does take the form of a narrative. You are the
hero, and it's your journey. You, the user.

Jared: In Amy Jo's experience, framing your
customer's journey in terms of that narrative timeline identifies what
your users need at the specific point they are at. Whether you’re
designing for new users to help them to form those habits or introducing
current users to a feature, you need to actually plan for and design
both of those behaviors.

Amy Jo: When you're designing a customer's
experience over time, there are different ways to frame it. The way I
frame it, which is coming from game thinking, is to talk about four
stages, discovery, onboarding, habit building, and mastery.

If you start with really who is using, playing your app, or your
service, your game, you're using your piece of hardware, your fitness
app, band, or whatever it is, that user is going to have that experience
over time. Those four stages are useful for abstracting how you think
about engaging the user at each stage.

Jared: No matter how good our first release is, our
designs need to get better. We learn that the first version could always
be improved. Our knowledge comes from users who have discovered and
started to use the design. There’s a better way to use it. There are
always new features we can add.

But, there’s a risk in adding new features. They can improve your
design, especially for new and incoming users. But if not properly
introduced, you can create headaches for the current users who have
existing expectations of how the design works. How do you avoid failing
your most loyal users?

Amy Jo: In terms of product design, and game design,
and cool interface tricks, there's many, many, many things you can do
to introduce new features. Many of them look like onboarding, because
part of onboarding's job is to introduce new features. Every feature is
new to the first time user.

The bridge there, in terms of introducing new features, is create
experiences that make the features worthwhile. Then work backwards from
there. That's where it's contextualized like sometimes it's a contest,
sometimes it's a fun little thing.

Jared: An existing user is a new user when it comes
to new features. When you introduce a feature, you’re turning your most
seasoned users back into beginners and restarting their journey. Making
those new features worthwhile ensures that people will keep coming
back. The first step in that process, though, might not be what you
think it is.

Amy Jo: Section one is actually not onboarding and
discovery. Section one is habit building and mastery. Even more so,
habit building comes first when you're designing -- bringing an
experience to life.

For that, habit building and mastery those are the stages of regulars
and enthusiasts. Regulars are people that are - it’s day 21. They're
using it. They’re our regulars.

Jared: In Amy Jo’s experience, it takes regular
usage of 3 weeks before the user makes the functionality of your design
into a habit - something they do comfortably all the time. Day 21:
That’s the critical target that you are shooting for to make beginners
into regulars, and continue them on their journey.

Amy Jo: But enthusiasts are the people that go
deeper and master your system, experts -- the super fans. Whatever it is
in what you're doing, there's always two to five percent of people that
just go nuts. Then they often want to go deeper and they want something
more.

Jared: You need to ensure that your new features are
habits that your users want to build. Only when you’re sure they want
to build habits and master the new features, can you turn your focus to
how they’ll find out about those new features.

Amy Jo: Discovery is turning visitors into first time users. Discovery is like, "What is this? Should I even bother? Is it for me?"

It's your marketing. It's your ads. It's the word of mouth. It's
whether discovery is social, or whether it's through ads, or whether it
gets handed down through IT.

Discovery happens in different ways, so it's important to understand how this discovery happened for what you're doing.

Jared: You need to ask yourself, do you truly need
your existing users to discover these new features? Are you clear what’s
in it for them if they do? Maybe they can get by with the existing
functionality, while you leave the newer designs for your new users?

If your existing users need the new features, then you have to help
those users discover them. But this doesn’t mean putting a huge
billboard ad in your designs, fighting for attention for every new
feature. Some of the best products slip their new features in under the
radar, letting users discover them almost accidentally, by having them
appear at just the right moment.

Once users discover the new feature, you then need to help them start using it. That’s where onboarding comes in.

Amy Jo: Onboarding is learning the ropes and you can
define on-boarding in different ways. For some companies, it's two
months. For some companies, it's the first time, 10-minute experience.
But on-boarding is where people learn the ropes enough that they can get
some value out of it.

Jared: If you’re learning to play guitar, you don’t
jump right in and play complicated solos as soon as you touch the
instrument. In turn, without any guidance, you don’t know where to put
your hands or what to strum when. You tend to approach learning in
chunks: notes become chords, chords become scales and over time the act
of playing becomes second nature. That’s when you’ve made the activity
into a habit.

Amy Jo: Habit building is beyond onboarding.
Onboarding is usually either a simple loop that you do a few times, or
it's a one-time experience that's an arc of an experience. But habit
building is always some kind of loop. It's the day 21. What is the core
activity that people are doing that's drawing them back?

Then mastery is what you give to that two percent that wants to
really go deep, and if bothered to master your system. In gaming, we
call that the "Elder Game." Usually, you're giving them a new kind of
game to play -- a different kind of role to play. Earned privileges,
earned powers.

However you do it, if you model those stages. At each stage, you ask
yourself, "What does this person need to learn right now? What is it
they're learning? What skill are they building?" There's always
something. It might be a trivial scale, but there's always something
that people are learning.

If you start putting people into learning, what are they learning
during on-boarding? What are they learning each time they log in on day
21 and day 60? What are they there to learn? What skill are they
building? If you ask yourself that, then you're organizing your whole
experience around the through line of skill building. If you want to
create a compelling experience, that's a great way to organize it.

Jared: When you play a game, often the first few
levels are the on-boarding process. You learn how to jump, run, access
inventory, and make your way through your journey. Helpful messages and
scenarios help you understand the environment and controls. You learn
how to exist in the game and eventually master it.

Just like application designers, game designers add new features,
such as levels or situations all the time. But they don’t expect the
user to figure it out on their own. The game designers return to
onboarding, then help their users build new habits, guiding those users
on their journey to mastering these new features. New is new, even for
experienced players and understanding where they are within the context
of their journey, the designer appropriately addresses their needs.

The users are the heroes of your design. Understanding what your
heroes need at each point of their journey will turn beginners into
masters. Even when we’re changing the game by adding new features.

The UX Immersion podcast is brought to you by the UX Immersion: Interactions
conference, which will be April 18th to 20th in San Diego, California.

Now, if you’re struggling to help your users master all those great
features you’re building into your designs, you need to spend a day with
Amy Jo Kim in her full-day workshop on using game design approaches.
She’ll share the vast experience she’s gained from working on games like
Ultima Online, Rock Band, and my favorite The Sims. We’ve put a
detailed description of everything you’ll learn from Amy Jo on the
conference web site, uxi16.com.

The UX Immersion podcast is produced by myself and Sean Carmichael.
You can find more information about the UX Immersion podcast on iTunes
and at the UX Immersion: Interactions conference web site, uxi16.com.

The music for this episode was provided by Eric Skiff.

We'd like to thank Amy Jo Kim for being a part of this episode.

You’ve been listening the UX Immersion Podcast, part of the growing UIE
Podcast Network. Thanks for listening and for encouraging our behavior.

You know it’s worth coming to UX Immersion: Interactions, but does your boss?
Use this information and cost summary to help you get the green light.

Five Overall Benefits:

Conquer chaos and confusion with simpler designs.

Lead the team and stakeholders to dynamic collaboration.

Overcome daunting requirements and functionality by tackling scale.

Identify opportunities and inspire growth by driving strategy.

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.

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.

Recorded: December, 2015

Transcript

Jared Spool: Welcome to the UX Immersion Podcast. I'm Jared Spool.

Nothing has plagued humanity through the ages more than the simple problem of getting from here to there.

Hagan Rivers: In general, a classic problem of Enterprise apps, I sit down and 25 or 30 percent of the pixels on the screen are dedicated to navigation. That's horrible, because Enterprise apps really need every pixel.

My name is Hagan Rivers.

Jared: Hagan spends her time working with companies to, among other things, clarify and streamline their navigation systems in large enterprise applications.

Hagan: They have big tables and lots of data and giant forms. They can't afford to lose anything to the navigation systems, and the navigation systems grow and grow and grow until...I literally had a client who had half the pixels on the screen lost to navigation of one kind or another.

Jared: The user’s tasks should be relatively easy to accomplish. Yet, because of the lost screen real estate, these tasks become a journey across "quick links", tabs, sidebars, help links, and footer links. All leading away from the user’s transaction. Much like Dorothy asking directions of the Scarecrow.

Hagan: I've run into apps, too, like this, where they have navigation on the top which is like tabs and menus, and then on the left they have a tree, and they go to the same places. I ask them, "Why do you have two navigation systems that go to the same tree?"

"Oh, we weren't sure if users would like the new one on the left, so we left the one on the top so that they could keep using that if they wanted to." You probably failed at that point. [laughs] If you don't have confidence in your new design, that's probably not a good starting point.

Jared: Every application that has more than a single screen requires some sort of navigation to move between them. Yet, there’s no definitive style for how the navigation should look and work. If you don't have that confidence in your own design, you tend to look outward for examples that seem to work.

Hagan: When Amazon was using tabs, there were Enterprise apps all over the place that had 10 and 20 tabs across the top, and then Amazon moved away from tabs, but the tabs stayed. They just added a new system on the left. [laughs]

Then they went to menus. So, I think it's a real sense that they're chasing the right idea, but they haven't really sat down and thoughtfully designed it and tested it with users.

Jared: There are, of course, always people who know where they're going and how to get there. A business traveler moves more swiftly through an airport than a infrequent vacationer would, breezing through security, and advancing quickly to their flight’s gate.

So-called "power users" have learned behavior that becomes almost muscle memory as compared to those unfamiliar or new to the product. Many enterprise applications were built with short screen codes that would jump you exactly where you wanted to be, making navigating with app of 600 or more screens really not that big of a deal.

Hagan: I worked on a healthcare app this year that they still have the screen codes. I watched users use them heavily. People who had been using this app for a decade and they knew the codes. They knew where they needed to go.

If you know exactly what screen you want to go to and you know the code for it, there is no faster system to get you there [laughs] than to type it in and go there. That's a great system. It's not easy to learn. It's not easily adjusted to change. It is a fantastic little shortcut for those users.

Jared: Traveling requires identifying the destination. Yet it also requires identifying the vehicle that will there.

Hagan: You start to build up a sense of, "This is a little application. How do these screens fit together in the user's mind, and how do they want to get to them?" The navigation in your application is just another application inside yours whose entire job is to get you to the right screen.

Jared: You want your users to travel quickly, so you need to avoid friction. Often, friction comes from not recognizing where to go or how to get there. Designing navigation is a balancing act, between speed of use and ease of learning.

Hagan: You need to be able to learn it. You need to be able to discover stuff in it. The whole features of your application will live or die by whether or not users find them in the navigation. There's got to be discoverability. Those got to be easy to use.

One of my guiding philosophies is I always try to design the navigation system last which really bugs most of my clients. They want me to start with navigation.

Both on Enterprise apps and even when we're starting an app from scratch, they say, "Let's do the navigation system first." That always seemed really backwards to me.

Jared: Designing your navigation system first is like installing the elevator before knowing how many floors the building will have. Without knowing the inner workings of your app, you can't possibly know the optimal path to guide your users through it.

Hagan: I need to spend time learning all the constraints and the screens and the users and the tasks and all that stuff. They always want to start with navigation. I say, "Let's do some other design work first. Give me an opportunity to understand this application and then we'll work on what navigation should look like."

That's the first thing. It's almost like, "Let's write the table of contents while we still have just the notion of what the book will be." Eventually, you might get to an outline, but exactly with the same process. You want to work your backwards from the screens you made to the navigation system that supports those.

Enterprise apps, people are sometimes are using these apps hours a day. This isn't the light touch like you get in Netflix or LinkedIn or things like that. These are apps that people sit down at for hours at a time sometimes.They don't want a navigation system that's clicky, clicky, clicky. They want to go fast. You've got to a lot of different needs to satisfy. It's hard.

Jared: When you go on a trip, you want as few obstacles as possible. There are reasons travel applications like Hipmunk sort search results by "agony". A direct flight is much less painful than five layovers to get you to the same destination. If your users have to traverse an incomprehensible menu system, or worse yet, they don't even know where to start, it's a clear indication that your navigation might be broken.

Experienced sailors can use nothing but the North Star to navigate their ships. But for the rest of us, we need clear and painless tools for finding our way.

The UX Immersion podcast is brought to you by the UX Immersion: Interactions conference, which is going to be April 18‐20 in San Diego, California. That’s where Hagan Rivers is giving a full‐day workshop on all the tricks and techniques for simplifying complex enterprise applications.

Hagan has been helping teams redesign the navigation on their enterprise applications for decades, so she’s seen and done it all. If you work on enterprise apps, this is a day of learning you can’t afford to miss.

The UX Immersion podcast is produced by myself and Sean Carmichael. You can find more information about the UX Immersion podcast on iTunes and at the UX Immersion: Interactions conference web site, uxi16.com.

We'd like to thank Hagan Rivers for being a part of this episode.

You’ve been listening the UX Immersion Podcast, part of the growing UIE Podcast Network. Thanks for listening and for encouraging our behavior.

We’ve all seen it. That moment when a high-ranking, influential executive suddenly takes our design project off the rails. They burst in with their ideas blasting about who they think the design is for and what it should be.

It doesn’t matter how hard the team has worked on their design. It doesn’t matter what research they’ve done. The highest paid person in the room has a “better” approach and that’s all that matters.

The team just experienced another executive swoop and poop. Like a seagull on the attack, the executive has swooped into the project and pooped all over the team’s design. Flying away as fast as they came, they left carnage and rubble in their wake.

A Symptom of A Bigger Problem: No Shared Understanding

While there is the occasional rogue executive who flies around big organizations cutting their path of disruption, most of the time this is a symptom of a bigger issue. It comes from the team not laying the ground work to get all the important influencers on the same page about the design.

There may be others without shared understanding. They come into the middle of the project with different expectations. Most of the time, the team can dismiss the concerns of these uninformed folks. However, when someone with substantial position power (like an executive) marches in with different perceptions about the project, it’s hard to ignore. Swoop and poop.Design Sprints to the Rescue

The good news is swoop and poop events are preventable. Design Sprints are a popular process that gets the team, including important influencers, on the same page early in the design life-cycle. Through a series of structured exercises, the team identifies critical assumptions, creates a prototype, and validates their ideas, all within a single week or so. The result is a shared understanding of what the team is building and why.

A typical design sprint takes about a week (though some folks stretch them out and others have figured out how to do smaller versions in less time). A team of participants assemble from various roles and perspectives in the organization. They define and unpack a problem that needs solving. They generate ideas and decide which ones to pursue for testing. They build a prototype of their ideas, then validate their assumptions by observing people using it.

In that week, they’ve taken a deep dive into a problem and validated key ideas around it. More importantly, this crew now has a shared understanding, based on real data collected from real users. They can spread that understanding, delivering the insights they’ve gathered to the rest of the organization, including the likely future swoop-and-poopers.

While there is variation to how you execute a design sprint, they all share five common phases:

Understanding Phase: Answer the import questions and surface our assumptions. What’s the problem we’re trying to solve? What assumptions are we making? Who are we solving the problem for?Brainstorming Phase: Generate as many potential solution ideas as we can, exploring the different dimensions of the problem in the process.Deciding Phase: Home in on the best ideas, increasing our understanding of who we’re building for and why.

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.

One trap I regularly see designers fall into is taking their first idea and fleshing it out in detail. That doesn’t sound bad. After all, if it’s a good idea, why not? You need to trust Admiral Ackbar: it’s a trap (which may be why so many fall into it so easily).

Often, our first idea isn’t our best idea, especially when we’re tackling a hard problem. We haven’t fully explored the boundaries of the problem. If we go down the first path too far, it may be too difficult to turn back.

This came up when I was talking to Chris Risdon about his upcoming UX Immersion: Interactions workshop on prototyping. He told me that he’s made it a rule for his teams to produce multiple variations of any design artifact before they start fleshing out any single idea.

Let’s say we’re working on a prototype of an app that helps parents locate nearby tutors for their kids (or even themselves). In this app, each user will need an account to connect with the tutor of their choice. If we want to prototype out what the on-boarding process might look like, our first variation would be create an account, then see the nearby tutors that are available.

We don’t want to stop there, so with another moment’s thought, we realize we could just reverse that order. In a second prototype, we’d first show a list of nearby tutors. The parent would create their account only when they’ve found the middle school math tutor they’d like to contact.

Now we have two prototypes to compare. Not bad. However… Stop there, a Jedi doesn’t.

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.

While
we often talk about building prototypes, we almost never explore how to
do them well. Producing multiple variations is one way to get more from
your prototyping efforts.

I
asked Chris Risdon to put together a full-day workshop to teach us how
to get the most out of our prototyping techniques. His UX Immersion:
Interactions workshop not only will show us how to create an effective
prototype, he’ll open up our world to an entirely new approach to
collaborating on designs.

Enterprise applications are massive, often unwieldy pieces of
software. You get a sense they were never truly improved or updated,
they just had a continuous string of features tacked on until it got to
the point where they are almost impossible to use. And they’re old.

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.

Transcript

Jared Spool: This is the UX Immersion Podcast. I’m Jared Spool.

If we want to immerse ourselves in serious design challenges, there’s probably no better starting place than time travel.

Dana Chisnell: Yes. I’m a time traveler.

Jared: Now some of you may recognize that voice. She
co-authored the Handbook of Usability Testing, co-founded the Center for
Civic Design, and created the Field Guides for Better Ballot Design.

Dana: Hi. I’m Dana Chisnell.

Jared: And since Time Traveler looks a little weird on a resumé, she is currently…

Dana: Digital Services Expert, Executive Office of the President.

Jared: And since that looks intimidating on a business card…

Dana: On my business card, it says Generalist Problem Solver, U.S. Digital Service.

Jared: So Dana is a Time Traveler, sent by the government, and she is in fact, here to help.

Dana: So it’s not a top secret project but it is
government work. What makes it feel like time travel is that when I got a
hold of what the design looked like, what the software looked like for
the users all you had to do was look at the screens to feel like you had
been transported back to the 1990s. Completely reminiscent of early
Windows systems, really felt like I had been here before already. And I
was going to get to do this again.

Jared: I know what you’re thinking: it’s 2015 and
despite promises by Robert Zemeckis, Time Travel really isn’t a thing
yet. But it turns out that Dana’s experience isn’t all that uncommon.

Hagan Rivers: Whenever I sit down with Enterprise apps,
it’s back to the ’90s. They’re old. The apps are old. The code is old.
The databases…Some of these databases have been around 25 years.
[laughs] It’s the same database that they set up the first time they
built it.

Jared: That’s our go to person for tackling time travel issues like Dana’s.

Hagan: My name is Hagan Rivers. I am a User Interface Designer for mostly enterprise applications.

Jared: Hagan is the person that we at UIE turn to when
it comes to taking old enterprise apps and bringing them into the
future. She says that a lot of the problem of why these applications get
stuck in the past is that they are narrowly focused.

Hagan: I find for most of them it’s such a struggle to
even get the features in. Thinking about design is something they just
don’t make time for, or have time for. They seem to be stuck in this,
“Get the features in,” mode. Honestly, when you look at the folks
purchasing this software, they’re often looking at, “Does it have this
feature or that feature?”

Jared: This focus on features is something that I talk
about a lot. When you keep adding feature after feature after feature,
you actually reduce the usability of your product. It’s called “feature
creep”. And the problem in this instance is that the people buying the
software aren’t the ones who are actually going to be using it on a
daily basis.

Hagan: They’re not paying attention to design. It’s not a space yet where design is a big selling factor.

Jared: Now because of this disconnect between the
purchasers and end users, the purchasers are only focused on what the
product allows them to do. And the more things it allows them to do, the
better because they can accomplish more tasks. But the thing that’s
lost in the shuffle is, if you can do these tasks that’s great, but you
also need to be able to do them well. And that’s where the design
factors in.

The companies that buy the software actually believe they can train
their users, who are their employees, on how to use this complex
software. They focus on the features and not the actual task at hand. So
since features are the focus of the people buying the software, the
people making the software in turn just keep adding more and more
features into the product.

Now this type of problem isn’t exclusive to the private sector, it’s
actually part of the reason why the US Digital Service exists. Dana ran
into this when she first started working at the US Digital Service and
had a look at some of the designs they were using.

Dana: They were horrible. They didn’t reflect what
users did one bit. It was like the programmers just barfed the database
onto the screen.

Hagan: Yeah. Dana’s very… visual. I like her. [laughs]

Yeah, the Enterprise applications, first of all, are very database
oriented, because you’re essentially manipulating data in a database.
That’s what they want you to do, is enter, update and maintain a bunch
of databases.

For them, the design works if you can update the database, if you can
adjust the fields, or make the connections, or remove the records,
whatever you need to do. They don’t care if it was easy or hard to do
those things, because the only thing that matters is that you can.

It is true. There’s this classic case of like, “Build a database, and
then whatever’s in the database you just throw that up on the screen
with the switches and levers that manage it”. But no real sense of, “How
does the user do a task? How do they accomplish something?”

“How many steps does it take to add a patient, and to hook them up to
the information, or to create a purchase order and send it to the next
person who has to deal with it?” It sometimes is a lot of steps to get
that work done.

Jared: So it may sound daunting, as Hagan was just
explaining, but this is what she does. And if she wasn’t successful in
making these types of products and services better, she wouldn’t have a
job.

So the question then becomes, is this something that is a complete
tear down from the beginning or are you redesigning the plane while it’s
in flight?

Hagan: The answer is it’s a little of both. I’m a big
believer in continuous improvement of software. I think, at any given
time, you should have a good list of your user’s current pain points.
What’s aggravating them in the software? Every time you do a release,
you ought to knock a couple of those off that list.

I worked with a client. We did some field studies. We watched the
users using the software. I made that list of pain points. We added the
three of them. They were doing a rollout of new features. They have all
these great new features and they were telling the customers about them.
They were very excited about them. They had been getting asked for them
so that was good. But I added these three troublesome spots that their
users were running into.

One of them, it was seven clicks to do this one thing that people did a lot.
Honestly, I don’t even remember the exact thing, but I remember it was a lot of clicks.
We fixed it. We fixed it so it was one click. It got done. You went to a screen. You did everything you need to do and it was done. I have to tell you.

When we finally showed the new version to the users, they were more
excited about that one little fix than they were about the six other new
features that they had also wanted. But that fix was something that had
been driving them bonkers. It was a pain point for them every single
time they sat down to use the software.

Jared: So it seems that addressing users’ problems as
they have them versus adding new features that they might not even use
will make the product and the experience of using it better than just
bloating it with more and more and more and more features that can
actually get in the way of the task at hand.

Hagan: I do believe you’ve got to know what the
problems are. You should never let a release go out that you don’t throw
in your own, “Here’s what we need to fix.” At the same time, there are
opportunities to make big changes. Typically, a software company might
be going to a new framework. They’re going to a new toolkit. They’ve
acquired another company. There are these times in engineering and
development that are good times for big movement.

In those times, that’s a good time to sit down and really look at the
design from a top to bottom standpoint. If you’re porting the code to a
completely new framework, that’s a great time to say, “Have we got the
right design? What do we need to change?” and to go through that
process. But that doesn’t happen very often. You have to also chip away
at it.

Jared: And here comes the importance of research. If
you want to find out what things in the product are annoying your
users, you actually need to watch those users use the product.

Hagan: I say, “Take me along on a sales call,” which
these days I don’t even physically leave the office, I just sit in on a
sales call and listen to the questions people ask. I listen in on
support calls, and I go out and I do field studies with the users.

Again, sometimes you don’t even have to leave your desk. I just do a
screen share with a user and I watch them for an hour, and occasionally I
ask them questions, and I ask them to talk aloud. It’s very
traditional, old-school stuff.

I’m a consultant, so I’m not at the company. It’s not that great to
have me doing that. It’s great, because I can help them with the design,
but I always rope in their own people and I start them in this process
of, “You have to be touching base with your users regularly, constantly,
so that you understand their pain points.”

I have yet to meet an engineer who can watch a user struggle with
something that’s broken and not want to fix it. That’s an instinct for
them. They love to fix problems.

Jared: When you get the developers, product managers,
stakeholders, and other decision makers in the room and you actually
watch these users struggle to use the product and you’re there and
you’re living their frustration along with them in real time, it’s a
really good way of getting everyone on the same page. Because no one
wants to ship a crappy product. And as Dana’s experience with the U.S.
Digital Service shows, knowing who your users are is a universal
problem.

Dana: When we started out there was no attention paid
to who the users were and what their needs were at all. The developers
would get a story that was completely out of context. They didn’t even
know what task that user might be doing. And the users were treated very
generically in addition. Internal users were this enormous category
that might actually describe any number of different kinds users. Up to
ten or twelve of them.

And so they were having to guess what needed to be done. And we were
seeing a lot of “Well what if we did this?” and “What if we did that?”
and “will this work for that thing?”

But as soon as we sent them out into the field to actually see how
the work got done, meet the users, get a chance to ask questions of them
about how they did their work and how they thought about their work, as
soon as they came back we noticed an immediate difference in the work
product they delivered. They had a much better idea of how to interpret
the requirements and to translate the stories they were working on. They
understood better, the context that any given story might be coming
from. But now they also had met human beings that they were making this
thing for and they didn’t have to guess anymore.

Jared: Time Travel. The general idea of it sounds
great. Fun and exciting. But in real life, in it’s real world
application, it’s exceedingly frustrating.

You can alleviate that frustration by watching your users use your
enterprise application. You need to exposure your team to what those
users are trying to accomplish. Then you chip away one frustration at a
time. Every frustration you chip away brings you one step closer to the
present.

The UX Immersion podcast is brought to you by the UX Immersion:
Interactions conference, which is going to be April 18-20, 2016 in San
Diego, California. That’s where Hagan Rivers is giving a full-day
workshop on simplifying complex enterprise applications.

I hand picked Hagan to be a part of this program, to teach this
workshop, for the people who have to deal with these problems every day.
If you deal with these problems every day, Go to uxi16.com to read a
complete description of Hagan’s workshop and what you’ll learn.

The UX Immersion podcast is produced by myself and Sean Carmichael.
We’d like to give special thanks to Hagan Rivers and Dana Chisnell for
being a part of this episode.

You can find more information about the UX Immersion podcast on
iTunes and at the UX Immersion: Interactions web site, uxi16.com.

You’ve been listening the UX Immersion Podcast, part of the growing
UIE Podcast Network. Thanks for listening and encouraging our behavior.

User Experience is really all about delighting your users. You want
them to accomplish tasks with ease and not encounter any roadblocks that
are a direct result of your design. Many of the delightful things about
an app or interface go unnoticed because they are the tiniest of
features. These microinteractions can set the tone for your users and
dictate the feel and performance of your design.

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.

For both seasoned professionals and infrequent travelers, booking a flight is a pain in the buttocks. Finding a flight that will meet the needs of the traveler and not cost a fortune can be taxing, even for those who do it every week.

Let’s say we’re trying to fly from Boston to Sydney. No direct flights, means we play games with a connection. Which route is best? Will we get there in time for dinner with our sister? We have an important meeting that morning at the office. Will we have to leave early? Hope this isn’t too expensive.

Hipmunk, a web site and app, tries to make the challenge of finding the best flight easier than other travel sites. And, it does a good job of it.

Hipmunk’s designers came up with a novel method for displaying available flights, using ‘swim lanes’ to put each flight up for comparison. Then they sort them by a proprietary ranking system they call Agony. This combination let’s you see the best flights quickly, by visually scanning all the details. Designing for Two Types of Challenges

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.

Suddenly, there was a collective gasp from the crowd behind me. I
knew immediately there had been a disturbance in The Force.

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.