The Power of Experience Mapping

April 5, 2017

Somewhere in the depths of Netflix, there’s a team whose primary responsibility is to make sure the bits move quickly. As Netflix serves its customers by streaming video, they ensure that video data leaves the server in a prompt and efficient manner.

This team is all about the performance of the servers and the networks. They talk in terms of bandwidth, throughput, latency, reliability, and efficiency. They are comfortably deep in the weeds of how all the data moves.

The members of this team are performance engineers. They are architecting, engineering, and maintaining the performance of a very complex system. It occupies all their time and then some. In systems engineering, there are few jobs more technical than these.

And yet, at the very moment that a Netflix viewer’s video stream stops and that spinning animation appears, indicating the player is now awaiting more data, these engineers make a dramatic change. They become user experience designers.

They made decisions about the system. Those decisions affected the bandwidth, throughput, latency, and reliability. Those decisions had a dramatic affect on that viewer’s user experience. They didn’t think of themselves as UX designers, and I’m betting no one else in the organization did either, yet, here they are, affecting the UX in a dramatic way.

When someone influences the experience of the user, they, in that moment, become a user experience designer. Their influence may not be positive. Their knowledge of UX design principles may be small, even non-existent. Yet, because they affect the experience of the user, they are a designer, albeit an unofficial one.

Unofficial Designers Are Essential For Most Organizations

Design is hard to define. We know it when we see it. (We certainly know poor design when we experience it.) Yet, describing it has been elusive.

Years ago, I stumbled upon a definition I’ve become quite fond of:

Design is the rendering of intent.

A designer has an intention to change the world in some way. Maybe they intend to help people be more productive, more delighted, more comfortable, or better entertained. When they are designing, they are making their intention real in the world. They render their intent.

Netflix’s performance engineers have a strong intent. Their goal is to ensure the viewer’s watching experience is never interrupted because the network and servers can’t keep up with the video. Every decision they make is to render that intention in their viewer’s world.

Performance engineers aren’t the only folks whose decisions influence the experience of the users. When product managers decide on features or when database developers decide on the data model, they are making decisions that affect how the design will work. Make the right decision and the design will work well for the users. Make a different decision and the design may feel clumsy and frustrating.

While organizations may have a team of designated designers, that doesn’t prevent all these other people from making design decisions. Under the guise of maintaining control, some organizations make a concerted effort to wrestle the design decisions out of the hands of these unofficial designers.

Yet, for most organizations, there are too many decisions and there are too few official designers. They can’t make every decision about performance, functionality, or database modeling. In the end, the official designers need the unofficial designers to make good design decisions on their own.

The Convolution Of Reward Systems

What seems to frustrate the official designers most is when those unofficial designers are making poor design decisions. Because the unofficial designers don’t know the ways of good design—for example, they don’t necessarily know to put the user first—the odds they’ll make the right decisions are slim.

To make things worse, the cadre of unofficial designers are often rewarded for something other than making the user happy. They are rewarded for achieving business goals, such as shipping on time, reducing costs, or for providing a list of competitive advantages.

Those amiable goals can conflict with a great user experience. Sometimes it takes longer to develop a great user experience, because you have to spend the time researching and learning what the users need. It can cost more to do all that research and iteration, instead of building the first thing to come to mind. And more features often increase the complexity of the product, thus diminishing its value to the user and raising support costs.

These unofficial designers fall into the trap that every designer falls into: they fall in love with the idea they’ve come up with. A product manager may fall in love with their idea for a new feature, because it seems cool and shiny. Not because it solves any problems the users have.

Great designers don’t fall in love with their solutions. Great designers fall in love with the users’ problems.

Usually, it’s not ego that drives them to falling in love with their ideas. It’s that they have little-to-no exposure to the problems the users have. Without exposure to users, they have no way of validating their idea. Without the data from any sort of validation, all that’s left is opinion. And there’s no way to sway an opinion in the absence of data.

The reward systems make this more convoluted. In many organizations, delivering features is rewarded more than solving customer problems. Product managers, like everyone else, naturally gravitate to what they’re rewarded for.

This means those people who set the organization’s reward systems are also influencing the design. They’ve rendered their intention on the organization, making decisions that affect the outcome of the design.

The only way we’ll get better decisions from the unofficial designers is to work to create a reward system that puts solving the customers’ problems first. And to do that, we need to bring the organization as a whole up to speed on what the customers’ problems are.

Experience Maps Help With Understanding The Problem

Since the earliest times, humankind has used maps to communicate. Maps show where we are and where we want to be. They communicate the relationships between the elements they contain.

In design, we map experiences. These maps take different forms. Customer journey maps show how our users progress through our design, often highlighting the frustrating moments alongside the delightful ones. Service blueprints describe how the organization interfaces with the customer, often revealing the invisible steps that happen for every action a customer takes. Empathy maps explore what our customers see, think, say, and feel, as they interact with our designs. And system relationship maps describe how the underlying parts of the system interact with each other to produce the users’ total experience.

It’s with maps like these that we explore the users’ problems with the unofficial designers and their reward-setting stakeholders. We can show where our customers are receiving less-than-intended quality, where our designs create frustration, and how those issues change the way people interact with our designs. We can show when customers call support (thus driving up costs), users avoid features (thus reducing value), or potential customers turn away (thus lowering sales).

Looking at someone else’s map can work. However, we’ve found a more effective approach is to have these unofficial designers and reward-setting stakeholders participate in making the maps themselves.

