Wade Shearer
Front Utah
Published in
20 min readMar 20, 2016

--

We had assembled a team of some of the best designers, developers, researchers, and product managers in the industry. We sat and worked together. We watched, listened, hypothesized, prototyped, tested, iterated, and validated. Industrial designers and marketers joined us on trips across the country observing, interviewing customers, and synthesizing the results.

It was Spring 2014 at Vivint. We had more data than I have had in my entire career. We had walked through our customer's homes and listened to them talk about their lives and their families. We believed we truly understood who they were and what they needed. Our lean personas followed this journey—iterating along behind our research and tests—resulting in the strongest and most successful user facsimiles I have seen:

Meet Mark and Michelle, and their two kids, Olivia and Trevor.

Everyone on the team knew Mark and Michelle—Engineering, QA, Marketing, and even a few executives spoke about them by name. Every decision was based on the needs of this family. It wasn’t perfect, but we felt like we had almost arived in the persona promised land.

But then, it wasn’t. As much as we thought we understood who Mark and Michelle were, questions kept coming up that we didn’t have answers for and we found ourselves struggling to speak for them. Since Mark and Michelle weren’t there, could we speak on their behalf? As much as we had humanized them, we still didn’t know them. As soon as we stepped outside of the persona and our perfecly crafted user stories, we were left to reference the only thing we knew: our own experiences. We naturally looked within ourselves for context, validation, and understanding.

It was extremely difficult to move from who Mark is to what Mark does without saying, “well, I wouldn’t click there” or “that’s not obvious to me.” But, as soon as we did, someone would cut you off and say:

Yeah, but you‘re not Mark

or…

Your opinion doesn’t matter.

It’s frustrating. We want to understand. We want to relate. It’s natural. So, what’s the problem? We’re smart and experienced. Does our opinion really not matter?

You’ve heard it before. Many times. Don Norman, in his book The Design of Everyday Things, states:

Designers are not typical users.

Jakob Nielsen, the godfather of usability reminds us that:

One of usability’s most hard-earned lessons is that “you are not the user.” If you work on a development project, you’re atypical by definition.

Joshua Brewer, former Principle Designer at Twitter and co-author of 52 Weeks of UX, said:

They don’t think like you do. You know your product inside and out. You knew it when it was just a few sketches on a napkin. You have been using it in every form and iterating it has been through in its entire life-cycle. Your actions, decisions and preferences have been imprinted into every aspect of your product.

I’ve even said this. Many times.

How can you design for someone else?

For those of us that have done a lot of research, how often has the research validated that we are not the user? If you are not the user, how can you expect to design for them?

It’s been a little while, but do you remember Google Buzz? It was a social network that Google attempted to cram inside of Gmail six years ago. It was replaced one year later by Google+ and then shuttered on 15 December 2011.

It seemed like a great idea. They had 20,000 people using it. But, they were mostly employees of Google. They were special people. They were smart, skilled, and carefully selected. They live very different lives from most people outside of Google. They are indoctrinated as they are assimilated into the corporate culture. It’s a rarified environment. It was working for work but not necessarily for personal lives—the major point of a social network.

So, was it a failure? It was for the mass market certainly. The answer depends on who the intended user was.

Kellen Styler, Head of Product at Hook & Loop, a creative lab that was built inside Infor, the world’s third largest enterprise software company, provides a simple but powerful example of the importance of getting to know your user:

When we initially redesigned Infor’s UI paradigm, we emphasized the importance of negative space—more precisely, white space. Most enterprise apps are cluttered with rows upon rows of data and fields. We championed a cleaner approach—one that gave information a chance to breathe.

But soon after we deployed the new paradigm, we heard from users. They told us that while working on decade-old monitors for eight hours a day, five days a week, the white screens were starting to strain their eyes—that’s an experience we never would have replicated in our work space. We really aren’t our users.

Notice the Retina Macbook Pros in the background? The Apple Thunderbolt Displays?

How do you know what they need?

How can we possibly understand someone else sufficient enough to design products or services to satisfy their needs? Just ask them? Watch them? A myriad of research methods and tools are at our disposal: user interviews, contextual inquiry, surveys, card sorting, usability labs, A/B testing, eye-tracking, and click-stream analysis. Research is expensive and takes time, but generally people assume that if they just do it—check it off the list—then they’ll have all the answers. Yeah for us! We’re practicing lean UX! This is especially dangerous as more and more tools are becoming available that reduce the cost and time it takes to perform this work and gain insights.

