Improve Your Designs Using Critique

February 1, 2018

The search for the right solution to a problem evolves out of the way we think about it: How decisions are made to meet specific goals and objectives, and why we made them. With critique, designers are able to explain the thinking behind the choices they’ve made and get feedback on those choices. It can help them refocus their work in areas that fall short, and bring to light those areas that shine (and why).

When we begin by focusing on the goals, and whether the design has met them, we move the conversation away from personal opinion. Critique is a balance between reviewing what works and what doesn’t in the context of the design.

Good critique, explains designers Adam Connor and Aaron Irizarry, draws from the strengths of a given design decision to shed light on solutions for the weaker parts.

Over time, critique creates a more collaborative work environment, where teams feel comfortable discussing their designs in spontaneous and casual conversations, with less reliance on formal reviews. The practice helps teams relax into the process of giving and receiving feedback, and reaching a shared understanding of design problems to be solved.

Adam and Aaron break down the difference between critique and criticism a bit further.

When using critique, we try to:

Identify the objectives we think the creator is trying to reach. Understand those goals and objectives. Discuss the choices made to achieve goals and objectives. Review how effective design choices are in meeting their objectives. Identify strengths, potential challenges that arise from the choices made, and possibly missed opportunities.

How can you integrate critique into your design practice? Both Adam and Aaron agree that starting small and casual is the best approach. Critique can be used in standalone reviews, design reviews, and collaborative activities. They suggest that teams consider the following:

Introduce critique into your process by starting small and informal, talking about designs in an analytical way. The more you communicate, the more natural critique will become a part of your language.

Choose whom you critique with carefully and look for people who communicate well. (You’ll recognize who is less inclined toward the practice, such as some managers and executives who are generally part of larger design reviews.)

You need to start improving the conversations you have around design. To do that you’ll want to spend a day in this amazing UX Immersion: Interactions workshop with Adam Connor and Aaron Irizarry. Adam and Aaron have been discussing design critique for many years and are authors of the book Discussing Design, which is exactly why you want to learn about Consensus and Critique from them.

Improving Design With Critique

January 26, 2018

It is always easier to find the flaws than it is to offer solutions. Many of us have gotten so used to looking for the fly in the ointment that we’ve narrowed our field of vision down to identifying error over opportunity.

This is the difference between delivering criticism, and critique, creating an environment that isolates and one that fosters collaboration. Understanding that difference can improve your team’s designs, the way you work, how you communicate with each other, and how you influence the way others communicate. Often misunderstood, critique is a technique, along with tools that foster collaboration and consensus that can raise your design game.

So, what do we mean by critique and why does it matter?

If design is the rendering of intent, then critique is the open exploration and discussion of that intent and the choices made to reach the designer’s objectives. Where have those choices succeeded, why were they made, and what can we learn from them? Where have they failed, and how can we improve upon them? Critique removes the element of personal opinion from the discussion and focuses instead on objectives and the choices made to reach them.

Criticism is the act of analyzing and judging a piece of work from one’s perspective. It is a process of finding flaws and delivering often negative feedback. Constructive criticism makes an effort to convey both the strengths and the weaknesses of a work.

Critique is an analysis that begins and is grounded by the design objectives. With critique, we weigh the work against the goals and objectives to be met and explore why choices were made and how effective (or not) they are in the context of the work. It creates a dialogue that extends far beyond formal reviews and helps teams focus and reach consensus. It delivers constructive, specific feedback to move designs forward, and it helps designers grow in their craft.

You need to start improving the conversations you have around design. To do that you’ll want to spend a day in this amazing UX Immersion: Interactions workshop with Adam Connor and Aaron Irizarry. Adam and Aaron have been discussing design critique for many years and are authors of the book Discussing Design, which is exactly why you want to learn about Consensus and Critique from them.

Complex layouts are within reach with CSS

January 22, 2018

What is so phenomenal about CSS Grid is that it can do natively what developers had to achieve in the past through hacks, table layouts, and floats. CSS Modules now available—Flexbox, CSS Grid Layout, and Box Alignment—are changing layout on the web. Why? Because designers have the flexibility to create and explore layouts they were previously unable to do, and developers can realize that work natively in CSS without having to use extra markup or hacks.

With CSS Grid, we can control columns and rows. Flexbox simplifies how we lay out columns on a grid. Box Alignment allows us to apply the features of Flexbox to other layouts. It’s an exciting time for designers and developers, and as the major browsers roll out support for it in 2018, it’s time to get ready.

Join Rachel Andrew at the 2018 UXI Conference in her workshop Pushing the Boundaries of Web layout with CSS Grid and explore the possibilities of CSS grid layouts, advanced grid layouts, and design for inclusive accessibility.

Small Things Have Big Consequences

January 16, 2018

Microinteractions are tiny, task-based interactions that you barely notice when they perform well—and we’ve grown accustomed to expecting them to perform well. They are kind of like a bit of grease the keeps the flow of movement through an experience fluid and carefree. Muting your phone, updating a preference, uploading a file, connecting devices, receiving a confirmation message, liking or sharing a piece of content. These are all microinteractions. They extend to explanatory copy, such as call-to-actions, labels, form fields, menu items, the prompt within an empty state. They can include sound and visuals to convey information.