Map Making is Powerful

When we involve these essential influencers in the process of collecting the data and representing it on the map, they are more likely to “get it.” They see where the customer pain is coming from. They see how the decisions they’ve made have created the outcomes we’ve gotten.

It’s that act of putting pen to paper that is most powerful. To be the one who draws the point where users are frustrated makes them want to draw it elsewhere. And the way they draw it elsewhere is to change how they make decisions.

It’s simple, really. Many times we’ve seen tremendous change by just asking the highest paid stakeholder in the room to draw what we’ve learned from our research. They come away from that mapmaking experience with a strong motivation to change the map going forward.

For the first time, those unofficial designers and their reward-setting stakeholders are seeing how their decisions turn out. The stakeholders see how the rewards are pushing the organization in the wrong direction. Shared knowledge emerges and a common sense of the customers’ problems drives future thinking.

All because we gathered everyone together to make a simple map.

We’ve invited Jim Kalbach, author of the fantastic book Mapping Experiences, to teach a full-day workshop on creating different kinds of maps to engage stakeholders and unofficial designers. Join us at the UX Immersion: Interaction Conference on May 3 in Portland, where you’ll learn the techniques for effective experience mapping. See exactly what you’ll learn.

UX Metrics: Identify Trackable Footprints and Avoid the Woozles

March 21, 2017

One of my favorite childhood stories comes from A.A. Milne’s Winnie The Pooh. It’s a story in which Pooh and Piglet set out to hunt a Woozle.

At the start, Piglet comes upon Pooh wandering through the 100-Acre Woods and joins him for the stroll. Pooh shows Piglet footprints in the snow that he’s following, which he believes are the tracks of a Woozle, which he’d very much like to catch. Piglet and Pooh excitedly continue to follow the tracks.

After a short while, Piglet and Pooh notice a second set of footprints join the first. “Oh, there must be two Woozles,” Pooh deduces. They continue to follow along, only to suddenly come across a point where a third set of footprints joins the tracks. However, this set is different, so there’s a bit of discussion about it possibly being two Woozles and a Wizzle or possibly two Wizzles and a Woozle.

Eventually, the always-hero of the story, Christopher Robin, arrives to ask Pooh what he was up to, saying he’d been watching the two of them walk in circles around a big oak tree. Pooh explains about their adventure in tracking the Woozles and Wizzles, only then to realize it was his own tracks and Piglet’s that they’d been tracking all along.

Why Out-of-the-Box Analytics Aren’t Helpful for UX Metrics

As I watch teams struggling to identify key UX metrics, I sometimes think they are behaving like Pooh and Piglet as they stroll through the 100-Acre Woods. The teams are hunting for a measure (or two or three) they can use to show that the investment their organization is making into improving the user experience is paying off. Finding key UX metrics is hard and, like the elusive Woozle, difficult to capture.

Teams often start with the metrics that come out of the box. Tools like Google Analytics come with metrics that have important sounding names, like Unique Visitors, Bounce Rate, and Time on Page. However, most teams quickly realize these metrics don’t actually track anything that’s meaningful to the users’ experience.

Sure, the Bounce Rate, which supposes to measure whether someone leaves the site immediately or stays, sounds like something important about how people interact with design. (I say ‘supposes to measure’ because it only does so if the site has been correctly instrumented and that, it turns out, rarely happens.) Did the person who left the site do so because they were confused and gave up? Or was it because the site did exactly what it was supposed to and they were happily moving along in their adventure?

A high Bounce Rate might be ‘bad’ (and warrant being lowered) or the same rate might be ‘good’ (and warrant doing more of the same). We can't tell which from this number.

Bounce rate isn’t the only culprit in the out-of-the-box metrics. All of them are.

Lots of Unique Visitors are ‘good’ if they are exactly who the business wants to explore the design. Yet, if a counted visitor is a person who mistakenly clicked on an ad (and approximately 50% of mobile ads, for example, are clicked on by mistake), then the total number of Unique Visitors doesn’t mean what we think it means. An increase in Unique Visitors isn’t always a good thing.

Maybe Time On Page is a good thing, because we think it says people spent a lot of time looking around at all our good stuff? Or is Time On Page a bad thing, because we think it says people spent a lot of time being really confused about what’s on the page? By just looking at Time On Page, we don’t know if it’s better if the amount of time increases or decreases. What do we do differently?

Woozles and UX Metrics

Out-of-the-box metrics themselves are only observations. They don’t have a story that helps us understand if a better design should increase them or decrease them. Without the story, we don’t know what to do differently.

To compensate, teams use an inference. Inferences are stories we craft when direct observation doesn’t fill in what we need.

Pooh and Piglet had an observation: the tracks kept increasing. They inferred the tracks were those of a Woozle, then two, then two plus a Wizzle. There was no direct observational evidence that there were Woozles or Wizzles anywhere in the 100-Acre Woods. And without Christopher Robin’s help, they would’ve kept hunting the Woozles and Wizzles forever, to no avail.

When we say things like “Well, they left the site because our content is boring,” we’ve made an inference just like Pooh. There’s no observational evidence that our site is boring. The inference is a Woozle and by acting on it, we’ve set off on a Woozle hunt.

Hunting a Transaction Security Woozle

Years ago, when e-commerce was a very young thing indeed, we were contacted by the e-commerce manager for a major U.S. office supply chain. He was looking for any information we had about how shoppers decide if a site is safe to purchase from. Did we know any good ways to convince their shoppers that they’d implemented a secure shopping environment?