I love the questions Matt Snyder, Head of User Experience at Lucid Software, asks during interviews:

Many… have become great UX designers because of their natural empathy and understanding of others; but most don’t naturally evolve on their own to that state. It takes conscious hard work, mentoring, schooling (in my opinion) and self-awareness… and an unquenchable appetite to humbly know what you don’t know. When I’m interviewing designers for my team, I often ask them what user-experience design is. If they respond, it’s usually a word salad of buzzwords that came from a popular UX blog. And when I follow up with a question like, “what does it mean to be a human being and have an experience or to go through an experience in life” — I get confused looks. And when I ask, “how are you qualified to understand the human experience?” — I get blank looks. I sometimes run across a potential UX candidate who is really brave and with some confidence will say, “I just put myself in the users shoes and will ask them what they want, then we can think like them and produce good stuff”. It’s usually at that point that I say, “And what skills do you possess that qualify you to ask, interpret and understand the experience they are having?”… and the conversation stops.

Research is good, but there are significant limitations:

  • Many unarticulated needs.
  • A substantial departure from what people say and what people actually do.
  • Unavoidable bias.

People are going to tell you what they think you want to hear. Being the subject of research is intimidating, uncomfortable, and can be emabarassing. Most people are not qualified to adequately articulate their needs anyway—even if they really understand them. And regardless of how well we are able to see into their lives, it’s impossible for us to avoid allowing our own personality and experiences from affecting our assesment.

Consider the famed experiments performed at Hawthorne Works almost a hundred years ago. This large factory complex of the Western Electric Company in Cicero, Illinois, opened in 1905 and operated for over seventy-five years. They employed 45,000 workers and produced large quantities of telephone equipment and a wide variety of consumer products. The company comissioned a psychologist and industrial researcher named Elton Mayo to study the effect higher or lower levels of light had on the productivity of workers. The results of this work were named the Hawthorne Effect by Henry A. Landsberger, another researcher involved with anaylzing the results.

Mayo found that the level of light made no difference in the productivity of workers. Whether the light was increased or decreased, the workers output went up. In fact, this effect occured when any variable was changed. It turns out that people act differently when under observation. Reasons vary from feeling important for being singled out to a desire to appease the researcher.

Interestingly, it’s not just people that are effected by observation. The Observer Effect can also be found in physics. It refers to how simply observing or measuring something can cause a change. For example, for an electron to be detected, a photon must first interact with it, inevitably changing the electron’s path. Other examples include measuring the air pressure in an automobile’s tire or using a thermometer to determine the temperature of a steak. Reading the state of the object requires you to consume some of the value and in turn reduces it’s total.

Going deeper into quantium mechanics, we learn that there’s even more to the inacruacy of measuring than just observing and consumption. Heisenberg’s Uncertainty Principle has proven that as we increase the precision in measuring one quantity, we are forced to loose precision in measuring another. So, the deeper we push into one area of research, the less clear things will become around us.

So, is there a way to learn without bias and without effecting the results? Ethnography is supposed to be the holy grail, right? This is the how you do real product research? You go deeper, you assimilate yourself into their culture, try to fit in, and become a chameleon? Ethnographers often live among the people they are studying and while it’s better than being a tourist—like studying abroad for a semester—but it’s impossible to observe without bias. It’s also very expensive, takes a lot of time, and requires a lot of resources. It’s hard to drop all assumptions and accept what you’re observing.

Is there no other way?

You must be the user

In response to Joshua Brewer’s article quoted above, Jared M. Spool writes:

Jason Fried, Ryan Singer, and the 37Signals team are pretty clear on their position: they design for themselves. They design applications they would want to use. And they design them to work the way they’d want to use them.

This shouldn’t work. If Joshua and others are right, 37Signals shouldn’t have successful products. But they do. Millions of customers love their products and rave about them to their friends. While 37Signals has their share of unhappy customers — people who find the product difficult to use or missing essential features — they have enough delighted customers to keep them quite profitable. How does this work?

