Fail fast, learn fast — not so fast

In the worlds of Lean Startup, Lean UX, and Design Thinking (DT), the prevailing wisdom tells us to build the smallest viable thing, test, evaluate, and iterate. The reason being, the more time, money, and effort you invest in the untested, the more you stand to lose. And, the more likely you are to get it wrong.

Let’s face it, until something is validated it’s just an assumption. In that way, fail fast, learn fast, just makes good sense. So what’s the problem?

In DT, for example, there are three steps to take before building. Empathize, define, and ideate. These are all intended to challenge our assumptions so we can build a better hypothesis before we build. Many are jumping straight o build and iterate, and skipping these critical steps.

When we begin with a wild guess rather than an informed hypothesis we’re more likely to fail big and learn little.

Not all failure is equal

We need to get real clear on the fact that not all failures are equal in scale or their ability to provide learnings. Failure is not an absolute condition. Failure spans a scale from insignificant to catastrophic.

The Big Bang Theory: Gradations of Wrong – YouTube

It is a little wrong to say a tomato is a vegetable, it is very wrong to say it is a suspension bridge. – Stuart to Sheldon on The Big Bang Theory

Unless you’re building a suspension bridge or other thing that has the real potential for life and death, most of your mistakes will never reach the catastrophic end of the scale. That said, when it comes to learning from our mistakes, the bigger they are, the harder it is to learn from them.

The reason it’s so hard to learn from bigger failures is due to the number of variables that may have played a role. Did we target the wrong audience? Did we test the wrong features? Were there too many feature, or too few? Were we addressing the right problem? How do we know?

The more variables at play, the more chances we have to focus on the wrong one. These larger failures are most often due to beginning with an uninformed assumption rather than an informed hypothesis.

Before we build a prototype to test, and before we can build an informed hypothesis, we need to test our assumptions. As a traffic court judge once said to me, “When you assume, you make an Ass of U and Me.”

Testing assumptions is the least expensive and most impactful step in failing fast, learning fast. Ask yourself, and your team, questions like:

  • How do we know our assuptions are right?
  • What data supports that assumption?
  • What data contradicts the assumption?

Anyone in science or math knows that no matter how right your answer is, if you start with the wrong assumption, the answer is wrong. Make no mistake, creating a great user experience is a science. For example, BetaMax lost to VHS because it assumed that image quality was more important than the length of the recording. (Sorry if you’re not old enough to remember BetaMax and VHS recorders)

Validate your assumptions by doing Kano analysis, conducting some user interviews, and running surveys. You can often get insights in as little as a few hours or a few days. Use these findings to write jobs-to-be-done (JTBD) stories to help you build an informed prototype for testing. It’s always less expensive to test assumptions than prototypes.

Build a better hypothesis before you build anything else

The quality of our questions determines the quality of our life. – Tony Robbins

It doesn’t matter how we answer the questions above. It only matters how our target audience answers them. It’s easy to believe we figured things out. The unfortunate truth is that or brain is wired to make this happen.

  1. Our brain is a pattern recognition machine. It excels at this. It’s excellent at this. But there’s a problem.
  2. Our brain likes to confirm what it knows. It’s called the confirmation bias. We all have, suffer from, it. It’s how it build patterns. We see what we want to see.

Have you ever thought of something and the suddenly everything seems to say you’re right? If you think a certain design pattern is bad, you suddenly find dozens of articles that agree with you. They tell you how they tested the pattern, and sure enough, it doesn’t work. Ever happen to you? Of course it has. It’s happened to all of us. Why?

You likely did a search to find out if others felt the same way. You may have used a search phrase like “Is {design pattern] bad?” or “How bad is {design pattern}?” Google, unsurprisingly, returns thousands of articles about how bad it is. What would have happened if instead you used a search phrase like, “Does {design pattern} work?” or even better, “How well does {design pattern} work?” Guaranteed, you get different results. Try it.

When we know the answer we want, it’s easy to ask the questions that get us that answer. Everyone wants to believe they know the answer, so they set out to find evidence that supports their position. It’s rare that people go out of their way to prove themselves wrong. And that’s also a problem.

Don’t skip user research and jump straight to building something to test. Part of the reason fail fast is possible, is because you’ll always get it wrong the first time. The question is, how wrong? A little, or a lot, or even catastrophic? Up front research can help you build a better hypothesis before you begin building a solution. Talk to your audience first. Ask them about your ideas.

Henry Ford and Steve Jobs were mostly wrong

People are quick to jump on quotes of Ford (still openly debated) and Jobs to support their position that people don’t know what they want or need, so why bother to ask them.

If I asked people what they wanted, they’d say faster horses. – Henry Ford (debatably)