In those days, the evening news was filled with stories about people possibly getting scammed by fake internet web sites and how everyone had to be extra careful before shopping online. The manager told me they’d made a major investment in secure transaction technology, but that they were afraid users weren’t noticing and that was affecting their sales.

I asked the manager how they knew security concerns caused them to lose sales. He told me they’d seen a huge drop off in their checkout sequence when people were asked to enter their payment information. He said his entire team was convinced shoppers perceived the site wasn’t secure and were abandoning.

To make matters worse, the team had believed it was a security issue for a while and had taken expensive steps to fix it. They revamped their entire e-commerce transaction system because they’d felt it wasn’t handling SSL certificates well enough. And they paid a lot of money to several third-party trust partners to validate and verify their security.

And despite all the money and time they spent, none of these improvements seemed to reduce the drop off rates at the payment page. What could we do to help?

We told them we’d help with user research. We started our research as we often do, by watching real shoppers buy something on the site. The team had never done this before, it was an entirely new experience for them.

Acting On Observations, not Inferences

The first shopper in our study was a small business owner who, coincidentally, was in the market for a new high-end color printer. He wanted a $2,400 unit and was quite excited to see it on sale for $200 off. He was all set to make the purchase and started his way through checkout. Sure enough, he stopped when he got to the payment information page.

However, it wasn’t the security that stopped him cold. In fact, he didn’t care about the security at all. He assumed the retailer was legitimate and the site was secure.

Instead, the reason the shopper stopped was this high-end printer weighed 140 lbs. A printer that heavy would be costly to ship. And he didn’t know what the shipping costs were. There was no way he’d enter his payment information until he saw the total cost of the purchase, not just the price tag of the unit. Because he didn’t the shipping costs, he wouldn’t continue.

What the shopper didn’t know — what he couldn’t know — was that the next page would tell him the shipping costs and he could say no to the transaction if he thought it was too expensive. Nor did he realize that purchases over $25 had free shipping. (The site said it in a tiny ad-looking box on the homepage, which he never noticed because he was focused on finding his printer. It was never mentioned again.)

Turns out he wasn’t the only participant in our study to get stuck on the payment information page because they didn’t know the shipping costs. A significant portion of them did.

And sure enough, the team acted on that observation, by making it clear what purchases had free shipping and moving the shipping calculator earlier in the checkout process. From that, they saw a huge reduction in page abandonments on the credit card screen, that resulted in millions of dollars of additional sales completed on the site.

The team’s observation (users abandoning at the payment information page) had been correct. But, their inference that the site wasn’t secure enough was wrong. Thinking it was a problem of transactional security was a very expensive Woozle hunt.

Hunting a Comparison Shopping Woozle

In another e-commerce study—this time for a major clothing retailer—we were tasked with tracking down yet another Woozle. This time, the team was convinced that their product descriptions weren’t doing the job. They thought, when a shopper is in the store, seeing the product up close and try it on is important to the sale . How could the team duplicate that experience online?

The team was just days away from several signing expensive contracts with service providers who offered virtual models and other tools that promised better sales. The team wanted us to confirm that these investments would indeed provide increased sales.

We went into our study focusing on the information on the product description pages. At that time, many of us in the e-commerce world assumed online shoppers behaved like people shopping in a store, visiting each product’s page as if they were taking the item off the shelf and inspecting it for purchase. They’d only choose which product to buy after comparing several, picking the best of what they found.

The pattern we expected to see from our online shoppers was that they’d bounce from one product page to the next, carefully studying each one. And we did see some shoppers bounce from one product page to the next.

However, we also saw many purchase without bouncing. They’d go to the page that listed all the products in that category (such as all the men’s shirts) and choose the most interesting product. If that product met their needs, they’d purchase it without looking elsewhere for comparison.

They were only going to other pages when each product they visited didn’t meet their needs. The comparison wasn’t actually a comparison. It was a straight-out elimination search.

The product comparison idea was also a Woozle. When we watched shoppers actually shop, we never saw the Woozle. We saw something completely different.


Those shoppers were jumping back and forth, between product and gallery page (that’s what we call a category page, because it’s often a gallery of products). The shoppers were eliminating one product, then the next, until they found the one they wanted. We gave that up-and-down motion, between product and gallery pages, the name “pogosticking.” And the more they pogosticked, the less they seemed to find an ideal product to purchase.

We went back to the analytic data we’d collected during our study. Sure enough, we saw the pogosticking pattern there too.

66% of all purchases happened with the shopper visiting a single product page. Of the shoppers who visited more than one product page, the more pages they visited, the less likely they were to purchase at all.

What we observed, and confirmed through the analytics, was our shoppers weren’t looking to product pages to compare and subsequently decide. Instead, they had already decided while looking at the gallery page. When the product on the gallery page surfaced the details the shopper needed to decide, they were more likely to purchase an item from that page.

Hunting the product comparison Woozle wouldn’t work. Increasing the detail on the product description or implementing virtual models wasn’t what would increase the retailer’s sales. Improving the gallery pages would.

Identify Trackable Footprints and Avoid the Woozles

One great thing about pogosticking is it gives us a very clear set of footprints to track. We can classify which pages are product pages and which are gallery pages. Then we can look for instances where users jump between them. We can measure how many purchases (or, at minimum, adding the product to the shopping cart) happen with pogostick and how many happen without.