He goes on to highlight Apple as another example of a company practicing what he calls “Self Design:”

Apple’s iPhone strategy has been basically the same thing. Again, Apple hasn’t conducted any traditional user research studies to get their results. Instead, the team just designed the phone they wanted to use. They pay attention to the support issues coming into their stores and support lines. And they monitor the discussions people have about frustrations and missing features. But, in the end, they design for themselves.

There are a lot of people that say a lot of things about what Apple does or doesn’t do though. Is this really true? How could the most successful and respected product design company in the world not do research?

Yes, it is true and the reason is that research should be validation, not motivation. The greatest products are born out of pain and hunger. Making money is a strong motivation, but the most successful designers and entreprenuers are those solving their own problems. Experience and a strong opinion will decimate group-think. Apple is successful because they are not a dev-shop for hire.

Phil Schiller confirmed this in his testimony during the 2012 Apple vs. Samsung trial:

We don’t use any customer surveys, focus groups, or typical things of that nature. That plays no role in the creation of the products. […] You never ask people “what features do you want in a new product?” You need to accumulate that yourself.

This approach is part of Apple’s DNA. Steve Jobs famously said:

It isn’t the consumers’ job to know what they want. It’s hard for [consumers] to tell you what they want when they’ve never seen anything remotely like it.

Basecamp and Apple aren’t alone. Joel Spolsky, cofounder of Stack Exchange and Trello, tells a story about working on a web content management system called CityDesk back in 2001. Thinking they were three weeks from shipping, Joel took the app home and tried to build a website with it.

Phew! There were a few bugs that literally made it impossible for me to proceed, so I had to fix those before I could even continue. All the testing we did, meticulously pulling down every menu and seeing if it worked right, didn’t uncover the showstoppers that made it impossible to do what the product was intended to allow. Trying to use the product, as a customer would, found these showstoppers in a minute.

So why isn’t everyone doing this? It seems so obvious in hind-sight. Interestingly, most companies start this way. Unfortunately, they quickly loose their soul to investors, boards, and profits. There are limitations but only if you’re afraid of hard work:

  • You’re atypical
  • You only have fresh eyes once
  • You must be insanely passionate about it and be able to relate
  • It requires an incredible amount of discipline
  • Requires enough customers like you
  • You must use the product a lot
  • You can miss workflows that you don’t use daily—such as on-boarding

How far are you willing to go?

We work feverishly doing research, but often only as a tourist—listening, observing, documenting. We have become better at understanding the feelings of our users, but rarely do we actually share those feelings.

You must be your user.

You must do the job.

You must have passion and empathy. You must be the user first. Empathy requires more than intellectual understanding; true empathy requires you to share a real connection with them—or better, the same experience.

The benefits are immense:

  • Speed
  • Cost savings
  • Issues with the product surface quickly with daily use
  • Because designers themselves experience it and, because they control the design, focus on eliminating it
  • Even non-frequent frustration points, such as something that might appear on initial use, surface frequently because the team is well-connected to support channels, conducting, in essence, inexpensive usability tests as they help customers walk through issues

If you work at Amazon, shouldn’t you shop at Amazon and be passionate about ecommerce? Shouldn’t Uber employees be the most active and loyal riders? What about a Slack employee that still prefers emailing coworkers? How can you design solutions for something you have never experienced and don’t believe in?

Yeah, but I can’t use our product.

Really? I bet you can. It might not be as easy as working for Dropbox or Spotify, but it’s not as hard as you think. It might make you uncomfortable and might require you spend time learning something knew, but you’ll be better for it. What if you are a designer at Hubspot? Don’t you have a Marketing Department that should be using your product? Any reason you couldn’t cross-train and spend some time working there? I’m sure they would love the help.

What if you work for Intuit and produce tax preparation software? Your company may have an accountant on-staff that files the corporate taxes, but how could you experience what it’s like to file an individual tax return for someone else? Couldn’t you work with a CPA part-time as an intern?

How far are you willing to go? You must get as close as you can.

An emotional value proposition

In Zendesk’s underground town hall auditorium last year, Blaise Bertrand, IDEO Partner and Industrial Design Director, talked about how successful product development lies in the difference between “tech push” and “tech pull.”

Many companies invent the technology, and then try to push it into the world regardless of the market or users.

