Why Is Innovation Hard at Big Companies?

I gave a keynote at Lean Startup Week 2017 in SF, early in November about some of the most common problems that large companies have implementing Lean Startup. Here's a little blog post I wrote up for the Business Talent Group blog summarizing the talk. 

If you’re responsible for launching new products, you’ve probably come across Eric Ries’s best-selling book, The Lean Startup. The Lean Startup methodology—which was created to help founders in Silicon Valley build better products—is incredibly useful for new companies and entrepreneurs who are trying to create innovative products and find product-market fit.

Over the years, however, Lean Startup has gone from something practiced by a few early adopters in very small companies to something that’s made inroads at organizations like GE, Toyota, and the federal government. And when you’re trying to introduce a big change at a large, established organization, you run into some very specific challenges.

I’ve spent years helping organizations of all sizes build new products and, in particular, create product development processes that help them continue to deliver. Here’s what I’ve learned about being an innovator at big companies—and helping them adopt the best of Lean Startup methodology. 

Read the whole post here >

Making Dashboards Useful and Usable

Products that people love and incorporate into their everyday lives tend to have two things in common: they’re both useful and usable. In other words, they’re things that people people want to use because they fill a particular need, and they’re things that people can use, because they’re not prohibitively complicated. 

Unfortunately, a lot of products fail one or both of these tests pretty badly. Either nobody wants to use them because they don’t see the value, or people try using them and give up in frustration. If you’re struggling with an analytics dashboard that isn’t getting the sort of usage you’d like, it’s worth conducting some research in order to find out if you’ve shipped something useless or unusable. Or both! 

Read more on the Logi Analytics blog >

The Right Deliverables

Once upon a time, I worked with a designer who refused to use any tool except Illustrator. Everything got made in Illustrator, whether he was building a visual design mockup, a task flow, or a discussion guide for a user research session (seriously). All of his deliverables were gorgeous.

He was also the slowest designer in history. Every single thing he did took five times as long as it would have taken anybody else, and much of it wasn’t very usable or useful. Pretty, though. 

While the visual interface, if your product has one, is an important part of the user experience, it’s not the entire user experience. And that means that the deliverables designers create to demonstrate a visual interface are not the only deliverables they need to make. 

So, if designers aren’t going to just produce pixel perfect Photoshop or Illustrator files, what sort of deliverables should they be creating? That's easy. They should make whatever they need to communicate the thing that needs to be communicated to the audience to whom they're communicating it.

Let’s get a little more specific. First, you have to understand the role that design deliverables play in the product development process. Designers, the good ones anyway, help to craft the experiences that users will have with a product, but they are rarely the ones to build the end product. Of course, there are designers who also code or build things, but even when this is true, there are typically other people on teams who also need to build things that the designer has specified. This means that the designer needs to create some set of documents or artifacts showing other people what to build.

But those aren’t the only deliverables that designers create.

In fact, designers make artifacts for three general reasons:

  • creation
  • communication
  • validation
Designers make artifacts to aid in creation, communication, and validation.          - Tweet This
Deliverables for Creation

The first type of artifact or deliverable that designers use are those that are helpful during the creation and ideation phase of design. These are tools that designers use by themselves or with small groups of people working together in order to get ideas out of their heads and into the physical world.

These sorts of deliverables might include things like sketches, ideas written on sticky notes, affinity maps, or dozens of other works in progress. In fact, many of the exercises in my upcoming book, Build Better Products (Rosenfeld Media ‘16), produce these sorts of deliverables - often bunches of sticky notes presented in some sort of framework.

These deliverables are great for communicating within a small team and making sure that everybody is talking about the same thing.

 Created by the amazing students at my Stanford Continuing Studies class!

Created by the amazing students at my Stanford Continuing Studies class!

Ideally, these are done roughly and quickly, since they’re essentially temporary and meant to facilitate a meeting or work something out in a group. In fact, they're hardly deliverables, at all. You might prefer to call them artifacts of the design process, if that's what you're into. 

When done right, these artifacts are incredibly useful to the people creating them and completely useless for communicating anything to anybody who wasn’t there when they were made.

Even when what you’re creating is a visual design, the early stages of working out that design can be done quickly with the goal of iterating through lots of ideas to find the one you want to move forward with. Many visual designers start with mood boards or collections of colors and examples of typography and imagery in order to narrow down the exact look and feel they want to achieve. Again, these don't tend to be that helpful to anybody who isn’t the designer or at least extremely familiar with the visual design process. 

That’s fine. Artifacts that help the creation process are not meant to be used for communication to other people after the fact. There are entirely different deliverables for those.

Deliverables for Communication

Designers have to communicate their ideas to other people. Frequently, they have multiple audiences for that communication. For example, they may have to communicate designs or concepts to engineers who are going to build the product. They may have to communicate new feature ideas or directions to customers in order to get feedback. They may have to present things to managers or execs within the company.

Each of these different audiences can require different types of deliverables. In fact, any given audience might require different types of deliverables depending on the purpose of the communication.

Some executives simply can’t stand seeing any designs that aren’t complete, pixel perfect, and fully interactive. Others might be fine with an early sketch or even a task flow. Depending on what the engineers are building, they might prefer a well constructed task flow and a set of detailed user stories rather than a static Photoshop mockup. At other times, they might need a detailed visual design specification.

 Task flows help you understand which screens need to exist and how a user might experience them.

Task flows help you understand which screens need to exist and how a user might experience them.

Deliverables for communication are a type of product in themselves. You need to understand who the intended audience is and what you want to communicate to them.

However, these deliverables do tend to be higher fidelity than deliverables that are only intended to help the designer create things. Because they are meant to communicate complicated ideas to people who may not have had anything to do with their creation, they have to be easier to understand than the type that are used merely to help a team think about the product together.

Deliverables for Validation

Another type of deliverable is used for validation. For example, a designer might produce a mockup or interactive prototype for the purpose of usability testing or to get feedback from a customer on a particular direction the team is thinking of going.

As with the deliverables for communication, what you produce here is going to depend on your audience. Some customers may be comfortable with low fidelity sketches or static pictures of features, but in general, these are going to be the most detailed deliverables a designer creates.

There are good reasons for this. When you’re usability testing a prototype, you can get much more realistic feedback from a prototype that behaves like the final product. If you’re trying to get feedback from a customer about a possible feature, there’s an excellent chance that the customer doesn’t have nearly as much information about the product as you do, so showing a more realistic example will help them to assess whether it’s an interesting feature.

Of course, the type of deliverable that you share here will also depends on what your goal is. Are you interested in getting usability feedback? You probably want an interactive prototype. Do you want to get customers excited about an upcoming feature? A high fidelity mockup might be better.

In general though, when sharing with outside people, avoid very high level sketches and concepts or boxes and arrows, since outsiders will have a difficult time understanding what they’re looking at.

Why On Earth Does This Matter?

Ok, that was a lot of time spent talking about things that designers make, and you may be wondering why it’s useful. It’s not just designers that create artifacts and deliverables. Everybody on your team creates them, all the time. You probably create documents, decks, spreadsheets, emails, and a dozen other types of documents every day.