We can also break it up by category. Maybe men’s shirts has less pogosticking than women’s shoes? If so, we can study the differences and how shoppers interact with those pages. Using clear footprints as UX metrics we track gives us a way to tell when our designs are working well and when they could use improvement. They tell us if the changes we’re making are improving the design or not.

Pogosticking footprints don’t only apply for ecommerce. When a news site lists its current stories, that’s a gallery page. When a customer support site lists pages where customers get answers, that’s a gallery page too. It’s possible we could use a similar footprint to measure those pages’ effectiveness.

Not all observations turn nicely into clear footprints. For example, it would be hard to code up a trackable footprint out of people who stop shopping when they don’t know the shipping costs. It’s hard to know, from the recorded log file activity, which abandoning users cared about the shipping costs.

However, we observed that knowing the shipping costs could increase sales. We can see if a the easy-to-track footprint of people who stop shopping at the payment information page changes when we move shipping information to a better place in the checkout flow. If we think shipping cost calculation is a major cause, this number should go down when we make it easier to discover.

Trackable Footprints Come From User Observation

The best UX metrics we’ve ever found have all come from observing users. We see the users do something and ask “How often does that happen in real life?” This is how we’ve uncovered hidden treasure troves of millions of dollars in retail websites. We’ve also found under-read content on content marketing sites and under-utilized functionality in enterprise applications. We’ve found workflows that were super complicated and creating undue friction to helping the users achieve their objective.

When we’ve just drawn inferences from analytics, we end up chasing Woozles and getting nowhere. By starting with user observations and identifying footprints to build our UX metrics, we create powerful tools for measuring how our designs work.

Interested in identifying UX metrics that will help you assess how your design is performing? Kate Rutter has a fantastic full-day workshop at this year’s UX Immersion: Interactions Conference in Portland, May 1-3.

Redesigning an Enterprise App to Battle the Clutter Tax

March 9, 2017

If we keep adding functionality, we start to clutter our enterprise application’s design. That clutter can create a substantial burden on the user while obscuring the functionality we want them to use.

In this episode, Amanda Linden talks about her challenge of fighting back clutter in Asana’s design. Hagan Rivers talks about her techniques for helping enterprise app teams deal with the issues of clutter.

Hagan’s workshop Enterprise Apps: To Boldly Simplify Where Nobody Has Simplified Before on Monday, May 1 will be one of 6 daylong workshops at UX Immersion: Interactions across 3 days . Join us, and take your next step towards simplifying your application’s design.


Jared Spool: This is the UIE podcast. I’m Jared Spool.

In a corner of the UIE offices, we’ve got this old cabinet. And it’s filled with stuff that we’ve acquired from being in business for more than 28 years.
Digging through this closet is like discovering a pile of lost treasures. There’s stuff in here we didn’t even know we had.
Useful stuff, buried deep in the closet, where nobody can see it and nobody knows it’s there.

Enterprise applications can be like that cabinet. Companies keep shoving their functionality into it, until it’s cramped and so full, it’s hard to do anything useful.
And when a company focuses only on the features in their application, they’re are not focused on how their application looks. We’re not talking about whether their application is pretty or not. We’re talking about whether their user can see the features that they need.