Research is not about just talking to people. Fully understanding and empathizing with a user is crucial before you can begin to explore a solution. This commitment often leads their designers go to extreme length to experience problems first-hand:

How far are they willing to go? Once, an IDEO designer researching how to improve hospital visits, admitted himself into the ER and recorded the entire experience. The resulting video showed how much time patients spend looking up at boring ceiling tiles — a unique perspective you wouldn’t think of until experiencing the environment for yourself. “Experiencing it develops empathy,” Blaise explained, “which leads to innovation.”

Jon Kolko, VP Consumer Design at Blackboard and Founder of the Austin Center for Design, strongly advocates empathy over process and speed:

If you go looking for a problem, you will probably find one, and then, as a problem solver, you will work to fix it. But, if you try to build an emotional connection with a group, you’ll find that you can create products that do more than solve problems.

I don’t agree with his interpretation of Lean completely or that design process and empathy acquisition have to be slow, but his position on empathy-first design and delivering an emotional value proposition is spot on:

“Complete” implies that users can achieve their goals, but also that they experience our emotional value proposition. A value promise that supports “viable” is framed as a statement of transaction: “If you use our product, we promise you will be able to do these things.” But an emotional value proposition is framed as a statement of feeling: “If you use our product, we promise you will feel this way.”

Consider the Apple Watch. Jonny Ive started dreaming about a watch shortly after Steve Jobs passed away in 2011. He presented the idea to the design team and they became curious about what could be done on the wrist. Horology became an obsession for Ives. That obsession became a product. In the midst of a marathon push to finish iOS 7—rethinking every interaction, every animation, every function—it became clear to them that our phones are ruining our lives.

So many still don’t understand the emotional value proposition of the Apple Watch. Most are those that haven’t tried it. Kevin Lunch, the ex-Adobe CTO that Apple brought on to lead the development of this product, poetically describes it like this:

Our phones have become invasive. But what if you could engineer a reverse state of being? What if you could make a device that you wouldn’t—couldn’t—use for hours at a time? What if you could create a device that could filter out all the bullshit and instead only serve you truly important information? You could change modern life. And so after three-plus decades of building devices that grab and hold our attention—the longer the better—Apple has decided that the way forward is to fight back.

Apple hasn’t announced sales numbers yet, but conservative estimates put units sold in the millions. Most of us will never make a product that touches even half a million users. But success isn’t measured by the number of devices strapped to wrists—it’s the minutes and hours returned to the wearer’s lives. A 17-year-old high school football player in Massachusetts and a contractor in Alberta both survived heart attacks after being warned of excellerated heart rates by their Apple Watches. That’s quite an emotional value proposition.

How to avoid being a tourist and create amazing products

You must be passionate about your product

Early in my career, I was brought on as Creative Director at a startup that was building an innovative drop-shipping platform. I wasn’t interested in drop-shipping, but I got to design everything: the identity, the product, every piece of physical and digital collateral, even the office. I owned the entire brand.

But it was all wrong. In fact, I worry that I actually hindered our progress in some ways. I criticized our customers and the business model. I had plenty of passion, but it wasn’t about our product. My team created an endless supply of beautiful things, but it wasn’t our best work.

Paul Boag says it so well:

You are never going to empathize with a user you disdain or share an experience if you avoid their interests. You have to make an effort.

If you aren’t passionate about your product, stop and take a long, hard look at what you are doing. This isn’t something you can fake. It affects your team, culture, and customers. You can have passion for something you’re not innately passionate about, but only if you’re sincere and willing to understand and experience it. Start by finding something small—the results it creates or the affect it has on people perhaps—and pursue it until it lights up within you, or move on.

You must have empathy for those using your product.

Later, I had an exciting opportunity to design an application for Deseret Industries—a non-profit organization that operates a chain of thrift stores. It was an eye-opening experience. I had donated to and shopped at these stores growing up, but had somehow missed their purpose. I thought it was to sell people’s junk.

Selling used merchandise is simply a bi-product. Deseret Industries exists to help people acquire the skills necessary to be employable. Where employee turnover is a substantial cost at most companies, it’s the measure of success for this organization. The application I designed was to help managers track employees growth, goals, and job placement. This is something I could get behind. This is a cause that I found passion for. I visited stores and interviewed managers and employees. I observed them working and specifically considered their resources and environment.