Many teams have trouble communicating because they create the wrong types of artifacts for the job they’re trying to do. Thinking about what you’re trying to communicate and to whom will help you determine the correct level of specificity required from a deliverable.

Being thoughtful about this can save you a huge amount of time - both because it keeps you from creating overly detailed deliverables and because it prevents a lot of confusion that can happen when you share the wrong level of deliverable with a team member or customer.

Let me give you an example. Let’s say you’ve just had a meeting with your team where you’ve been sketching possible feature ideas on a board. Maybe you’ve gotten to the point where you all agree on a direction and even sketched some wireflows. In order to make sure that everybody remembers what you decided, you take a picture of the whiteboard and attach it to the story in your issue tracker.

 Wireflow. Illustration by the awesome Kate Rutter from Build Better Products. 

Wireflow. Illustration by the awesome Kate Rutter from Build Better Products. 

Now imagine that a new engineer has just joined the team, and they weren’t in the meeting where you had that discussion. How useful will that picture be? Or, imagine that you share it with a customer who requested a similar feature in order to get feedback. Do you expect that the customer will be able to give you any sort of useful information about what you’re sharing? Very unlikely.

On the extreme other end, let’s say that you decide that you need to make a change to your app to allow users to opt out of certain notifications, and you need to share the specifics with the engineers who will be building it. Do you really need a fully prototyped, pixel perfect version of the feature? Or would a quick task flow and a sketch showing the changes be more useful to the engineer who is implementing the change?

Instead of always creating the exact same deliverables or whatever’s easiest - photos of whiteboards, powerpoint decks, Photoshop mockups - think about the audience for the deliverable and what you’re trying to communicate. And make sure that everybody on your team does, as well.

A Deliverables Framework

When you’re deciding on what sort of deliverable to create, you need to consider the following:

  • who is your audience?
  • what are you trying to communicate?
  • what sort of action do you want them to be able to take?

Honestly, the best way to find the right deliverables with your team is to sit down with them and understand how they work, and then experiment with different levels of fidelity. If they want something with significantly more detail than you think is justified, talk to them to understand why.

Are they trying to avoid a problem they’ve had in the past? Are they uncomfortable making decisions? Are they new and lacking any of the background? Are you just really bad at judging how much direction someone might need? All of these are possible. In other words, treat your deliverables like a design problem and your coworkers or customers as the users of those deliverables.

Once you understand your user and what you want to communicate to them, you need to have a firm idea of what sort of action you’re expecting from them. Are they supposed to implement a feature? Give usability feedback? Help you flesh out a concept? Estimate the amount of work something would take? Greenlight a new project? You should always give people what they need in order to give you the sort of feedback that you want.

In other words, don’t expect people to give you usability feedback on a high level sketch. There simply isn’t enough information there to respond. On the other hand, a developer shouldn’t need a fully functional prototype with complete visual design to start working on building a feature.

Once you know who you’re communicating with and what you’d like to get back, you need to pick the right deliverable. Deliverables can come in a dizzying array of styles. Let’s look at a framework for deciding which is right for what you need to do.  

The first question you need to ask about your deliverable is whether it needs some visual component. In other words, can it be described easily in words or a story? Or does it need a conceptual model? A sketch? A full visual mockup? This depends on what it’s conveying, of course.

 Some deliverables are more visual than others.  

Some deliverables are more visual than others.  

Many things benefit from being shown visually. For example, explaining the layout of a page or the context of use for a product can be done much better with images than with words.

However, other things, like how often an email gets sent or which pricing plans to offer to different types of customers might be better shown in something like a spreadsheet or user story. When you’re communicating something, don’t just fall back on whatever you’re used to. Ask yourself, “could this be communicated better with an image or with a story?”  

If you do need something visual in your deliverables, the next question you need to ask is how high fidelity does it need to be.

 Some visual deliverables are higher fidelity than others.

Some visual deliverables are higher fidelity than others.

You should be careful here. While high fidelity visual designs can make users or team members feel more like a product is “real,” having a very finished looking prototype can get you worse feedback on your idea. When confronted with pretty, finished looking mockups, people tend to focus on the look of them rather than whether they’re useful or usable. A gorgeous demo looks like a fait accompli, and you’ll rarely get good input other than surface level visual comments.

You also need to decide how interactive your deliverable should be.

 Some deliverables are more interactive than others.

Some deliverables are more interactive than others.

Again, how interactive something needs to be depends on the sort of feedback you want. You’ll get significantly better usability feedback on an interactive prototype than you will on a sketch or a static mockup. People who can play with something that feels like a real product won’t have to imagine nearly as much as they would if they were looking at a set of user stories. That said, interactive prototypes take time to build, and sometimes you don’t need that level of feedback.

The last thing to consider when creating a deliverable of any sort is how maintainable it needs to be. Everybody forgets to take this into account, and it’s exactly the sort of thing that will cause you problems six months from now.

 There are a lot of options between a Google Doc and a Poster.

There are a lot of options between a Google Doc and a Poster.

Imagine that you’re creating a set of personas. A huge number of teams seem to think that personas should be turned into posters that can be printed out and displayed around the office. That’s fine. It can make them very high visibility.

However, imagine that three months from now you realize something that needs to change about the persona. How do you do that? You’d have to remake all the posters. That’s not terrible for things that are fairly simple and aren’t likely to change constantly. But if you’re building a product prototype for usability testing, being able to quickly and constantly make changes as the product changes and features get added will save you an enormous amount of time in the long run. If you’re building an interactive demo to show to high level execs in order to get funding for a project, on the other hand, being able to update that demo later is significantly less important.

The most important thing to remember in all of this is that deliverables, like everything else in the product development process, are not one size fits all. All the deliverables you create have a purpose and a user. Understand those before you make anything at all. 



Good Enough

I've been thinking a lot about building better products lately. After all, I'm writing a book called Build Better Products, and it'll be out this autumn, so I haven't been thinking about anything else, really. 

The hard part about building better products is often knowing what better means. This is especially true when building MVPs or first versions or experiments or whatever you want to call that thing that you put out in the world in order to see if anybody might care about it.

It's even harder, I think, for designers, since many of them seem to have some sort of belief in the idea of Good Design as its own thing. Like there's a cosmic governing panel that decides whether something is Well Designed that is independent of whether the product makes users happy or makes money for the company.

And it's a tricky balance. I'm the first one to point out that if you release an incredibly crappy product, you're not going to learn anything other than that people don't like to use crappy products. We're already pretty clear on that. They don't. On the other hand, if you spend months tweaking the fonts and obsessing over every single word or loading the product up with unnecessary features, you're very likely to waste a huge amount of time and money building things nobody wants. 

How do you choose? I really wish I had a simple system that would allow you to decide when you've hit Good Enough every single time. "Should I release now? Y/N" Maybe someday we'll get that working. Until then, how about a weird analogy? 