Recently, I talked with Hagan Rivers about this. Hagan helps teams make their hard-to-use enterprise applications easier to use. I asked her about whether she sees companies prioritizing getting stuff into the product more than making the functionality easy to find.
Hagan Rivers: There's no doubt in my mind that companies, start from a list of features that they have to have in enterprise apps. They start from list of features they've got to have, and they get those in come hell or high water, and honestly, when visual design becomes a priority for them, is when some small upstart web based company comes along with a tenth of the features, or even a hundredth of the features, but it looks fantastic. Then suddenly visual design matters to them.
Jared: When there’s no competition, there’s no pressure on the company to ensure users have an easy time of it. But when a competitor arrives on the scene, that’s when they need to clean up their act. That’s when surfacing all that hidden functionality becomes important.
If there’s a competitor, then customers get choices. There’s a chance they’ll pick the application where it’s obvious how to use the functionality. The application with the stuffed cabinet approach to design? That application will falter in the face of competition.
But, let’s say it’s an internal enterprise application — something that’s only used by employees who just don’t get a choice. They have to use it.
Those employees still need that functionality and if they can’t easily get to it — if it’s hard to find because the interface is too cluttered — well, they pay a cost. More accurately, the organization pays a cost. A productivity cost. All that clutter makes it hard for the employee to get their job done.
Whether it’s the cost of lost sales to a competitor or the cost of lost productivity, the company is paying for that clutter. A clutter tax, as it were.
Asana was paying that clutter tax and it was expensive.
Amanda Linden: We had a lot of user feedback telling us that the design of our product was their largest reason for detracting or not wanting to adopt.
My name is Amanda Linden, and I'm the head of design at Asana.
Jared: Amanda came to Asana to help them eliminate their clutter tax. Before Amanda joined the team, the company had gone down the road just like Hagan said, focusing just on the features. And they had all the features users wanted. But because of the clutter, those users weren’t seeing them.
New customers couldn’t see what the project management product would do and they were not choosing to sign up for a paid plan. And existing users were only accessing a small subset of the functionality, not taking advantage of the product’s full capabilities. Asana was paying the clutter tax through low customer acquisition costs, high support costs, and poor retention rates.
To solve this, Amanda and her team started by giving the product a close look. First, they studied their application’s visual design.
Amanda: It was blue and every enterprise software product is blue. It was visually very complex. A lot of information on the page, tons of text everywhere, kind of thing.
The product looked very generically enterprisey. It wasn't differentiated from our competitors at all because so many of them are using imagery of teams and office buildings and skyscrapers. They've got the teal logo. It's all the same in enterprise land. [laughs]
Jared: And then they looked for where the important functionality was buried.
Amanda:There was all navigation in one area, but that had to do so much work.
Jared: Fortunately, the team had just shipped a mobile version of the Asana application. In that process, they learned about which functionality was essential. They used what they learned as inspiration for the redesign.
Amanda: I think that, a lot of times, right after you do a mobile version and launch that for the first time you uncover so many insights about how you can simplify the desktop or web app.
In the mobile version, you don't have the luxury of as much space. You cannot show as much on the page. A lot of times with the mobile app you start by figuring out, "What do people need to do on the go? What are the things that are going to be the most important use cases in the mobile context?"
Jared: Armed with all this design research, they decided to dive in, head first and take on the clutter tax.
Since the bulk of the problem was the hidden functionality, the Asana team started by unpacking the existing navigation. Before the redesign, everything in Asana’s application was packed tightly into a single left-hand navigation menu.
Amanda: For the redesign we ended up creating a top bar header that had some navigation so you could see, at a high level, if I need to search for anything in Asana or if I want to create anything in Asana I can do that at the top.
Jared: Creating a more exposed navigation opened up the workspace. Now there was a clean place for users to put their project lists and notes.
Opening up the workspace is a common approach to decluttering an enterprise application. If you think about it, the workspace is the true focus of the users. It’s why they’re using the application. The data is what they care about most.
Hagan Rivers argues that the workspace is the most important part of any enterprise app.
Hagan: I think the one thing that really is important in enterprise application design is to understand that the users came here to interact with the information and the data in the application. All the controls, the navigation, all those other pieces that the buttons they have to push, the toolbars, those all things they have to interact with, but they're there to see the data. A lot of these applications, you sit down with them and they're really heavy handed with the controls. The controls are taking up half the visual weight of the screen. The pixels, the colors are being taken up by paging controls. Which are just a thing there that the user has to deal with, but they're not interested in. I think you have to be really careful about putting data and information first, and still having the controls be available.
Jared: The Asana team redesigned the cluttered text controls into an open, clean canvas design. It was like writing on a blank sheet of paper. This made it much easier for users to focus on the thing they desired most.
And with the canvas now open, they tackled the next big thing: getting rid of that enterprise-blue color that permeated Asana’s design. It’s easy for teams to get endlessly distracted by color. Hagan has an approach that shifts the emphasis away from color.
Hagan: One of my favorite things to do is to start doing some visual design work and not use any color at all, and see how much we can communicate without color, just a gray scale if you will. Really push that as hard as we can, and then start to apply color to really draw the users attention to particular things. Color's really, really powerful, and we're very drawn to bright, candy colors. There's a reason candies are brightly colored. I always tell people to think of the ape in the jungle looking for fruit hanging in a tree. That's color, you want it, you want to eat it, you want to grab it. If you can use it very carefully in your design, you can create an enormous amount of pop and attraction. The only thing more attractive to users than color is motion, we have to look at things that are moving on the screen. Color is great, I like to use it really sparingly. There are some designs we've worked on where we get a heavy hand with it, but generally we start with a gray scale and we add the color in for emphasis.
Jared: The Asana team followed an approach similar to Hagan’s. They adopted a sparse color scheme that matched up with the brand refactoring, which they were doing at the same time.
Having reduced the clutter through layout and color, Amanda says the team achieved their goals of making the application feel a lot better to use.
Amanda Our product experience should feel like a clean white canvas that gives you an undistracted picture of your team's work and the clarity to make progress with ease.
Jared: And that’s what they did. It doesn’t feel like much, but by doing those simple things, they made the application feel much more inviting.
This type of redesign where you increase the space and simplify the visual elements is one that Hagan employs often with her clients.
Hagan: We've worked on screens where all we do is, increase the space, normalize the feel, and you clean it up. You come back a couple of days later and people look at it and they go "Oh this is completely different." "No, we didn’t change a thing, everything is where it was, everything works the same way but it just looks different." Well it's a completely different application like it's totally new. To them, changing it from this cramped, dense, enterprise app jammed pack with visual noise, into something that looks more like these great web apps that are out there now that have such a leaner, lighter, brighter look. It really transforms how people perceive the application.
Jared: I don’t want to minimize the Asana team’s efforts. They worked hard on this and it was an intense project. But, in the end, it was changing the look that got a whole new feel for the application. And that’s a really important outcome.
The Asana team eliminated the Clutter Tax on its users. Suddenly the users could do more.
Amanda We didn't really change the functionality of the product. We just started cleanly and simply and then let the easy things be obvious and the complex things be possible.
Hagan: Applications with more white space seem easier to use, even if nothing has changed about them, and that's just how the human brain works. We really try to work toward that a lot. We do big open white areas in the user's workspace, lots of emphasis on the data and information.
Jared: But the Asana team wasn’t done. They still had to roll out the design.
Amanda: The other unusually difficult constraint that we had was that we were not going to launch to just new users, we were going to launch to existing users as well.
People are always very scared of a redesign. It's very risky. You know you're going to make people angry. That anger is more amplified on enterprise products than it is on consumer products because you're trying to get your work done, man.
"I was just trying to run payroll," [laughs] or, "I didn't need everything to move around on me." And so,It was a real challenge that we were not going to be able to launch with new users and let existing users simmer on it and come over when they were ready.
We didn't have the ability to have one engineering team maintaining our existing product, and a new engineering team working on the new thing. We're a startup. We have really limited resources.
Jared: They’d successfully eliminated the clutter tax, but now they had another cost to deal with: switching costs. Hagan has run into this.
Hagan: I've worked with enterprise companies where they've made a bunch of interaction design changes. They've reshuffled what was on what screen, where things are located and the look. They try to roll all of that out at once. It's just too much. It's as if users had switched to a completely different application. They see a big drop of because at that point the price to switch to a completely new application is not any higher than learning this new thing.
Jared: An enterprise application incurs switching costs when a change is too sudden with too much changing at once. It can feel almost like a betrayal. All that change may be enough to push even a loyal user to evaluate other tools or products.
The Asana team worked hard to reduce those switching costs.
Amanda: I thought that the product design team and the PM team on the project did a great job of figuring out how to solve that problem, which is that they, again, decoupled the visual changes from the interaction changes and they launched the top bar, the project header, just the left nav, and then internal stuff all in the new look, AB testing each one, piece by piece.
And so, for an existing user, over the course of six months, each month the product looked slightly different, but no change was ever so drastic that it was highly problematic. And it allowed us to check in on each piece of the navigation changes independently and make sure that they were an AB test win before we rolled them out.
And then redesign was really a reskin at the end. things looked fresher and cleaner. We had amazing results of users being very excited to move on to the new product rather than resisting.
We didn't change any of the visual look and feel, but we added a top navigation bar and we moved the search and all these pieces up to the top. It still looked like it was in the old style.
And then we cleaned up the left nav, and then we added the project pane, and then we changed the content area so you're rolling out a portion at a time of the redesign all laddering up to the full effect, but still using the old style sheet.
Jared: By rolling out the new navigation a little at a time, Asana’s existing users easily adapted to the changes. In fact, they hardly noticed them. Since the color scheme stayed the same, it wasn’t a jarring change.
Once the users were completely comfortable with navigation in its new home (and now a lot easier to find), the team put the new color scheme in place. Again, this felt like a small change.
We call this embraceable change. That’s when the team makes small changes to the design over a long period of time. It helps the users adapt, and that’s important to a successful roll out. It can dramatically reduce the complaints, and more importantly, the cost of switching to a new product.
There’s an old saying that form should follow function. We need to know what the thing we’re designing needs to do before we can know what form it should take.
Yet, for enterprise applications, maybe the saying should change. Maybe it should be form dramatically lags behind function. That’s because it’s so easy to ignore form in enterprise work. After all, the users have to use what we give them, right?
But the clutter tax starts to add up. It makes it harder and harder for users to take full advantage of our products. Over time, new functionality is packed in with older functionality, making the product hard to learn and hard to use.
A successful redesign can eliminate the clutter tax, breathing new life into that functionality that had slowly disappeared and make the product feel fresh. And we can avoid heavy switching costs by bringing an embraceable change approach to the rollout, keeping those existing users who have invested in learning the application.
Suddenly, by eliminating taxes and costs, we see a return on the investment of design.
Amanda tells us that 98% of their existing users chose to move to the new design. And those upgrades to the paid subscriptions? Well, they increased by almost 10%. The team’s strategy of focusing only on Asana’s visual design worked.
They successfully decluttered their enterprise application closet. They uncovered a rich set of functionality and brought it to the surface where the users could take full advantage of its value.
This UIE podcast is brought to you by the UX Immersion: Interactions conference, which will be May 1 through 3 in beautiful Portland Oregon. That’s where our expert, Hagan Rivers, is returning to give you a full-day workshop on redesigning those complex enterprise applications.
Hagan’s workshop from last year was fantastically received. Everybody who attended loved it. They told us, after spending a day with Hagan, they were ready to tackle their toughest enterprise application redesign issues. If you are neck deep in enterprise application design, go to and read a complete description of Hagan’s workshop. Once you get to the end of it, you’re gonna want to sign up.
The UIE podcast is produced by myself and Sean Carmichael. We'd like to give special thanks to Hagan Rivers and Amanda Linden for appearing on this episode.
You can find more information about the UIE podcast on iTunes and at the UX Immersion: Interactions web site,
This podcast is part of the UIE Podcast Network. Thanks so much for listening and thanks for encouraging our behavior.

