A UX Conference Unlike Any Other Returning in 2017

Exploring the Critical Edges of Interaction Design

New practices and techniques met theory and expertise at UX Immersion: Interactions. Our 2016 event in San Diego sold out. We hope you’ll join us in 2017! (We’ll announce details in late 2016.)

Six industry leaders discussed groundbreaking interaction design skills you won’t find elsewhere. Their Featured Talks videos are available now in our All You Can Learn Library.

The Conference Blog & Podcasts

It’s Safe to Say, I Don’t Know – UX Immersion: Interactions Podcast

March 18, 2016

UX Immersion podcast

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.

Where to Stay near UX Immersion: Interactions

March 16, 2016

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:

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

A Story Told About Story Listening - UX Immersion: Interactions Podcast

February 23, 2016

UX Immersion podcast

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.

Design Sprints: An Ignition System for Innovation Project Teams

February 17, 2016

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. 

Design's Fully-Baked Deliverables and Half-Baked Artifacts

February 4, 2016

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.

Artifacts form a common understanding

Artifacts represent our current thinking about upcoming design decisions.

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

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

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

The disorientation of hunkering

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

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

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

Artifacts and deliverables each tell the story differently

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

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

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

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

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

Serving different purposes

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

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

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

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

The challenges of being clear about malleability

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

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

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

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

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

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

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

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

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

Enterprise Apps In The Field: How User Visits Become A Catalyst

January 28, 2016

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. 

Adding New Features Can Literally be a Game Changer – UX Immersion Podcast

January 22, 2016


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.

Convince Your Boss

January 16, 2016

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:

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

Proven Techniques and Best Practices for UX Designers

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

Tackle Critical UX Topics and Move Projects Forward

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

Summary of Costs

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

Item Expense
Conference fee $2,175 (through April 15)
Hotel costs $775 (for three nights)
Flight $300-600
Transportation to and from airport $15
Food $100
Total $3,165 - $3,465

Download This as a PDF

Navigation: Oh, The Places You Were Trying to Go - UX Immersion Podcast

January 5, 2016

UX Immersion podcast

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.

​Preventing the Executive Swoop and Poop with Design Sprints

January 4, 2016

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.

Jedi Designer Tricks for Exploring Multiple Variations

December 28, 2015 by Jared Spool

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.


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



Time Traveling with Enterprise Applications – UX Immersion Podcast

December 17, 2015

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.

Designing the Critical Details using Microinteractions

December 15, 2015

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.

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

 

Goal Challenges and Tool Challenges

December 7, 2015

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.

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

 

For an Edge Condition, Seeing the Problem is a Problem

December 4, 2015

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.

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