Let's say you're cooking dinner, and the first step is to cut up some potatoes. Now, if you do a terrible job of it and hack them up into uneven pieces, it's probably going to ruin the dish and make it inedible because half of the potatoes will be raw and half will be overcooked and mushy, and the whole thing will be awful. So, instead, you take a little time and use good knife skills and cut the potatoes better. 

Now you have to decide how much time you're going to spend on the potatoes. 

Obviously, you could make them perfect - where perfect means all exactly the same size and shape and weight or cut into animal shapes or trapezoids or whatever. Molecular gastronomists have almost certainly discovered the golden ratio of surface area to interior, and I'm sure they'd love to tell you about it.  

But the more time you spend carving your potatoes into identically sized spheres, the less time you have for cooking the rest of the meal. And, frankly, having the potatoes perfect doesn't contribute that much to the overall meal. The end result of perfect potatoes may not be noticeable to the person eating the meal, and even if they did notice, it wouldn't increase their enjoyment of the meal enough to justify the time it took you to do it. They don't want perfect potatoes at midnight. They want good potatoes at 7pm. 

Remember, your goal isn't to make a perfect potato - whatever that means. Your goal is to make dinner. Preferably a dinner that the people eating it will enjoy. 

And when you think about it, you don't even know what "perfect" means. Is it that the potatoes are all the same size? Is it that they're all the same weight? Is it that they're all exactly 20% smaller in order to improve the texture? Does it depend on the person who is going to be eating the potatoes? (note: it does! If you're cooking them for me, they should be sweet potatoes, and just go ahead and fry them, thanks.)

You don't know what "perfect" means. - Tweet This

The great thing about cutting decent potatoes that are close to the same size but not worrying about more than that is that you can get the meal on the table, have your family eat it, and then make decisions about what you want to try next time. Maybe the potatoes would be better if you cut them a little smaller. Maybe the dish needs twice as many potatoes. Maybe you decide to substitute cauliflower for potatoes like a terrible person who doesn't deserve food. Maybe the problem isn't the potatoes at all. It's the spices. They're all wrong. You didn't see that coming, did you? 

You'll have a much better idea of what "better" means once you've shipped the meal and gotten feedback about what people liked and hated and what they left on the plate and why. 

Remember, the more time you spend obsessing about the damn potatoes, the less time you spend fixing important things like the fact that you forgot to make dessert. 

This is why I say that there's nothing wrong with aiming for "good enough," especially on the first few versions of something.  Good enough doesn't mean "too crappy to learn from" and it doesn't mean we're never improving it. It means we're getting something out that is good enough to get feedback on and that we can improve over time.


Whose Job is User Research? An Interview with Adam Nemeth

For this installment of my series on good user research practices within companies, I spoke with Adam Nemeth, UX strategist at UXStrategia.net, a UX research firm based in Hungary. He shared his perspectives on how teams should think about user research and when they should get help.

Why You Should Be Doing Research Yourself

There are a lot of reasons that your team should own and run user research. Most importantly, research is deeply connected to the product. “Design is essentially a plan for a product,” Adam says. “Whoever is responsible for bringing the product on the market should be held responsible for the research about the ‘true’ underlying problem, and also the for the research which validates whether the product is truly a solution for the problem.”

Because understanding your user’s problem and finding the right solution for it are so integral to the product design process, whoever is making product decisions needs to be held responsible for the research that produces this understanding.

Of course, understanding the problem and solution are important, but they don't make up the entirety of user research. Another critical part of your product is its ease of use. “Learn usability testing,” Adam says. “For God’s sake, just do it!” He even wrote a Medium post on how to do it well, in case you don’t have any experience with it.

Why You May Need Help Doing Research

But doing your own user research may be easier said than done. There are, unfortunately, some common roadblocks that teams run into, especially when starting to conduct research without a specialist. 

“Research is easy to mess up,” Adam warns. “It’s a world full of biases.” That’s very true. It can be extremely difficult for PMs, designers, or founders to get unbiased feedback on their own work without appropriate training.

Adam explains, “A startup CEO once had a hard time believing nobody needed their wonderful product, even when it came out as an unsolicited statement from the 4th participant in a row.” Research needs to be done by somebody who can deal with the bad news. Because, as Adam says, “Research bringing only good news is usually self-deception.”

Even if you’re not actively denying bad news, some research techniques can be hard to learn and perform well. “Usability testing is easy,” Adam explains. “but learning how to do interviews and field studies properly is much more difficult. You have to watch your own posture, your tone of voice, choose your words carefully, and be open to a world you know is filtered by your own assumptions, yet you must strive to get a glimpse behind them.”

To improve, Adam recommends recording yourself, not just to listen for the answers to your questions but to hear the questions themselves. You want to hear what you’re asking, how you’re asking it, and the sorts of responses it’s eliciting so that you can improve.

Also, some research is simply harder to do. It’s not all just usability studies and guerrilla coffee shop tests. Diary studies take a long time and a lot of attention. Hard to locate participants from very specific groups can make recruiting a huge task. Sometimes you’ll need to find an external person to manage bigger research projects, just to make sure that they get the attention they need.

Finally, even if you do have a research specialist on the team, they can run into an entirely different set of problems. Sadly, user researchers within organizations aren't always believed. In-house researchers can suffer from credibility issues, through no fault of their own. Companies sometimes need to hear the same results from an outside consultant in order to really listen.

So, Who Is Responsible for Research?

“It all boils down to these three factors,” Adam explains. “Who is able to argue the best for the user against a product choice? Who is able to notice a product error? Who is responsible for the product?” Whoever that person is, they’re the one who should be responsible for research.

Whoever is responsible for it, “Understanding users should be deeply embedded in the culture,” Adam says. “When I'm working with clients, I always facilitate studies. I don't believe in handed-in reports, no one will care about them and everyone will forget them soon. But making sure every single stakeholder participated in field studies, and that we watch usability test videos together - that is an experience which brings users closer to everyone within a product team.”

In other words, it doesn’t matter if research is being done by internal resources or external consultants. We’re all responsible for being involved in the research so that we can truly understand our users.

Whose Job is User Research? An Interview with Amy Santee

Almost every time I give a talk, I get asked how people can convince their companies to adopt more user research or pay attention to the research that’s being done. I’ve always given various answers, ranging from “quit and go to a better company” to “try to make research more inclusive,” but I realized that I was giving advice based on too small of a sample set.

So, earlier this year, I became obsessed with finding out who owns user research in functional teams. I’ve asked dozens of people on all sorts of different teams what makes research work for them, and I’m sharing their responses here. If you’re someone who is very familiar with how user research works on your team and would like to participate, please contact me.

Recently, I asked Amy Santee, an independent UX research consultant, some questions about who should own research. She trained as an anthropologist, and she’s been doing user research for several years for companies ranging from healthcare to insurance to hardware and mobile tech companies, so she’s seen what works and doesn’t work in a lot of different models.

Who Owns It

“For internal teams,” Amy explains, “researchers and designers who do research should ‘own’ the research process in the sense of being the go-to people responsible for driving its fundamental activities: planning and budgets, coordination, research design, recruiting participants, conducting sessions, and disseminating the results. It’s not so much ‘owning’ it but being the point person for getting things done.”