UX Immersion: Interactions Sponsorship Opportunities

February 14, 2017

Be a part of the conference experience for hundreds of designers as they sail beyond their limits in interaction design. Our three-day event included two days of master-grade full-day workshops and a day of featured talks and a keynote from our own, Jared Spool.

Below are a variety of sponsorship options for the UX Immersion: Interactions conference, May 1-3, 2017 in Portland, OR. Not seeing what you want? We’re happy to customize a sponsorship that works best for you.

1. Printed materials and marketing branding (limited to 2 sponsors)

If your main goal is for name and logo recognition, this is a great option, as you'll be part of all printed posters (and we print a lot of them). We’ll include your logo or company on each poster and attendee email template.

2. Lanyard Sponsorship (limited to 1 sponsor)

Everyone will see your company name and logo! All you have to do is send us a designated number of lanyards. We’ll give you the specs on size and color - what you put on the lanyard is up to you.

3. Printed Flyer or Give Away Handout (limited to 2 sponsors)

Everyone will receive an item or flyer with their registration materials. All you need to do is provide the item or flyers and ship them to the hotel. We’ll do the rest.

4. Exhibit Table (limited to 3 sponsors)

Get an exhibit table in the break area. You can market the table in any fashion you like and are welcome to promote give-aways and materials. Collect contact information at your table (since we are unable to share email addresses and phone numbers.)