Dan Saffer coined the term “microinteractions.” These interactions are often an afterthought in the design and strategy, cobbled together with on-the-spot copy and mockups. But Dan says they are intricately tied to the way we experience a product and brand, and can influence our opinion about products. He’s outlined a four-step process to approaching how you design and develop microinteractions:

The Trigger – What starts the interaction: be it a person or a system trigger. The Rules – The rules that define what happens when the microinteraction is triggered. Feedback – How the rules of the interaction are communicated to users. Loops and Modes – The nature of the interaction: does it repeat, what happens over time?

Join Dan Saffer at the 2018 UXI Conference in his Designing the Critical Details using Microinteractions workshop and explore in detail the four steps for designing microinteractions, using feedback, setting realistic rules, and experimenting with loops and modes.

Visualize the user experience across all touch points

January 11, 2018

Teams get caught up in process. It happens. We all have work to do, and we are all fine-tuning how we do it. Without a process for examining the experiences we create, we move further away from understanding how users actually engage with our products, and where the experience falls short.

Diagrams and visual artifacts collect data in one place to illuminate problems we might not otherwise see. These maps align teams around real issues the customer is experiencing.

How do teams get started using experience maps? There is no right or wrong way to map an experience, so don’t let it hold you back before you get started. We use maps to visualize the customer journey as it happens. The map that solves the problem we are trying to identify is the one that works, explains Jim Kalbach, and it might take the shape of sticky notes, sketches, or more formal journey maps.

“The concept of mapping helps us understand complex systems of interaction, particularly when we’re dealing with abstract concepts like experience. But mapping experiences is not a singular activity limited to one type of diagram over another. There are many possible perspectives and approaches,” says Jim in his book, Mapping Experiences.

Join Jim at the 2018 UXI Conference as he explains how teams can Utilize Mapping to Gain Stakeholder Alignment, and learn the many ways you can approach experience mapping to communicate the customer experience.

Explore the User Journey Across All Channels

January 9, 2018

The larger the business, the more likely it is that departments work independent of one another, even when their goals are aligned. When we engage with our peers and clients across department silos in strategic conversations, it can be a challenge to get everyone on the same page, to say the least.

Experience maps are visualizations, and diagrams, that serve as artifacts of the customer experience. They are based on research, but don’t need to be exhaustively researched or slickly produced. Visualizing the customer experience in this way shines a light on problems that teams across silos can immediately recognize and find alignment around.

“The reality is, very often, we don’t know, companies don’t know, what their customers actually go through,” explains Jim Kalbach. “I see that time and time again and that’s part of the activity of mapping, is to shine a spotlight on that, to say, “Well, here is the real experience, slowed down, frozen in time, so we can diagnose that and actually step through it step–by–step.”

Creating experience maps takes some care and consideration, because your map can’t contain all of the information that you’ve uncovered in your research, lest you want to overwhelm everyone. It needs to offer relevant, pointed, organized information about an experience. While experience maps don’t contain answers, explains Jim, they do provide an opportunity for deep engagement that helps teams identify strategic solutions.

Join Jim at the 2018 UX Immersion: Interactions Conference as he explains how teams can Utilize Mapping to Gain Stakeholder Alignment, and learn the many ways you can approach experience mapping to communicate the customer experience.

Establish The Right Measures

January 2, 2018

When we use metrics alone to assess the value of something, we fall into the realm of making half–informed decisions based on somewhat arbitrary indicators that can hold sway over a business.

Is the high bounce rate good because the user has come and found what they needed and left? Or is it bad, because they came and left disappointed? Is time on site an indicator of a customer’s appreciation of the product and content, or a reflection of a customer’s frustration at not being able to find something (or a browser left open that timed out of the session)?

Obsessing over numbers derived from out–of–the–box analytics can pitch our process into an endless loop of trying to move numbers in a direction that can’t tell a full story, and may even lead some of us into implementing dark patterns to reach those numbers.

When the goal becomes a number, the human element, the user experience, gets lost. Designers and product leaders should combine qualitative and quantitative data to assess the performance of their product designs if they want to make better decisions.

You need to start making measurement part of your design practice. To do that you’ll want to spend a day in the amazing UX Immersion: Interactions workshop with Kate Rutter. Kate is a master at the intersection of business performance and great design, which is exactly why you want to learn about UX Metrics from her.

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

December 18, 2017

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,

UX Metrics: Identify Trackable Footprints and Avoid the Woozles

December 13, 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 Newport Beach, CA, March 5-7.

UX Immersion: Interactions Sponsorship Opportunities

December 11, 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, March 5-7, 2018 in Newport Beach, CA. 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, March 5. 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 conference 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 $200 off the current price once you become a sponsor.

Please reach out to [email protected] to learn more about these and other sponsorship opportunities.

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

December 7, 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 stakeholder alignment, new layout possibilities, and compelling visualizations 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, March 5-7, in Newport Beach, CA.