One of the themes I’ve seen so far in these interviews is the strong difference between the responsibility for conducting research and the ownership of the results. Regardless of who is responsible for getting research done, research results and participation should be owned by the whole team. The researcher or designer might be driving the process, but everybody else on the team should be along for the ride.

It’s not just direct members of the team who need to participate, either. “Stakeholders in design, product, engineering, business, marketing and other areas should share in this ownership to the greatest degree possible,” Amy says. “That’s why they’re called stakeholders – they have (or should have) a stake in the game when it comes to incorporating research into their processes and decision-making.”

To be clear, in Amy’s model, the stakeholders aren’t just interested in the outcomes. They should be active participants in the research. They can offer important perspectives from their respective business areas, and they should contribute to the research process itself by observing sessions, brainstorming ideas and solutions, and helping to synthesize the results.

The benefits of this sort of participatory research, Amy says, are clear. “The more this is done, the more value people will see in being involved, and the less the researcher needs to ‘own’ research by him or herself. Stakeholders might even learn how to do research so they don’t always have to rely on a single person or team to do it.”

Researching without Researchers

Of course, not all teams are lucky enough to have dedicated researchers or designers who are trained in user research methods. Amy has some suggestions for those who decide to do research without any experience on the team.

“My preference is for internal researchers because they have an understanding of the company and product from the inside,” she explains. “They are able to really get a sense for how research fits into the design process and business strategy. They can build relationships with other business areas and roles in order to figure out how research can bring the most value, when to do it, who to get involved, how to communicate most effectively, and possibly make more effective recommendations.”

That said, there are reasons to bring in experts from outside. “Training from an expert who has the right background and experience can help a team get started with the fundamentals and avoid the inappropriate execution of a research project (e.g., wrong methodology, misinformed research questions, etc.),” she says.

Sometimes, combining an external expert with internal trainees can even yield certain unexpected benefits. For example, outside consultants might have a fresher look at the questions the team should be asking. They might be able to bring up things that team members wouldn’t feel comfortable saying because they don’t have a bias or agenda. And, of course, they’ll typically have experience working with many different teams, so they’ll be able to spot patterns that less experienced researchers might not see.

Whether you’re working with internal experts or external coaches, the important thing is that the people on your team are engaged in the process. Making research a collaborative effort means more people in your company will learn from users, and that’s good for your product.

Learn More

For more information about Amy, check out her website, find her on Twitter, or connect with her on LinkedIn.


Whose Job is User Research? An Interview with Steve Portigal

This post appears in full on the Rosenfeld Media blog. 

Those of us who conduct user research as part of our jobs have made pretty big gains in recent years. I watched my first usability test in 1995 then spent a good portion of the 2000s trying to convince people that talking to users was an important part of designing and building great products. These days, when I talk to companies, the questions are less aboutwhy they should do user research and more about how they can do it better. Believe me, this feels like enormous progress.

Unfortunately, you still don’t see much agreement about who owns user research within companies. Whose job is it to make sure it happens? Who incorporates the findings into designs? Who makes sure that research isn’t just ignored? And what happens when you don’t have a qualified researcher available? These are tough questions, and many companies are still grappling with them.

So, I decided to talk to some people who have been dealing with these questions for a living. For this installment of the Whose Job is User Research blog series, I spoke with Steve Portigal, Principal at Portigal Consulting. He’s the author of Interviewing Users, which is a book you should read if you ever do any research on your own.

Steve has spent many years working with clients at large and small companies to conduct user research of all types. He also spends a lot of his time helping product teams get better at conducting their own research. Because he’s a consultant, he sees how a large number of companies structure their research processes, so I asked him to give me some advice.

Read the rest at Rosenfeld Media>

Whose Job is User Research? An Interview with Dorian Freeman

As part of my ongoing series about how user research is being done in organizations, I asked Dorian Freeman, the User Experience Lead at Harvard Web Publishing to answer a few questions. She shared her experiences working in UX design since the late ‘90s. See the rest of the series here

Owning Process vs. Owning Results

When I asked Dorian who on a product team should own user research, she explained that there is a difference between owning the process and owning the results. “The people who are accountable or responsible for research are the ones who oversee the researching, the synthesizing of the data, and the reporting on the findings,” she explained. “However, the data from the research is ‘owned’ really by everyone in the company. It should be accessible to everyone.”


This is an important distinction. Regardless of who is collecting the data, the output is important to the whole company  and should be accessible and used by everybody. Research, in itself, is not particularly valuable. It’s only the application of the research to product decisions that makes it valuable. Making the results of the research available to everybody means that, hopefully, more decisions will be made based on real user needs. 

External vs. Internal

A few folks in this series have talked about the benefits of having UX research done by members of the team, but Dorian called out one very important point about external researchers. “An external expert can often provide insights that are more credible to the leadership than an internal expert, which is a perception issue, but helpful in some cases.”

And she’s absolutely right. We may not always love that it’s true, but highly paid external consultants will sometimes be listened to where an employee won’t, even when they’re saying the same things.

On the other hand, for day to day research that is informing product team decisions, an in-house expert is often preferable. Dorian says, “Typically, the in-house expert researcher has more institutional knowledge which can speed up the process and provide more insight. In the ideal scenario, the product team should always have an internal expert researcher working closely with them.”

For teams that aren’t lucky enough to have an expert, Dorian recommends getting someone on the team to learn how to do it. “Understanding the people who use your product is essential,” she says. “If you’re not interviewing users, you’re not doing UX.”

Who Does What on Product Teams?

This is a post I wrote for the Rosenfeld Media blog in preparation for the PM+UX conference. Some of the research I did will also be covered in more detail in my upcoming book, Build Better Products

When we started talking about putting on the PM + UX Conference, the first thing we asked was, “What sorts of things should we talk about?” Since the folks at Rosenfeld Media are, not surprisingly, extremely user-centered, the obvious answer was, “We’re not sure. How about we do some research and find out what questions our attendees might have?” So we did.

The most interesting thing to me was that a lot of the questions people asked boiled down to “Who does what on a product team?” This was curious. I mean, we’re all working on product teams or we’ve worked on them in the past, right? Shouldn’t we know what our jobs are? Shouldn’t we know what everybody else is doing? Well, yes! We should! And yet… when I started to dig around and have conversations with people, I got very, very different answers about how things really worked.

That was odd. It turned out that, although we all have job titles like Product Manager or UX Designer, many of us have very different ideas about what it is that we’re supposed to actually do all day. Do designers talk to customers? What about PMs? Who decides what features go into a product? Who makes wireframes? Does anybody do usability testing? If not, could they please start?

Like any good team faced with more questions than they started with, we did some more research. Ok, first we had a couple of stiff drinks. Then we did some more research. I was volunteered to lead the way.

Read the rest at Rosenfeld Media>

Whose Job is User Research? An Interview with Susan Wilhite