*Your sponsorship includes additional benefits we list below.

5. Monday Night Peer Dinners (limited to 3 sponsors)

Treat a group of people to dinner on Monday evening, May 1. We organize 1-2 tables of 8 in 5-7 restaurants for attendees to meet up and have dinner with you. Sponsor as little as one table to all 14 tables. You’ll have a company representative at each table. We promote this opportunity a week before the conference along with Sunday and Monday and attendees sign up in advance. Maximum number of attendees is 112.

This sponsorship does not include any conference passes or the added sponsorship items listed below.

6. Party Sponsorship (limited to 1 sponsor)

Be the host of our Tuesday evening networking reception. We’ll load you up with a stack of drink tickets to hand out so you can meet and greet with the attendees. You’ll be everyone’s best friend.

Additionally, you’ll have a small table during the reception that you can use for demos or for a general meeting area. We’ll promote your sponsorship through out the day on Tuesday.

7. The Big Shebang (limited to 1 sponsor)

Get the best visibility and the most involvement when you participate with an exhibit table for all three days, branding sponsorship, and the party sponsorship.

*Your sponsorship includes additional benefits we list below.

*Additional sponsorship items automatically included in noted sponsorships

On Tuesday, during the conference, we'll introduce your company. Jared is great about spinning a story on why attendees should check you out, but we’ll need you to provide any key points you want Jared to say.

List of attendees - At the conclusion of the conference, you’ll receive an attendee list for those who attended the conference. The list will include names, companies, and titles.

Company handout – We’ll include a 1-page flyer from you to handout at registration on Sunday-Tuesday. We’ll need to approve the handout prior to distribution.

Should you want to send additional employees or friends to UX Immersion: Interactions, beyond the number included in sponsorship, we’ll provide you a promotion code for $300 off the current price once you become a sponsor.

Please reach out to to learn more about these and other sponsorship opportunities.

Shh! Don’t Tell Them There’s No Magic In Design Thinking

January 24, 2017

When the term Design Thinking first emerged on the scene, I found it completely puzzling. People were treating it as if it was a revolutionary new methodology to produce better products and services. They were talking about how entire companies were adopting this new approach, and those companies were becoming more competitive in the marketplace and seeing huge increases in customer satisfaction.

Now, every few years, someone touts some new approach or method that’s going to change the world. It’s part of how consultants make money. Brand an idea and sell it. Make a ton of money until the next big thing comes around. So, I’m used to these cycles by now.

Yet, Design Thinking was in my own backyard. It’s supposed to be a shift in how companies think about design, and that’s where I’ve been working for the last 37 years. I needed to find out more about what it was.

Did We Need a New Term?

It wasn’t hard to find people excited about Design Thinking. They were popping up in lots of organizations.

Yet, when I asked them what they thought it meant, their answer puzzled me. They told me it was a new approach to design, focusing on problem solving with multidisciplinary teams, producing competitive end-to-end solutions that delight customers, users, and employees.

Problem solving? Multidisciplinary teams? End-to-end solutions? Delighting users? I’d been researching and writing about integrating these elements for decades. What’s new here?

“Well, our senior managers are really excited about design thinking. Much more than any time before. That’s what’s new!” they’d tell me.

For the longest time, I didn’t get it. It seemed like we just added a new name to an old thing. Nothing was different. I thought it wouldn’t last.

But it did. Everywhere I’d go, there would be presentations where folks would talk about how they’ve introduced design thinking into their organization. (My wife and I would play this game. If we hear someone say “design thinking” in a presentation, we’d each try to be the first to say “I’M DESIGNING WITH MY THOUGHTS!”)

Why did we need another term? Design worked perfectly fine, I thought. You could take any sentence that had design thinking in it and substitute only the word design and get the same meaning. Hell, you could just use thinking most of the time and it still worked.

Fighting the “Design Means Make It Pretty” Meme

For decades, I’ve needed to do what every seasoned design professional has found themselves doing: explaining why design is more than just making something pretty. When I’ve worked with other designers, they get it.

But once someone who isn’t a designer — someone who is a layperson — is introduced into the mix, I’ve found I need to convince them that design isn’t only about making the thing pretty. That’s it’s about solving problems. That’s it’s about end-to-end solutions.

Some of the make-it-pretty meme comes from the way design is framed inside our society. TV shows, like Project Runway or This Old House, talk about design as the end stage, where the colors and decorations are added in. Go into a Home Depot or a Lowe’s and you’ll find a section of the store called the Design Center, where they sell paint and decorative knickknacks to complete your rooms. There’s no discussion of problem solving or end-to-end solutions in that world of design.

It’s important to bring design into a project early, before the team settles on a solution, so they can truly explore the needs of the users. Yet, when we would propose this, we’d get these funny looks. Why should we care about the design that early? We haven’t even figured out what we’re doing yet? They’d always push back and tell us to come back later, when it was time for design to clean things up.

That’s been the fight for decades. We’ve spent so much time trying to get the laypeople to try to think about design in a bigger definition. Yet, they always come back to the notion that design is only about making it pretty.

Design Thinking is a Reframing of Design

The phrase design thinking changed all that. To a layperson, it was completely new. While it was made up of words they thought they knew, the combination was novel. “Design thinking? What’s that?”

