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.