As part of my ongoing series where I try to find out who is doing user research in organizations and who should be, I spoke with Susan Wilhite. Susan is a lead UX researcher. She was incredibly helpful in explaining how teams work best under different conditions. This is the third post in the series. 

Strategic vs Tactical

When we talk about ownership of the research function, we have to start with the type of research we’re doing and our goals for that research. “When research is mostly tactical,” Susan explains, “it should be owned by either product management or the design team, with the other being a key stakeholder.” 

Research that is intended to answer very specific, well understood questions, should be driven by people on the team who are asking those questions. For example, usability testing and other forms of tactical, evaluative research are going to be owned and driven by the people responsible for making decisions based on the results of the studies. 

Strategic research, on the other hand, like that done when a company is still developing its primary product or service or is branching into other lines of business, should be led with broad direction and budget from the VP of product or other high level stakeholder. This puts that leader in the best position to interpret UX research findings for their peers and champion those ideas into wider strategic decisions.

Most importantly though, generative and formative research is best done in-house rather than by people outside the company. “This research, unlike evaluative, has a very long shelf life. A tiny amount of information from strategic studies are communicated in a final report,” Susan explains. "Findings developed outside the company can be a lost opportunity to grow institutional knowledge within the org over time. Down the road this is important because findings from generative and formative research inform the most tactical research.” 

In other words, don’t pay vendors to acquire deep knowledge about your users unless you intend a long-term relationship those outside researchers. Understanding the product/service and users is a critical advantage, and the understanding that comes from conducting generative and formative research should be kept close to the vest.

Cross Functional Teams vs Silos

Recently, with the growth in Agile and Lean methodologies, we’ve seen a lot of companies break down functional silos in favor of cross functional teams. This can improve communication within the product team and help diminish the waste that happens when silos only communicate through deliverables. Susan points out some of advantages and disadvantages of doing away with the research team. 

“I have become a fan of the embedded research function,” Susan says. “Researchers are themselves tools, and as such are vastly more effective when given the chance to compound learnings and develop stakeholder trust in a circumscribed domain.” When a user researcher works within a product team, they become much more effective, since they’ll have a better understanding of the team’s real research needs. They can also build trust with the team, which will hopefully lead to less resistance to suggestions made by the researcher. 

On the other hand, embedded UX research has its own problems. “The hazard here is that product groups have varying budgets and sexiness – a researcher caught in a group not advancing fast from attention given by executives or the market can hobble a career.” Having a separate research team can prevent that by allowing researchers to circulate among teams and find areas of interest and groups where they work best. But still, it takes a very well managed corporate culture for a silo to work. As Susan warns about research teams in silos, “Success is uncommon.” 

Regardless of the company org chart, Susan encourages summing up and offering evolved thinking on strategic frameworks and tactical principles throughout the company. “I’d like to see twice-yearly off-sites where the org reviews what has been learned and workshops ideas from the product team at large,” she says. “Partly to remind the team of what has been learned and how we think we know it, but also to ponder aspirational research - what’s next.”

Whose Job is User Research? An Interview with Tomer Sharon

I'm interviewing researchers, designers, product managers, and other people in tech about their opinions on how user research should be done within companies. This is the second post in the series, and it appeared in full on the Rosenfeld Media blog. 

If you'd like to be featured as part of the series, contact me

As part of my ongoing series of posts where I try to get to the bottom of who owns user research, I reached out to Tomer Sharon, former Sr. User Experience Researcher for Google Search and now Head of UX at WeWork. He also wrote a book called It’s Our Research which addresses this exact topic, and his new book Validating Product Ideas is now available. He’ll be speaking at the upcoming Product Management + User Experience from Rosenfeld Media about ways teams can work together to learn more about their users.

I asked Tomer a few questions about his recent statement that UX at WeWork won’t have a research department and what suggestions he has for creating a team that conducts research well and uses it wisely.


Read the rest at Rosenfeld Media >


Whose Job is User Research? An Interview with Jeff Gothelf

I'm interviewing researchers, designers, product managers, and other people in tech about their opinions on how user research should be done within companies. This is the first post in the series, and it appeared in full on the Rosenfeld Media blog. 

If you'd like to be featured as part of the series, contact me

While doing research for the upcoming PM+UX Conference, several respondents requested guidance around how user research should managed. In fact, it was the most common write-in answer on our survey, and a question that comes up repeatedly whenever I give talks. Apparently, there seems to be very little consensus about who on a product team should own research. This makes it a lot harder to get user insights and make good product decisions.  

In a way, this is good news. Five or ten years ago, there would have been more questions like, “How do I get my boss to consider doing user research?” and “What is user research good for?” Those still come up, but far more frequently, I’m hearing things like, “How do we make sure that everybody on the team understands the research?” and “Who is in charge of making sure research happens and deciding what to do about it?” Research, these days, is assumed. It’s just not very well managed.

To answer these questions, I interviewed several very smart people who know a thing or two about research and building products. I’ll share some of their suggestions in a series of blog posts.

First, I spoke with Jeff Gothelf, the author of Lean UX (O’Reilly, 2013) and Sense and Respond (Harvard, 2016).

Read the rest at Rosenfeld Media > 

Predictive Personas

This blog post originally appeared on the Invision blog

In theory, personas should let us better understand our real users, spread that knowledge throughout the entire company, and help everybody on the team make smarter, more human-centered product decisions.

Unfortunately, personas don’t always live up to the hype. I’ve been on plenty of teams where creating personas turned into a time-consuming exercise in design theater and produced nothing but fictional stories of imaginary people based in little-to-no research.

And posters. For some reason, everybody turns their personas into posters.

Even the best personas tend to be descriptive, but not predictive. - Tweet This

We can do better. Frankly, most teams can improve their process for creating personas in a lot of ways, but there’s one problem that’s inherent in even decently researched and constructed personas: even the best personas tend to be descriptive, but not predictive.

Why use personas?

Before I jump into how to do this, I’ll explain why it’s important that personas are predictive. The goal of good, well-researched personas should be the ability to treat the constructed personas as a proxy for the user.

This doesn’t mean that we don’t talk to users, obviously. It means we take what we’ve learned from and about users and produce something that lets us constantly check our design work to make sure it matches what we’ve learned.

Hopefully, we’re all in environments where we get to conduct sufficient user research in order to make great decisions. But even great user research needs to be analyzed and interpreted in order to draw conclusions about the majority of our users.

We don’t just interview 100 people and then start designing. We take that knowledge and condense it down into a picture of our ideal customer. Sometimes we turn it into several different people with different needs if we have different groups of customers, but producing a coherent design for many different types of users requires that we consolidate people into groups that reflect who they are and how they use our product.

Designers and researchers are great at this. They can convincingly draw a portrait of “the people who use our product,” or, in the case of new products, “the people who will use our product.” They draw a picture of a “mom in her early 30s who has 2 kids and a golden retriever and went to Santa Clara University and holds a part-time job.”

And they believe that this accurately describes their user because when they reach out to their users, they find that she often matches that sort of description.

But the question they should be asking themselves isn’t, “If I interviewed a user, would this describe her?” The question should be, “If I found a person like this, would she become a user?”