But, while I was closer to success than before, I was unable to truly understand their needs because I was only observing as a tourist. Working for them wasn’t enough; I needed to work with them.

Lilla Watson, an Australian artist and activist, says this so boldly and clearly:

If you have come here to help me you are wasting your time. But if you have come because your liberation is bound up with mine, then let us work together.

You must use your product regularly

Back to Vivint. Our research was for a cutting-edge home automation and security platform that we designed, built, and launched in just over a year. It was an intense period of long days, design sprints, travel, iteration, and learning. We would test, refine our personas, adjust the prototype, and test again. Slowly, Mark and Michelle were coming more and more into focus. Twice, we scrapped the entire front-end of the product and started over. It’s hard to throw things away that you have invested so much of your life into, but it’s impossible to continue once you know that it’s wrong. Finally, we understood who they were, what they needed, and what the solution should be. We launched and it was a huge success.

This is Mark and Michelle’s home. This isn’t stock photography. We didn’t even have our in-house photographer take this shot for our persona. This is a real house. Well, almost. We built this inside of Vivint’s office. The design studio is on the other side of the wall. Imagine the clarity of being able to hold stand-up each morning in your user’s home.

But, we could have gotten there much sooner. Probably not the technology—our engineers worked miracles to pull it off as fast as they did—but certainly in terms of validating our hypothesis and designing the right solution. Years before this project started, an executive at Vivint asked if I had installed a system in my home yet. I hadn’t. Having recently built a new home, I was still getting settled and wasn’t very interested in drilling holes in the walls. Later, I was asked again, and this time had an excuse about my wife having just given birth to our fourth child and it not being a good time. Even later, the excuse was that I was still trying to decide what components I wanted.

Finally, a few months into this major project to rebuild Vivint’s entire platform, I scheduled an installation. I was now my user. I learned more the first few hours using the system in the context of real life with my family than during the previous three years of research. The revelation and clarity was shocking. I was embarrassed, but excited. I was no longer guessing. I had answers. Real answers. I was no longer sympathizing with my users—I had honest, true empathy.

The difference between testing a protype in a studio and actually using a product in the wild is dramatic. No matter how many times you tap and swipe and no matter how solid your user stories are, you can never truly understand until it’s real. Imagine the difference between testing how intuitive and accessible it is to unlock a door from your phone and actually doing it for your home… say, for your wife… while you’re talking on the phone… while you’re driving… while she’s frantic and crying… because she’s locked her keys in the car… and your kid is inside… and the only other key is locked in the house.

To quote Steve Jobs again:

The broader one’s understanding of the human experience, the better design we will have.

I’m currently at a startup called ClientSuccess where we are trying to bring relationships back into enterprise and subscription businesses. We believe that success comes from trust and authentic connections. We’re bulding a platform to help empower companies with intelligent insights and tools that they can use to manage relationships with their customers and ensure that they are engaged and getting real value out of their products.

I proudly use our product every day to run our business and manage our customers. Never in my career have I been closer to my customer. Never in my career have I felt more qualified to speak for them. Never have I had such clarity around prioritizing a roadmap. Never before have I felt more unity and focus from a team.

Everyone on your team and at your company should participate in research. Everyone should use your product. Everyone must have empathy. Even the executives. You shouldn’t have to spend time trying to convince your team of usability or product-fit issues. Why are you doing research in the first place? Just to ensure that your product is usable? There’s a difference between usable and useful. Research doesn’t mean your done. It isn’t something you check off. Research is where you begin.

In a speech given a year ago at the Whiting Writers’ Awards, acclaimed writer and philanthropist, Andrew Solomon, taught:

Your work is not opposed to your life; you do not have to choose between them. It is only by living in the world that you acquire the ability to represent it. I am addicted to artists’ residencies, to sequestering myself to concentrate, to the vision that comes in silence, to Rilke’s vaunted solitude — but not to the exclusion of the engagement that gives you things to say. Try not to let your words outstrip your experience.

You need to have enough understanding and empathy to speak on behalf of your user.

How far are you willing to go?

--

--

Wade Shearer
Front Utah

Vice President of User Experience at Workfront, Cofounder of Front www.wadeshearer.com