A lot of times, people don’t know what they want until you show it to them. — Steve Jobs.

This is another case of a little wrong or a lot. Jobs is a little wrong. You can ask questions of people and get insightful answers. but, you do have to ask the right questions the right way to make sure you aren’t playing to your confirmation bias.

Ford on the other hand was a lot wrong. There’s at least one clear insight in the answer he anticipated. People needed to get from one place to another faster. Now, it’s up to the innovator to figure out how that happens.

In both cases, these legendary innovator were wrong to think that people don’t what they want or need. For many, there was desire to connect with others faster, from more places, more often, and in more ways. Viola, the iPhone. People needed to get places faster, not have to shovel horse manure, or get rained on while doing so. Viola, the automobile.

Would the average person have conceived of those specific solutions? Unlikely. Do you always need to build something before you know if the need exists? Maybe, but not always. Ask before you build. Reduce the risk of wasted effort. Reduce the size of the failure. In the process you will improve your ability to get insight from you failures. Insights that you can act upon. Insights that increase your chances of success.

I hope you’ll adopt a new mantra. Fail better, learn better.

Web forms that don’t suck

Responsive, accessible, mobile-first, and progressively enhanced forms

Web forms can be tricky business. Luckily there are some really smart guys out there keen to solve the challenges associated with doing web forms well. Making forms easy to fill out on touch device, making them easy to navigate for people using assistive devices, making them easy to visually scan, and making the look clean on any device is tall order to fill. Wish I could say I had the brains to figure this all out on my own but that just wouldn’t be true.

A little while back I ran across a great presentation by Aaron Gustafson on accessible, mobile-friendly forms entitled Falling in Love With Forms. He provided a lot of great information on how make forms not suck. Here is a series of form elements inspired by this presentation.

See the Pen Accessible, responsive, mobile-first forms by Mike Donahue (@mdonahue37) on CodePen.

More recently I came across an article on entitled Why Infield Top Aligned Form Labels are Quickest to Scan that looked at the usability different form styles. They found that including in-field labels (not in the input element) top, left aligned were faster to scan and reduced visual noise. This codepen is based on those findings.

See the Pen More responsive, accessible, mobile first forms by Mike Donahue (@mdonahue37) on CodePen.

This is proof of concept and I’ve no doubt there are several other ways to handle this. There are few kinks I”ve yet to smooth out, if you see them and have some advice let me know. What are your thoughts or best practices on web forms in todays multi-device reality?

6 Reasons No One Needs a Fold Manifesto

This is an article I posted on LinkedIn. If you read “The Fold Manifesto” by Amy Schade of the Nielsen Norman Group (NN/g) and it has you convinced “the fold” is major design challenge, read this before you do anything rash like add a carousel to your homepage. Save yourself from worrying about one of the least important aspects of web design so you can focus on what truly matters – compelling, structured, well-organized, prioritized content.

Feeling Your Consumer: What Marketers Are Missing About Making Emotional Connections

In Feeling Your Consumer: What Marketers Are Missing About Making Emotional Connections, Douglas Van Praet offers some great insight into the connection between our emotion and motor systems based on research. This is great read for anyone that is truly concerned with successful marketing. It offers even more evidence that it is our emotions that drive action and not logic.

Big Data Only Tells Half the Story, If You’re Lucky.

We’re living in a world where our devices are tracking our every move. Google, Yahoo, Amazon, eBay, Facebook, Pinterest, Twitter and countless other services are collecting crazy amounts of data on us. All this information is analyzed to uncover patterns of behavior so they and those they share their information with can better target us at every turn.

Many articles and books have been written that offer advice on how to improve an experience through design changes based on this big data. In fact an entire industry, Conversion Rate Optimization (CRO), has sprung up around the idea that big data can improve site performance. Can big data (quantitative data) alone be enough to realize the full potential of any experience? Can we forego in-person user research (qualitative data) now that we have so much data on WHAT users are doing? No.

Continue reading Big Data Only Tells Half the Story, If You’re Lucky.

Win User Loyalty by Targeting Logic AND Emotions at UXPA London 2014

Presenting at UXPA London 2014 BadgeI’m happy to announce I will be presenting an updated version of the Emotional Strategy for Balanced UX Design at the upcoming UXPA International Conference in London, July 22, 2014.

Win User Loyalty by Targeting Logic AND Emotions looks at why emotions are such an important factor to consider at every stage of design. It also explains when, where, and how to use emotions by looking at The 4 Stages of Accomplishing Goals. The 4 Stages explains HOW we experience everything.

After the conference I will post up the slide deck to Slideshare and hopefully I’ll have link to a video recording of the session to share as well. Hope to see you in London.