What is a predictive persona?

A predictive persona is a tool that allows you to validate whether you can accurately identify somebody who will become a customer, which is an incredibly useful thing to be able to do when you’re looking for new users or designing for current ones.

If you can create a predictive persona, it means you truly know not just what your users are like, but the exact factors that make it likely that a person will become and remain a happy customer.

Let’s look at our “mom in her early 30s who has 2 kids and a golden retriever and went to Santa Clara University and holds a part-time job.” This very clearly describes a person. You can picture this person. In fact, it’s so specific, you could almost certainly go out right now and find her.

In fact, you could probably find 10 of her.

So do it.

Based entirely on the persona your team created, go out and recruit 10 research participants who match. Most personas include, in addition to basic demographic information, some behavioral information or a description of the needs and goals of the user. Make sure those match, too.

If you think you care about what kind of car she drives or whether she only buys organic produce, control for those factors.

Whatever the profile, recruit 10 people who match it.

Remember, if you’re completely incapable of recruiting those 10 people, you’ll have a hard time finding thousands or even millions of them to be your actual users. Your persona should reflect people you can find in the wild, since you’ll need to do that in order to acquire them as users of your product. If they’re impossible to find for research, either that person doesn’t exist or they exist but you’re not the right person to try to build something for them.

Let’s say you do find them, though. The next step is to try to sell them your product. You don’t ask them if they’d use your product, since most of the time people will just smile and say yes in order to make you happy. You actually try to sell it to them—see if they’ll give you their credit card number or sign a letter of intent or start the procurement process right then and there.

Can’t recruit 10 research participants? You’ll have a hard time finding millions of users. - Tweet This

If your product is free, have them sign up for it and then monitor their account over the next few weeks to see if they continue to use the product. Do whatever you can to turn them into a customer.

If your persona really reflects the needs and goals that cause a person to want to use your product, you should be able to get your research subjects to sign up for and use your products. They should be thrilled to have found you.

I know this sounds incredibly hard, but it’s also important. If you have the perfect candidate for your product and you can’t sell something to her in person, how will you ever do it when you’re not there to give her the pitch? If hearing about all the benefits of the product from somebody who knows exactly how great it is doesn’t convince her, why do you think that a landing page or app download page or Facebook ad will?

Of course, the chances are that you don’t have the perfect candidate for your product. You have a description of some people who currently use your product, or, even worse, a description of a completely imaginary person who you think should want to use your product.

Until you can identify the specific things that make a person want to be a customer, you don’t have an accurate predictive persona. And that means your product and design decisions will be based on a lie.

That’s the beauty of personas. They allow you to answer questions like, “Would our ideal customer want this feature?” or “Is that going to solve a problem for the main persona?” If you’re basing the answers on factors that don’t really matter, your product won’t get better for real users.

Accurate predictive personas identify the things that make people want to be customers. - Tweet This

As a side note, this also works beautifully with current users and new features. Contact 10 current users and try to sell them a proposed upgrade. Show them a prototype of the upgrade and ask them to pre-order it for a small discount.

Again, you want the majority of them to take you up on the offer or you want to understand which ones do and which ones don’t, because they probably should be represented by different personas.

What to do when you’re wrong

So what do you do when you find out that none of the people you recruited want your product?

You iterate on your persona or your product. Because you’re either wrong about what makes a person use your product, or you’re wrong about what your potential users will buy. You have to change one or the other, and you have to keep doing it until you can conclusively prove that your persona isn’t just descriptive of your users, but also predictive of the type of person who will become a user.

Let me give you another example. Let’s say you decide your persona is just “moms.” And believe me, this isn’t far off from the level of some of the personas I’ve seen. So, you go out and you just recruit moms. That’s the only thing you can use.

You might get a new mom, a grandma, a mom from China, an adoptive mom, a mother of 20, a full-time working mom, and a stay-at-home mom. Additionally, all of those moms would have all sorts of other aspects that would probably affect whether they might use your product.

Is it very expensive? You may want to target more affluent moms. Is it only in English? You probably only want English speakers for now. Does it help with scheduling multiple children? You probably want moms with multiple children. And so on.

All of these factors will affect whether the “mom” will become a user. So even if every single one of your current users is a mom, they probably have several other, more important, characteristics in common.

Your job is to identify the ones that really matter so that you can say conclusively who your ideal customer really is. The best way to do that is to be able to predict ahead of time whether somebody is going to be a user.

Try predictive personas. You’ll find them difficult, frustrating, time-consuming, and possibly the best tool you can use for finding out if you really do understand exactly who your user is and why on earth she’s using your product.

For more information about ways to improve personas, listen to the podcast What is Wrong with Personas.

Three Reasons Your Visitors Don't Convert

I wrote a post about Conversion for Startup Grind. 

Let me tell you the story of far too many startups. A few people have a brilliant idea. They go off and spend six months to a year building it. Then they launch it into the world and wait for the users and money to come pouring in.

When that fails to happen roughly 100% of the time, they break down and start spending on PR. Maybe they get a mention on Techcrunch. They get featured in a few blogs. The traffic starts trickling in. The problem now, is that while they’ve got some visitors, none of those visitors are sticking around or turning into customers. Nobody is converting.
What Is Conversion?

The first problem with conversion is that the term is a little bit vague. Theoretically, it means turning a visitor into a customer. E-commerce companies use it to mean when somebody buys something. Growth Hackers use it to mean getting an email address on a landing page. Mobile developers can use it to mean getting somebody to download an app or create an account.
All of these definitions have a couple of things in common:

  • They all represent an exchange of value of some sort.

  • They’re all much harder to do than you’d think.

Read the entire post at Startup Grind! >


What You Don't Know About Growth

You shouldn’t have to be a growth hacker to care about growing your product’s user base. Understanding growth is important for Product Managers, UX Designers, and Entrepreneurs, too.

If you read about growth hacking (and I’ll admit that I do this obsessively), you’ll come across a couple of points that seem like they contradict one another:

  • There are hundreds of tricks and hacks to improve reach and growth for your product.
  • An incredibly important part of growth is building a great product that solves a serious problem for someone.

These are both true statements.

It is far, far easier to achieve sustainable, long term growth for a great product that solves problems for people than for a gimmicky product that doesn’t really work. However, even the best products can fail if you don’t pay attention to growth and use some smart tactics to get it in front of the right people. History is littered with “better” products that lost to “worse” ones.

“It’s easier to grow a great product.” — Tweet This

So, how do we combine these things and build great products that grow? The key is to pay attention to growth strategy and tactics as we build, rather than wait until we’ve launched and then spin up the marketing and PR machine or try to hire a growth hacker.

I’ve spent the last several months collecting advice from real growth experts in order to put together the top strategies and tactics that Product Managers, Entrepreneurs, and UX Designers should know about building high growth products, and I’ve put all this information into a class that I’ll be teaching on July 21st.