Adding the word ‘thinking’ to ‘design’ was a brilliant move. David Kelley and Tim Brown, the founders of IDEO who popularized the term, were smart to take advantage of the unfamiliarity of the phrase.

To those of us who’ve been doing this for a long time, design thinking doesn’t mean anything new. But it also doesn’t mean ‘make it pretty.’ And that’s why it works.

It changes the conversation. When you add ‘thinking’ to the word ‘design, it’s no longer about color or decoration. It’s now about process. It’s about getting to a more intentional outcome. It’s about thinking about the experience of the customer, user, and employee.

Design Thinking is a shortcut for a new way for non-designers to approach design. It says:

  • We’re going to do things differently from how we’ve always done it before.
  • We’re going to study problems before we jump to solutions.
  • We’re going to treat requirements as assumptions and validate them.
  • We’re going to diverge on our best ideas before picking the one that matches the solution best.
  • We’re going to map the customer’s journey to see where we’ve made a mess of things.
  • We’re going to build multiple prototypes and watch users interact with them, to learn what’s best.

In essence, Design Thinking is the integration of techniques, like Lean UX, customer journey mapping, and prototyping directly into the way the organization does business every day. It’s using the basic, proven tools of design to the maximum effect.

The customer-focused problem-solving approach to developing products and services feels magical to anyone who hasn’t been doing design for a long time. People get excited about it. And they talk about it as if it’s magical.

Magic is a wonderful thing. It helps you suspend your disbelief. “Yes, Design Thinking can finally solve all of our problems!” This reframing gives the designer the power to lower the resistance of executives providing support for solving big problems and achieving great outcomes.

Yet, with power comes responsibility.

The Traveler from Stone Soup

The magical powers that people assign to Design Thinking reminds me of an old Eastern European folk tale. The story takes place at a time when walking was the only way to travel from one village to the next (before horses were invented). In that time, it was traditional to offer visitors to your village scraps of food to replenish their hunger after such a long walk.

One traveler, upon arriving at a new town, knocked on the door of the first house he saw. However, despite the tradition, the homeowner didn’t offer any food. She explained that they were experiencing a drought and barely had enough food to feed their own family. They couldn’t spare a scrap.

Every house the traveler visited had the same story. It was a drought and there was no extra food.

When the traveler reached the center of town, he decided he needed to make something for himself. He took out his pots, started a little fire, and set up to cook himself some dinner.

He reached into his bag and pulled out a round stone. He set the stone in the bottom of the pot and started stirring. A crowd of villagers started to form.

“What are you doing?” a curious villager asked.

“I’m making Stone Soup,” the traveler responded.

“You can make a soup out of stone?” asked the villager.

“Yes, but a little water makes it better.”

“I have a little water in my well,” said another villager. He then ran off and fetched the water. The water was added to the pot and the traveler resumed his stirring.

“What will it taste like?” a villager new to the scene asked.

“Well, it would taste better with some carrots.” Upon hearing this another villager ran to his house to grab a few carrots from his garden.

Then another villager offered up some other vegetables he’d salvaged from his garden. And a woman mentioned she had some meat scraps on her pantry.

“All of it would make the soup even better,” said the traveler. Off they all went to grab what they had.

Soon the pot was filled with a lovely large stew. The traveler graciously shared his dinner with the villagers. Everybody had a grand time eating the Stone Soup.

After the festive evening, as the traveler was packing up to head on his way, he thanked everyone for helping.

“As a repayment for your kindness and generosity,” the traveler announced, “I’d like to give your village the gift of this stone. So, you can keep making soup even when you have a drought upon you.” The villagers all cheered with delight.

They thanked the traveler profusely as he made his way out of town. He continued on his way.

When the traveler was a few miles out of the town, he looked down at the road and spotted a lovely round stone. He picked it up and admired it for second. Then he dropped it into his bag and continued on his way with a smile on his face.

What Does the Traveler Think?

Design Thinking is our stone. When we apply Design Thinking, we bring the entire organization together to collaboratively solve big problems.

Yet, to me, that’s not the important lesson from the story. The lesson I take away is that, at no time during the story, do we believe that the traveler thinks the stone makes soup.

Instead, the traveler sees that the villagers need their thinking reframed. They have enough food to eat, if only they worked together. The stone isn’t magical. It’s a device.

Maybe the villagers believe the stone makes soup? Maybe a smart villager or two see what the traveler did? But at no time did the traveler himself ever believe the stone made soup. He’d starve if he did.

As design professionals, we shouldn’t let ourselves think there’s any magic in Design Thinking. Our teams, stakeholders, and executives can believe in it, but we shouldn’t. To do so would be to depend on Design Thinking having magic and such magic doesn’t really exist.

That’s the design professional’s secret. Shh! Don’t tell them!

Build out your Design Thinking toolkit with a Lean UX approach, customer journey mapping to gain across-the-organization collaboration, and design prototyping to share your vision of how your product can be better. Send your team to the full day workshops on these topics at the UX Immersion Conference, May 1–3, in Portland OR.

It’s Safe to Say, I Don’t Know

November 9, 2016

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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,


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,
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,
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.

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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,


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,
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,
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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,

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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,

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 Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,

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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,


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,
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,
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.

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 Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,

Recorded: December, 2015


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,
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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,

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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,

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 Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,


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 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,
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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,


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 in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,


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.

Join us in Portland, OR on May 1-3, 2017 for our UX Immersion: Interactions conference. For more information visit,