You should take this class if you’d like to learn more about:

  • Identifying your Ideal Customer for product/market fit
  • Acquiring the right customers from the right places
  • Measuring the customer lifecycle funnel and improving your customer’s journey through your product
  • Helping your customer get successful sooner
  • Finding the right engine of growth for your product (tip: viral sharing is not for everybody!)

This is an online, hands-on workshop. That means that you can tune in from your desk, but you’ll be expected to do some work on your own product to follow along.

If you want to learn what growth, product, and UX experts like Sean Ellis, Lincoln Murphy, Nichole Elizabeth DeMere, Dan Martell, Christina Wodtke, and Amy Jo Kim have to say about building a product that acquires, converts, and retains people quickly, you should take this class.

Sign Up Now!

Intent to Solve

I wrote an article about finding out whether prospective customers will buy your product over at Boxes and Arrows. You should read it!

"When we’re building products for people, designers often do something called “needs finding” which translates roughly into “looking for problems in users’ lives that we can solve.” But there’s a problem with this. It’s a widely held belief that, if a company can find a problem that is bad enough, people will buy a product that solves it.

That’s often true. But sometimes it isn’t. And when it isn’t true, that’s when really well designed, well intentioned products can fail to find a market."


7 User Research Myths and Mistakes

I wrote a post over at O'Reilly's Radar blog about a few of the myths and mistakes surrounding quantitative and qualitative research.

I can’t tell you how often I hear things from engineers like, “Oh, we don’t have to do user testing. We’ve got metrics.” Of course, you can almost forgive them when the designers are busy saying things like, “Why would we A/B test this new design? We know it’s better!”

In the debate over whether to use qualitative or quantitative research methods, there is plenty of wrong to go around. So, let’s look at some of the myths surrounding qualitative and quantitative research, and the most common mistakes people make when trying to use them.

Read More at O'Reilly >

Or sign up for the Webcast on March 11th, 2015 to learn about combining qualitative and quantitative research more effectively. 

Stop Accosting People in Coffee Shops - Use Guerrilla Research Wisely

Entrepreneurs, please stop accosting people in coffee shops.

I know that idiots like me have been telling you about the wonders of guerrilla user research. Some of us may even have included it in our books. Apparently, we were not clear enough about when testing something in a coffee shop is a reasonable option, since many of you have decided to do this to the exclusion of absolutely everything else.

Stop accosting people in coffee shops. Guerrilla research can hurt your product. — Tweet This

What Is Guerrilla Usability Testing?

Let’s do a very quick recap. Guerrilla Research is what we call a very specific form of usability testing. It involves, at a high level, hanging out in public places and asking people to use your product in exchange for coffee.

What’s It Good For?

Guerrilla Usability is a fast and cheap way of getting a certain type of feedback on one type of product.

It can be very effective if all of the following criteria are met:
  • you have a consumer-oriented product that does not require any specialized knowledge to use
  • you want to know if people who have never seen your product before can understand your value proposition immediately
  • you want to know if brand new users can perform a single, very specific task using your product

What Does It Suck At?

Everything else.

But Why Can’t You Use It for…?

The worst abuse of this research methodology is when entrepreneurs use it to determine whether people WANT to use their product. This is horrific on so many levels.

Getting 20 people at a random Starbucks to smile politely at you while you pitch them your idea does not constitute validation. People are generally polite, and most of them will nod encouragingly and agree that your product is probably fantastic in exchange for a $5 Frappuccino. Even if they didn’t lie just to get you to go away, they’d still be incapable of telling you whether or not they would use your product, since people are really bad at telling the future.

A major problem with trying to figure out if people will love your product based on this sort of testing is that, even if your product is aimed at “everyone” (and that’s own problem, really), it’s not necessarily aimed at the people you’ll find in any given coffee shop. And even if it’s specifically for people in coffee shops, there’s no saying whether or not those people would have found or understood or used your product on their own, if you hadn’t been standing there offering it to them.

Just trust me on this. You will never find out if people like your product by talking to strangers in coffee shops. Stop it. You’re wasting your time.

You will never find out if people like your product by talking to strangers in coffee shops. — Tweet This

Also, you won’t find out if it’s usable or useful to anybody beyond the first five minutes of usage, since that’s all the time you’re likely to have. If you have a product that is only useful with repeated usage, coffee shop testing isn’t going to help you. All you get to see is the onboarding process, so if you’re ignoring other types of longer form research (diary studies, current user observations, etc.), you’re probably going to end up with a really well tested onboarding process and a really confusing product.

Finally, if your product is designed to be used by a specific type of user, or even a general consumer in a specific type of context, you’re screwed if you’re only doing guerrilla research. For example, if your product is for accountants, it’s very likely to have loads of content that wouldn’t be at all understandable to an average person on the street. That’s ok!

Not every product needs to be perfectly understandable to every person. We don’t design airplane cockpits so that just anybody can walk in and fly a plane. It’s not a reasonable expectation. But if you’re getting feedback from non-accountants or non-pilots on your accounting software or your cockpit design, you’re going to get suggestions that will probably make the product worse for your actual users.

The same goes for context of use. Something that might seem perfectly usable in a Starbucks with decent lighting, a good wifi connection, and a flat surface might not be that great if the product is meant to be used one-handed on a crowded bus or when sprinting through an airport or while driving a car. Context can have an enormous impact on the usability of a product.

What Can You Do Instead?

I’m not actually saying you can never use coffee shop testing. It’s a reasonable tool for a very limited set of research objectives.

But branch out a bit. Figure out what you want to learn, and then do the work to understand the best method for learning that. As an added bonus, you’ll stop getting kicked out of all those coffee shops.

Like the post? Read the book. UX for Lean Startups.

Your Job Is Not to Write Code

Dear Engineers,

Your job is not to write code.

I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well.

But it’s not your job.

Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don’t always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!

Of course, if you want to do your job well, it does mean that you may have to change some of your current behaviors.

For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users’ machines.

Did you know that our users probably don’t have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked. A lot of them have Internet Explorer on 4 year old laptops, so sometimes things you build don’t work right on their machines. They’re still our users, and it’s still your job to improve the product for them, so please make sure that the code you wrote works in a reasonable number of environments.

In fact, you’re going to need to make sure that the code you wrote runs in production, in general. I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.

So, to avoid that, you need to check your changes in production. Every time. Remember, your job is not just to ship something. It’s to ship something that improves our product for our customers. You can’t know it will do that unless you check that it runs in the way it’s supposed to.

Of course, in order to check your changes in production, you’re going to need to make sure that your code actually gets merged and pushed into production. I mean, you can’t really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.

This is obviously harder to do if you’re in an environment where you can’t do continuous deployment, but the theory still holds. When your code gets into production, whenever that is, you’re still responsible for it. Make sure that it’s doing what it ought to be doing - which is make the product better for users.

Another thing to remember is that sometimes users do surprising things, which means that it’s not enough just to test that your code works under perfect conditions. You need to make sure that it does something reasonable even in error cases and zero data states and when the user does something you might not expect, like use the back button or make two accounts by mistake.

This is hard. It means you’ll have to spend time thinking about the different things our users might do. But it’s an important part of your job, because it will vastly improve the product for our users if they aren’t constantly finding bugs or edge cases or dead ends.

There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes. If you expect the code you are writing to improve user engagement (by improving the user experience in some key way), then you need to have a way to learn whether or not you succeeded. How else will you know if your job is done? Because, as I’ve mentioned, your job isn’t done until you’ve improved the product for our users.

I know what you’re thinking. This will all take so long! I’ll be so much less effective!

This isn’t true. You’ll be far more effective because you will actually be doing your job. If you get hassled for writing less code, that’s a failure of management, and I apologize for it. We need to spend less time demanding that you write features and more time asking you to improve our product for our users. If we’re not doing that, I strongly suggest you ask us to. If we still refuse, you should leave and find an environment that lets you do your job. Which, not to beat a dead horse, is to make the product better for our users.

Please don’t feel like I’m picking on you. You’re not the only one who should be doing this job. It is all of our jobs to make the product better for our users. It is my job as a PM and UX Designer and Manager to understand our users well enough that I can help you know how to improve the product for them. It is the CEO’s job to find a strategy that allows us to make money by improving the product for our users.

No matter what our job titles, our jobs are all the same — to make the product better for our users. Every day. So let’s do that.

Thank you,

Your Product Manager

Dear Engineers, your job is not to write code! - Tweet This

*This post originally appeared on Medium*

What Happens Next?

Today I’d like to talk about why that feature you’re building has taken twice as long to build as you thought it would and why it will be hard to use once you’ve shipped it. The problem is that you didn’t really think it through before you started coding.

Before I jump in, I want to point out that this is not, in fact, an argument in favor of big, up front design, or an argument against Agile or Lean. Please believe that the technique I’m sharing here can very easily be used in any sort of environment.

When you create an interaction for a product, you have to design more than what it looks like. You even have to design more than what happens during the interaction. You have to design what happens after the initial user interaction. And then you have to keep going.
Design what happens after the initial interaction. Then keep going. — Tweet This
Let’s take a look at an example. Let’s imagine that you have an e-commerce product that sells children’s books. You encourage readers to post comments and ratings. It’s a new product, so everything is very bare bones. You didn’t spend a lot of time building a huge commenting system before you knew if anybody would leave comments. Instead, you just made something very simple where people can leave a comment or read a comment. Well done! That’s very Lean of you.

Then one day, you have to have this conversation with your designer:

You: Oh my God. People are awful!

Designer: Right?

You: Someone posted an ad for penis enhancement on the Where the Wild Things Are page, and I didn’t see it until someone sent a customer support email. It could have been there for days.

Designer: We should probably have an easier way for users to flag inappropriate content than sending us an email.

You: I guess we should. Can you add flagging to the comments?

Designer: Sure!

A little while later, the designer claims he’s added flagging to the design and is ready for engineering to implement it. The design looks like this.

“Well, that’s easy,” you think. “I’m just a few minutes away from users being able to tell me when a comment is inappropriate.”

Then, of course, the design goes to the engineer. And the conversation goes like this.

Engineer: What happens when a user clicks the flag link?

You: Well, the comment gets flagged.

Engineer: Ok, I’ll set a flag in the database whenever a user flags a comment.

Hopefully you can see where this is going. The upshot is that, when a user clicks the flag link, the database will record that fact and…well…nothing else. The user who clicked the flag link won’t get any feedback. Nobody will be notified that something was flagged. You can’t do anything with the user report about the comment.

In other words, nothing has been planned beyond the visual implementation and the initial user interaction. And this is all happening because you only designed the initial user interaction.

So, what really needs to happen for this feature to be considered usable and useful? What is the minimum set of subsequent interactions that need to be designed after the user clicks on the flag link?

Probably something like this:
  • The user who flags a comment should get a confirmation that the comment was successfully flagged and be given some sort of information about what will happen next. 
  • Someone at the company should be notified in some way that a comment has been flagged. 
  • Someone at the company should be able to view the flagged comment and probably the identity of the person who flagged the comment. 
  • Someone at the company should be able to remove the flagged comment. 
  • The person who left the flagged comment should be notified that their comment was removed.
“My God!” you say. “My little, tiny feature has ballooned into an enormous undertaking! This is feature creep!”
What really needs to happen for a feature to be both usable and useful? — Tweet This
Well, no. It isn’t. You see, these are all things that would have to happen just to make the feature work at all. If you allow people to flag comments but don’t have any way for someone at your company to deal with the flagged comments, you’ve designed half a feature. Or, more to the point, you’ve designed a broken, unusable feature with a dead end.

Of course, that’s just the minimum set of things that need to be designed. There are all sorts of optional pieces like letting the flagger know when the issue is resolved or letting the flagger indicate why she’s flagging the comment or letting a customer service rep know how often people have been flagged so they can decide whether to ban the person. That last one would mean that you’d need some affordance for banning users and preventing them from returning.

Now, if you’re being very Lean Startup, you can always build the customer facing side first and decide not to build the admin side until people start flagging comments. In that case, when someone flagged a comment, you could simply have an engineer go into the database and remove the comment if you deemed it offensive.

That absolutely counts as designing a solution to the problem, by the way. It’s just a very manual design, and it’s probably one that won’t scale very well.

Why Should You Bother? 

Now you’re probably thinking that this all sounds exhausting and wondering why you would bother thinking through all of this stuff. That’s understandable. It can be exhausting. Do it anyway.

You see, thinking through the entire flow of interactions after the first one has a huge benefit to both your product and your product development process.

It helps your product by making sure you don’t have a lot of dead ends and awkward experiences. You don’t, for example, have a flagging feature that doesn’t result in flagged comments being pulled from your pages. This goes a long way toward making your overall user experience about a thousand percent better than the majority of products I use on a daily basis.

This process also improves your product development by helping you to understand the true complexity of a feature before you build it. You will never know exactly how long something will take to build, but you can certainly tell that building a flagging feature that works will take a lot longer than just putting a flag icon on each comment.

By fully exploring the complexity of features, you are better prepared to prioritize your backlog.

So, How Do You Do It? 

It’s pretty simple. Instead of thinking of your feature, think of the end user’s intent. Then, every time there’s some sort of interaction, you need to ask yourself, “has the user’s intent been satisfied?” If not, you’re not done, so you need to ask yourself, “What next?”

For example, your user isn’t going to flag something because she just loves flags. She’s going to flag something because she wants an offensive comment removed from a product page. Let’s go through the interaction sequence until that intent has been satisfied.

  1. A user can click the flag icon. Does this result in the comment being removed? No? Ok, what next?
  2. An email gets sent to someone at the company. Does this result in the comment being removed? No? Ok, what next?
  3. The person at the company asks an engineer to remove the comment from the database (which the engineer has agreed to do). Does this result in the comment being removed? Yes? Great! You’re done (for now).
Just keep asking yourself what’s next until the user’s intent has been met. It’s the best way to guarantee that your features do what you think they do and what your users expect them to do.

Like the post? Follow me on Twitter. 

Also, check out the book for more product and UX tips — UX for Lean Startups.