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.


Making More UX Designers

Over the last few years, I’ve had an increasing number of people ask the same two questions. Specifically I get asked:
Where can I find a good UX designer?
How can I get into UX?

The best possible solution is, of course, to teach the people in the second group how to do the job and then introduce them to the people in the first group. The second best solution is to teach the people in the first group to do it for themselves. I’ve been experimenting lately with both of these approaches. 

This need for creating more UX designers is one of the biggest reasons I joined Tradecraft as an instructor at the beginning of the year. My co-teacher, the amazing Kate Rutter, and I each spend 3 days a week working with smart, motivated, tech-savvy students, teaching them UX design fundamentals like user research, task flows, personas, wireframing, and prototyping. Most importantly, we teach them to think like UX designers. 

Because it’s an intensive 12 week program, students have time to learn UX skills and apply them on real projects for real companies. They also learn from frequent guest mentors and speakers. 

It’s a competitive program. We don’t take many students. We’re not interested in churning out a lot of mediocre designers. We want to take a few people each quarter and turn them into great designers whom we’d be happy to recommend for jobs. We prefer people who have experience in some area of design, product management, user research, or engineering. 

So, if you’re someone who desperately wants to become a UX designer, and you want hands-on coaching from a couple of people who’ve been doing this for quite a few years, you should apply to Tradecraft for the next quarter. Or, if you’re a manager at a larger company, and you have a promising UX designer or Product Manager who needs some serious coaching to get to the next level, you should consider sponsoring that employee in the program. Lastly, if you’re looking for a newly minted UX designer, we’ve got a few of those graduating at the end of March. 

And if you want more information about any of it, you should email me at laura@usersknow.com and ask.

By the way, Tradecraft also has programs for people who want to be Growth Hackers and Sales People.



Lean UX Videos

Recently, I've been experimenting with new ways of delivering information about UX for Lean Startups. Yes, this is a very poor excuse for not blogging as much. But it's also a genuine effort to get information about user experience design to new people.

As part of this effort, I'm making a series of short (10 minutes or so) videos for UXD for Developers. This is a show on YouTube produced by the folks at the Android Developer Network at Google.

Two of my videos are already posted, and at least one more is on the way. A list of all the videos (including some that I'm not in) is here: UXD for Developers.

In my episodes, I cover an Intro to Lean UX and Qualitative vs. Quantitative Research for UX.

New episodes are released every Tuesday, so make sure to subscribe to the channel to get all the updates!


How Bad Can I Make My Product?

Imagine that I have a product that cures cancer. Sadly, the side effect is that you may lose a few toes. I’ll bet that I would still have a huge line of customers who want to use my product.

Now, instead of curing cancer, imagine that the product tells you where you should eat lunch. Unfortunately, the toe-loss thing still applies. I’m going to go out on a limb and say that I’ll probably have far fewer customers.

This seems obvious. Sacrificing a toe or three doesn’t seem like a big deal when weighed against your life, but it’s a different story when it’s just lunch. Even a really good lunch.

If you are asking your users to put up with a lot of pain, you need to do so in the context of giving them something extraordinary. I get asked all the time how to tell when something is good enough. Does it have enough features? Is the visual design pretty? What if it has a couple of bugs?  The answer to all of these questions is that it depends on whether the users are getting enough in return.

Every startup has a slightly different calculus for deciding what product to put out into the world, but I’m going to give you a piece of advice that will make this all a little easier: if you’re solving a really big problem that nobody else is solving, your early adopters will be quite tolerant.

This is one of the reasons why B2B applications often get away with being so awful and hard to use. If a product helps me do my job better and makes me more money, it’s solving a big problem for me. I’ll put up with a few missing features or a less than stellar experience. (There are lots of other reasons B2B applications are terrible, of course, but that’s not what this blog post is about.)

Of course, there is a minimum standard for anything you put out in the world. People have to understand what it does, for example, and be able to use it to solve their really serious problem. In other words, it needs to be both usable and useful. But the more useful it is, the more of a pass you get on a lot of the nice-to-haves.

To be clear, this is not a pass to make your product awful. Think of this as an encouragement to build something important that solves serious problems for people and to get it into their hands as quickly as possible.

Like the post? Follow me on Twitter!

Like the post but wish there were more of it? Buy the book!

Stop Making Users Explore

Often, entrepreneurs ask me something to the effect of, “What’s the best way to let new users explore my product?”

My answer is almost always a variation of, “Stop it.” In order to be slightly more helpful, let’s look at why this is a terrible question.

Users Don’t Care About Exploring Your Product

Nobody cares about your product. Fundamentally, what users care about is themselves. They are using your product as a means to an end. We knew this back in 1960 when Theodore Levitt explained that when customers buy quarter inch drills, they really are buying quarter inch holes.

Think about the last time you bought a drill. Did you sit down with the drill in order to spend time exploring it? Not unless you’re some sort of drill fetishist. What you almost certainly did was try to figure out the fastest way that you could set about completing the project for which you had bought the drill.

The same is true of whatever product you’re building. I know that you care deeply about the user interface of your product and all of the delightful features you have so lovingly handcrafted. Sadly, nobody else does. At least, not in the same way that you do.

People want whatever your product promises to do for them, and they want it to happen as quickly and easily as possible. They don’t want to explore your tax preparation software. They want their taxes done. They don’t want to delve deeply into the mysteries of your To Do List software. They want to not miss deadlines.

But What About B2B Products?

I know, I know. B2B products are different! They’re more complex! They have so many features! They require training and exploration!

Nonsense.

All of those incredibly complicated, feature-dense pieces of B2B software that require weeks of training are getting disrupted by things that humans actually understand. I worked with a company that required all documents be shared by filing a ticket with IT to create a personal folder on a shared server which then required mounting a new drive onto the desktop and...blah blah blah. Everybody just used Dropbox, even though it was officially forbidden by the company.

The fact is, people in big companies are forced to work with dozens of complicated products every single day. The introduction of a new, complicated product does not instill in them the desire to spend a lot of their day exploring it. It tends to make them sigh resignedly and figure out if there is some way to avoid learning the new system until it goes away and is replaced by something else.

The only way to make a product that people at work want to use is to make a product that is so obvious and easy to operate that they don’t feel like they have to explore it. They can just jump in, share a document, send an email, or do whatever task it is that they wanted to do originally. They shouldn’t have to explore anything to do their jobs.

But...but...but...Games!

Nope. Sorry. Still very little open exploration for new users.

I mean, sure, you can wander all over GTAV and steal as many cars as you want. But have you ever noticed how many quests and tasks and hints you’re given along the way as a new player? Actually, you probably haven’t. Really successful games are fabulous at getting you onboarded without making you feel like you’re going through a tedious training session but also without just dumping you directly into the deep end.

In fact, in good games, the real exploration doesn’t come until users are pretty comfortable with all the basic actions they need to be successful. Often, advanced features are hidden from users until they are unlocked. This not only provides the user with an incentive to keep playing, but it effectively hides complexity until the user is ready for it.

Think about hiding a rocket launcher from a new FPS player. Now think about hiding quarterly estimates from a tax preparer until you know that she needs to file quarterly estimates. There’s a surprising similarity. Note: hiding rocket launchers from people doing their taxes is also not a terrible idea.

E-Commerce?

Again, not really. While online stores do encourage you to explore and browse, you’ll notice that they don’t have you exploring and browsing the store itself. They have you exploring and browsing the products they want you to buy.

When you’re selling widgets, it’s all about showing off the widgets as quickly as possible. Even while you’re looking at a widget, the site or app is immediately offering you more widgets that you might be interested in.

It’s not about exploration of the product itself. It’s about getting you involved with the things the product is selling.

What Should You Do Instead?

Stop thinking about letting users explore your product. In fact, stop thinking about letting them do anything at all.

When a new user comes to your product, give them a task. Have them do the most obvious, low-friction thing that they will need to do in order to become a slightly more experienced user of the product.

Twitter is an excellent example. When you first join, they don’t just tell you to explore Twitter. They have you immediately start following people. This not only introduces you to the concept of following people, but it gives you a nice, low-friction way to start using the product in the manner it’s meant to be used.

Of course, figuring out what that most obvious first task is can be tricky. In order to do it well, you need to truly understand why your user might want to use your product. What problem are they trying to solve? What task do they want to accomplish? How do they want to change their lives? What sort of hole are they trying to drill?

Once you understand that, you’ll know how to create an onboarding experience that won’t force people to explore your product before using it. In fact, they’ll never have to explore it. They’ll just be able to accomplish their task and get on with their now-improved lives. And that, after all, is exactly why they wanted to use your product in the first place.

Like the post? Follow me on Twitter!

Want more advice like this? 


How about buying the book? It will help you learn how to build great products. I promise. 

Don't Allow Behaviors. Encourage Them!

I wrote this post for the O'Reilly Programming Blog. Here's an excerpt:

As a consultant, I’ve talked to a lot of startups who have “social” products. You could tell that the products were “social” because they had comment sections and sharing icons that let people post to Pinterest or Facebook.

Of course, one of the things that the founders complain about is that too few users are actually making comments or sharing or doing anything remotely social with the product.

There’s a very simple reason for this: the founders have added features to their product that allow users to be social rather than encouraging them to be social.

Read More at O'Reilly > 

Mobile First? Not So Fast! The Importance of Flow and Context.

I recently wrote a post for the O'Reilly Programming Blog called "Mobile First? Not So Fast!
Why "flow" and "context" are more important than screen size."

Here's an excerpt:

Are we done with the Mobile First meme, yet? Can we be? Please?

Look, don’t get me wrong. I fundamentally agree with a lot of the thoughts behind the annoying catchphrase “mobile first.” For example, I agree that mobile devices are now the primary (if not only) mode of connecting for many markets. I also think that having some sort of mobile strategy is absolutely required for almost every product.


The problem is that “mobile first” often equates “mobile” with “small screen” or “responsive layout” or “native vs. mobile web.” Now, those are all incredibly important decisions. But if you’re thinking about the size of your screen or the technology you’re going to use first, you are designing wrong.


Of course, if you’ve read anything else I’ve ever written, you know that the first thing you must figure out is an important customer problem or need that your product is aimed at solving for real people. We’re going to just skip over that whole part where you get to know your most important users. But that’s always first. Promise.


Once you’ve done all that though, you need to start designing. And there are two things that you should always know before you even start considering things like screen size or technology.


Those two things are: Flow and Context.


Read the rest at the O'Reilly Programming Blog >

Want more information like this? 


My new book, UX for Lean Startups, will help you learn how to do better qualitative and quantitative research. It also includes tons of tips and tricks for better, faster design. 

The Best Best Practice

I get asked for a lot of what I call "generic" advice, which I'm not really very good at giving. People will ask questions like, "Should I make a prototype?" or "Should I build a landing page?" or "Should I do more customer development?"

If you've asked this in email, you've probably gotten an unreadable 5,000 word manifesto that is essentially a brain dump of everything I can think of on the topic. If you've asked me in person you've almost certainly had to listen to me blather until your eyes glazed over.

Wherever you've asked, I've probably started the response with the words, "Well, it depends..."

And it does depend. What you should do right now with your product depends on a tremendous number of factors.

However, I think I've got some better advice for you.

You see, there aren't really Best Practices in Lean UX that apply in every situation. There are merely things that would be extremely helpful, except in cases where they'd be a huge waste of time. You can learn all the techniques in the world, but you still have to know when to apply them.

Every time you are wondering, "should I do this thing?" you should immediately ask yourself the following three questions:
  • What do I hope to learn by doing this?
  • How likely is it that I will learn what I want to learn by doing this?
  • Is there a faster, cheaper, or more effective way that I could learn what I want to learn?

An Example!

Somebody recently asked me if his company should build an interactive prototype of a proposed new feature. 

I asked him what he hoped to learn by building an interactive prototype. He said he wanted to know if people would use the feature. I explained that, actually, interactive prototypes aren't terribly good for figuring out if people will use your new feature. They're only good for figuring out if people can use your new feature. 

So, by building an interactive prototype, you're very unlikely to learn what you want to learn. A more effective way to learn if people will use a new feature might be a Feature Stub (also called a Fake Door). 

Note: A Feature Stub is where you put some sort of access in your product to the proposed feature. For example, if you were wondering if people would watch an informational video, you might put a link on your site called Watch This Informational Video and then record how many people clicked on the link. If nobody clicked your link, you wouldn't bother to make an informational video. 

To be clear, it may be that he should also build an interactive prototype in order to figure out if people can use the feature as designed. However, his first step should be to learn whether the feature is worth building at all. If nobody's going to use the feature, it's best to learn that before you spend a lot of time designing and building it.

It's All About Learning

The reason these questions are so important is that Lean Startup is all about learning quickly. If a particular Best Practice helps you learn what you need to learn, then you should use it. If not, you shouldn't. At least, not just yet. In other words, it depends.

Want to learn more? Buy this book.


My new book, UX for Lean Startups, will help you learn how to build great products. It also includes all sorts of Best Practices and when you should use them. 

10 Reasons Founders Should Learn to Design

I know, I know. Founders and entrepreneurs are already being told that they need to learn how to code, hire, raise money, and get customers.

Screw that. What founders and entrepreneurs should really do is learn how to build a great, usable, useful product. And that means learning the fundamentals of research and design.

Don't believe me? Here are 10 reasons you should learn to be your own UX designer (or at least learn enough about UX design to fake it).
  1. You can't build a great product if you don't know what problem it solves for which people. UX design and research helps you figure that out.
  2. The only thing harder to find than a great designer is a unicorn.
  3. It is almost impossible to judge somebody else's UX design skills unless you have designed things yourself. 
  4. The only thing more expensive than a great designer is a faberge egg. Sitting on top of a unicorn. 
  5. It's much easier to manage somebody who is doing a job you truly understand. 
  6. Jason Putorti already has a job.
  7. UX design is a team sport. You don't want to get picked last for the team, do you? 
  8. You have a million fabulous feature ideas. It's easiest to communicate them to your team and customers through design. 
  9. You should already understand your product and users better than anybody else. This just takes it to the next logical step. 
  10. Adding extra people to the Build>Measure>Learn loop does not make it faster. 
Convinced? Great! First, share this list with people!

Now, here's a book to help you learn how to do enough user research and design to get your product into the hands of people who want to buy it. 


It's called UX for Lean Startups. It's by me. It will help you learn how to build great products. I promise. 

Design Hacks - The Talk

I write a lot about user research - generally tips and tricks for people who don't have much experience with it. The reason for this should be obvious. Understanding your user, by any means necessary, is always the first step in creating a compelling product.

Seriously, you can't build a product without understanding the problem you're solving and the people for whom you're solving it. Various forms of research are the best way of understanding people who aren't you. It's really as simple as that.

But I've also seen another common problem. A whole lot of folks have learned how to go out and listen to their customers and understand problems, but they still make bad, hard to use products that don't really solve a problem. It turns out that, while learning your users problems is a necessary first step, it's not the only step.

You also have to be able to create something that people understand and want to use, and you don't do that by simply trying random ideas until one of them sticks unless you have an infinite number of monkeys and typewriters. If you are constrained with respect to monkeys, typewriters, or VC funding, you might want a little guidance on what to do once you understand the problem.

Getting your design closer to right on the first, second, or third try will speed things up considerably. It's hard to learn anything from a badly designed, unusable product other than the fact that people hate badly designed, unusable products. And believe me, that lesson has been learned. Kind of a lot.

That's why I'll be giving a talk at Lean Startup Circle on Wednesday, March 20th. It starts at 6:30.  There will be other interesting speakers, as well. You can sign up here: http://sanfrancisco.leanstartupcircle.com/events/102633722/

I'll be talking about Design Hacks. These will include a few general tips on producing a good design. It will also include some (free) resources for getting good design ideas. Time permitting, it will include an example or two of how to think about new features for your product in a way that makes them easier to design.

This talk is NOT for design experts. Sorry, you'll be bored out of your minds.

This talk is perfect for founders and engineers who don't have experience with turning what they know about their users into useful designs. And, as always, I'll be hanging around afterward to answer specific questions about your products.

Once again, to see the talk, sign up here: You can sign up here: http://sanfrancisco.leanstartupcircle.com/events/102633722/

If you want to hear about future events where I'll be speaking, you can follow me on Twitter.
If you like to read about things like Design Hacks, the book is available for pre-order.

Don't Make Your Users Feel Like Idiots

I’m a smart person. I’ve been using the Internet since the early 1990s. I know how to program. I only feel the need to point this out, because I’m about to share with you a story in which I come across as a complete, blithering idiot, and I’m feeling a little defensive about it.

I got an email from an event that I won’t name, but I’m guessing a few of you are getting emails of your own. If you didn’t make the same mistake, then bask in the glory of being better at computers than I am. If you did make the same mistake, welcome to the club. You’re not alone.

The email I received was several paragraphs long and told me all the places and times where I could pick up my badge for the event. It also said that they were introducing something new this year called a QuickCode. The email instructed me to bring my photo id and my QuickCode to pick up my badge.

Then it had the following line:
Laura Klein’s QuickCode:

That’s it. After that, it went on to give me more badge-related information.  “Aha, I thought. The automated system has failed to print my QuickCode.”

I immediately wrote back and said that I didn’t get my QuickCode. To the credit of the organization, I was immediately written back to by a very polite person who explained that the QuickCode was an image and even gave me instructions on how to turn on images in my email, in case I didn’t know how.

I was, as you might imagine, embarrassed. I mean, of course I know how to show images in an email. I just want to make that clear, because I’m coming off as enough of an idiot without you thinking I can’t use Gmail.

What I didn’t know was that the QuickCode was an image. Because I’ve never seen a QuickCode. Because a QuickCode wasn’t a thing to me until an hour ago. Because a QuickCode is just a name that somebody made up for a bar code that they’re using to help with their badging system.

Obviously the people writing the email knew what a QuickCode was, so it wasn’t at all surprising to them that you’d have to turn on images to see one. For those of us (ok, me) who had never heard of a QuickCode, this wasn’t immediately obvious. A QuickCode could just as easily have been a string of numbers and letters that could have been printed in the email. Of course, when I went back and re-read the email, the first paragraph did mention “scanning” the quick code, so I might have figured out what it was, but there were a lot of paragraphs in the email that I quickly skimmed. This is not unusual user behavior.

The interesting thing is that they could have avoided my acting like an idiot and subsequently having to deal with my support email by just including the phrase, “If you don’t see your QuickCode, try turning on images in your email.” They could have made that the alt text for the image so only people who didn’t have images turned on would see it.

Why am I telling you all this? I’m telling you this because we make assumptions of this sort in our interfaces every day. We assume people know that a QuickCode is an image, even though they’ve never heard of a QuickCode. We assume people know what our products do, even though they’ve never heard of our product. We assume people know where to go within our products to find the things they’re looking for, even though they weren’t in the meeting where we determined our product structure.

We are almost always wrong.

The moral of this story is not (just) that your users are going to do stupid things sometimes. It’s not even that they’re probably only going to skim our very long emails. The moral is that we constantly need to be asking ourselves what we really expect a user to understand about our product, and we need to have ways to preemptively help them in places where we’re presenting new concepts or unfamiliar terminology.

Users don’t know our slang. They don’t know our jargon. They don’t know our product. If we want them to use our products successfully, we need to teach them what they need to know without making them feel like idiots.

A Perfect Use for Personas

I was reading Dave McClure's post about changes to menus (and its not always flattering Hacker News thread), and I found myself both violently agreeing and disagreeing with both. I kept thinking something along the lines of, "That would be great! Except when it would be incredibly annoying!"

That's when I realized what was missing for me: personas.

 First off, apologies to Dave, who certainly doesn't need me to defend or improve his ideas. This is just meant to be an explanation of the process I went through as a designer and researcher to understand my weird, ambivalent reaction to his product suggestions. Here are the problems that Dave listed in his post that he was solving for:

  • Too many items, not enough pictures, simpler & more obvious recommendations. 
  • Not online, no order history, no reviews, no friends, no loyalty program, no a/b testing. 
  • Have to wait forever for waiter to order, re-order & pay. 
  • Nothing to do while I'm waiting. 

Then he presented reasonable solutions to these problems. All of the suggestions seemed geared toward making restaurants quicker, more efficient, and lower touch. Interestingly, both the Hacker News complaints and my own seemed to be from the point of view of people who do not have these problems. They were saying things like, "this would make restaurants awful!" but what they really meant was, "I, as a potential user, don't identify with that particular problem you're trying to solve, so your solution does not really apply to me."

In other words, Dave's suggested solutions might be great for people who have these problems but might not appeal at all to people who don't have these problems.

 So, then I started to think about the types of people who would have those types of problems. I put together a few rudimentary personas of people who likely would benefit from things like recommendations, entertainment while waiting, a more efficient order process, and a faster way to pay.

As a note, these personas are behavioral, not demographic. This means that you might sometimes fit into one of them and at other times you wouldn't. It depends more on what you do than who you are.

The Business Person

Imagine that you're on a business trip to someplace you've never been. You're quite busy, and it's likely that you'll have to eat a few meals on your own, possibly on the way to or from a meeting or the airport. You're not a fan of fast food, so you'd rather be able to find something you like at an interesting local place than at a big national chain.

 In this instance you might LOVE having things like recommendations from people you trusted, pictures on the menu of unfamiliar dishes, and a quick, efficient ordering and payment system that guaranteed you wouldn't hang around for twenty minutes waiting for a bill. You might also really enjoy some entertainment so that you'd have something to do that wasn't stare creepily at the other patrons.

The Barfly

Now imagine that you're at an incredibly crowded night spot. You are desperate for a bourbon, but you don't want to queue up five deep at the bar to try to get someone's attention. You manage to get a table, but now you have to decide whether to leave it to flag down one of the few waitresses or or just wait it out.

 In this instance you would almost certainly be excited to be able to order and pay directly from your table using some sort of tablet. You'd also be able to quickly order your second, third, and (dare I say it) fourth rounds without having to go through the whole process again or count on the waitstaff knowing exactly when to ask if you want a refill.

The Group Luncher

Last one for now, I promise. You're out to lunch with eight of your coworkers. You need to get back to the office in 45 minutes for another stupid meeting. You don't want to spend 10 of those minutes just for a waiter to make it to your table and take your orders. Also, you really don't want to be the one in charge of figuring out how to split the bill, especially since three of your coworkers always get booze, one of them never eats more than a salad, and two of them order the most expensive thing on the menu.

In this instance, you'd be thrilled to be able to just sit down, punch in your order (and your credit card!), get your food delivered to you quickly, and get to spend more time chatting with that cute new person in accounting rather than negotiating who forgot to figure in tax to the amount they owe on the bill. 

And the rest...

There are probably a half dozen other hypothetical persona groups, all of which would obviously need to be validated (or invalidated) with various forms of user research and quantitative testing.

 The persona groups that aren't on this list are also important. Many of these types of innovations might make things worse for the types of folks who are enjoying the experience of being in a restaurant as an event. For example, a romantic dinner for two at a high end restaurant is not improved by shaving thirty minutes off the wait between courses. Other people might enjoy the personal exchange with the waiter or a consultation from a sommelier more than reading about items on a tablet.

That's ok. These products aren't necessarily going to be for every type of restaurant all at once. There's no need to worry that suddenly Manresa is going to be putting pictures on the menu like Denny's.

 The reason I bring this up is that it often helps me to evaluate product ideas through the eyes of the people I expect to use the product. When I find myself saying things like, "Driving sucks! I'm going to fix driving!" I have to step back and realize that driving (like eating in restaurants) is an almost universal activity that has a constellation of problems, many of which are not shared by all types of drivers (or eaters). If you think your startup has a brand new product that's going to solve all the driving problems for stock car drivers, commuters, and truck drivers, I think you're probably wrong.

Instead of arguing back and forth whether or not these problems exist, it's very easy to identify particular types of people for whom these problems MIGHT exist and then do some simple qualitative research to see if you're right. After all, we know at least one person (Dave) has these problems that he wants solved. Presumably Dave (or the companies he invests in) are doing the sort of research necessary to make sure that there are enough people like Dave to make a profitable market. That market might not include you, but there are lots of wildly successful products you don't like.

 So. Long story short: personas, yay!

Postscript

For those of you who notice these things, you're right, I didn't include the personas for the other side of the equation: the restaurant owners. Whenever your customers (the people who give you money) and your users (the people who actually use your product) are different, you're in a much more complicated space from a user experience point of view. I'm assuming that, if we can make a specific type of end user happy enough it will make the types of restaurant owners who cater to those users interested in purchasing the product.

 That's just another hypothesis, and all hypotheses need to be validated, not assumed to be facts.

Here's the Problem With Your Product

As I mentioned on Twitter, I often answer emails that people send me asking questions about UX. I enjoy it. It helps keep me in touch with what type of questions entrepreneurs are having about their products.

Whenever I mention that I'm happy to answer UX questions (for free, guys! Seriously. I have a book to procrastinate, after all.) I tend to get one particular question over and over. It is some variant on "How is the UX for my product/site?"

I'm publishing an answer that is very similar to one I recently sent to a nice entrepreneur who asked me this question. I'm doing this because I basically end up writing the exact same thing over and over when people ask me this question, and I'd love to get some different questions. Please note, unless you are building one of a fairly small number of products that I use on a regular basis, this answer applies to you.


I can't give you insight into your site, because I'm not the target customer. If you ask for my opinion, it's going to be mostly useless, because it really doesn't matter what I think about your product. It matters what your user thinks about your product.

It's like if somebody asked you about your opinion of their spaceship. Presumably you don't fly spaceships, so your opinion is almost certainly not going to be super relevant to interspace travel methods. You want feedback about spaceships, you ask an astronaut or an extra terrestrial (no, I do not have suggestions on recruiting for that study).

In order to get in touch with some of your users, I'd recommend that you do the following:

Figure out exactly what you are concerned about with your site or product. 

  • Do you want to know if new users understand the messaging?
  • Do you want to know how people are finding specific information or performing tasks?
  • Do you want to know the general behavior of people coming to your site?
  • Do you care about the experience of current users, new users, returning users, etc.?
  • Do you care about what the look and feel of your site is telling new people? 
  • Are you wondering why your revenue is too low?
  • Are you concerned that people aren't coming back? 
  • Do you want to encourage people to share more? 
  • Are you having trouble converting free users into paying users? 
Figure out which metrics you care about that you'd like to change, and do some validation around why they are what they are. 


For example, if your conversion is too low, you're going to need to figure out if people don't want what you're selling, don't understand what you're selling, or don't care enough to pay you for what you're selling.

Based on what you want to learn, you need to find some way of learning that. You can ask me for specific advice on those sorts of things. The more specific you are about the type of user and the type of thing you want to learn, the easier it is for me to suggest doing something.

You can also ask me for advice on things like what to do when you've found out that people aren't sharing because they don't understand how to do that. Or if you've learned that people aren't converting from free memberships because they're not understanding the value that they'd get from your paid product. In fact, I'm happy to give you advice about how to proceed with your UX for anything that is at this level of specificity.

There is no such thing as generic "UX". Your user experience only makes sense in the context of your particular users, what their behavior is, and what you want their behavior to be.

When Talking to Users Saves You Time

I mentor a few young designers, which is great, because not only do I know exactly who I want to hire when I’m building a team, but they also share interesting stories about their current companies.

I was speaking with one of them a couple of weeks ago, and she shared a story that sounded incredibly familiar. I think this happens to all designers who work with a sales force at some point.

 The designer, whom we will call Jane, is working on the user experience for an enterprise product for hiring managers. The product has some competitors that have been around for awhile.

One day, a few weeks back, the sales team came to the product team and said, “We need Feature X. All of our competitors have Feature X, and we’ve heard from some of our potential customers that they won’t buy us if we don’t have Feature X.”

 Jane and her team looked at the competition’s implementation of the feature, which had a lot of bells and whistles. The product team asked sales which parts of Feature X was most important to the potential customers. “All of it,” sales replied.

Jane’s team starting pushing back. This was not a simple feature. They estimated that it would take months to get the feature to be comparable with the competition. There was one part of Feature X in particular, the live video part, that Jane knew would be incredibly tough to design and build, simply because of all the implicit requirements that would make it useful. They explained this to the sales department, but the sales department continued to complain that they couldn’t do their jobs without Feature X.

Finally, Jane insisted on speaking directly with a customer. A meeting was lined up with a few representatives of the company. Jane started off by asking how the potential customer would use Feature X. They gave detailed explanations of exactly the places that they needed Feature X, none of which had been conveyed by the sales team.

Interestingly, none of the uses they had for Feature X involved the live video part of the feature that was worrying the product team. Finally, Jane came right out and said, “Tell us about live video. How do you feel about it.” The potential customers shrugged. “I guess it might be useful,” they said. Jane asked, “Would not having live video prevent you from buying our product if we had Feature X?” “Not at all,” the potential customers said.

Jane’s team then had a similar conversation with other customers and potential customers. The product team gladly put the much smaller Feature X, minus the expensive live video feature, onto their product roadmap. They also left out a few other parts of Feature X that didn't solve actual user problems, and created a design for Feature X that was significantly different from the competitors' versions but that addressed all the customers' issues.

Sales was happy because now they could tell potential customers that they were competitive on features. Jane was happy because she was able to quickly identify a real customer problem and solve it, rather than fighting with sales about something that would take too long to build and would include features the customers didn’t actually want.

 My prediction is that Jane’s version of Feature X is going to be significantly better than the competitors’ version, simply because it will only have the pieces that customers actually need and use.

The new feature won’t be made needlessly more complicated by bells and whistles that are only put there so that a sales person can check something off on a list. They’ll be put there because they solve a problem.

You Know Too Much

This is not an earth shattering revelation. Think of it more as a friendly reminder that even people who have been doing UX for a very long time can get obvious things wrong.

For the last three months, I've been working on what I think is going to be an amazing product. Thanks to some fantastic engineers and some really hard work, our MVP is already out, and people are using it in closed beta. It's tremendously exciting.

The important thing to note is that I've been thinking about this product really, really hard for the last three months. We all have. We know everything about this product - who it's for, what it does, what it's going to do.

And that's the thing. We're crowdsourcing designs for children's clothing, sizes 2-6. We know that. We know that because that's what we told all of our wonderful, independent designers. We know that because those are the sizes we ordered from the manufacturers. We know that because that's the size of the models that we're using.

Which is why it was so surprising when I did a very quick user feedback session with someone who had used the site for the first time, and she pointed out that she wasn't sure what the age range on the clothes was supposed to be.

But then I looked at the site and tried, really hard, to see it from the point of view of somebody who hadn't been thinking about the product for three months - or even three minutes. And I realized that there was simply no way for users to know something that was so baked into our view of the product that we didn't even think to explain it.


It's a small thing, but it's incredibly important. After all, choosing designs you like for a 4 year old is quite different from choosing designs you like for a 40 year old, and crowdsourcing only works if the crowd knows what it's supposed to be picking.


This is why I'm so glad that we talk to users, even when we think things are simple or obvious. What is obvious to us is probably more likely not to be obvious to our users because we don't spend any time informing them of it.

We are making one very small, quick fix for this that should happen immediately, and we have a larger feature that I've already added a story for and hope goes into the product in the next couple of weeks.

The important reminder here is that I know too much about my product, and you know too much about your product. We think too much about our own products to be able to truly understand what a new user experiences.

Again, this is not a new concept, but it's a critical one if you're trying to make something that is truly simple and intuitive. You need to understand your user's starting point so that you can take her on a journey through your product without losing her along the way.

The single easiest way to see things through the eyes of your new user is to simply watch your user interacting with your product for the first time and talk to her about the experience. Don't try to do this without help from your users. You know way too much.

Sometimes It’s Not the Change They Hate

There has been a lot of discussion in the design world recently about "change aversion." Most of the articles about it seem to be targeting the new Google redesign, but I've certainly seen this same discussion happen at many companies when big changes aren't universally embraced by users.

Change aversion is a real thing. Often people don't like something different just because they're used to the old way. Once they get used to the new way, they discover all the wonderful new features and are happy with the new change.

But sometimes your users' rage isn't change aversion. Sometimes your new design actually sucks.

So, before you blame your users, you should figure out if it's change aversion, or if you really screwed something up. Ask yourself the following questions.

Did You Do Any Sort of User Testing Before Launch?

This is an important one. Sometimes people complain about a product because it has changed. Other times they complain because the product makes them feel stupid or it prevents them from doing what they want to do.

Most often, products make people feel stupid because the products are hard to use.

It's very possible that the changes you made to your product have made common tasks that the user is used to performing harder to do. Yes, the user may eventually learn to perform the tasks the new way, but that new way may be legitimately more difficult! You may even be reducing the amount of time the user spends performing that task, if you make it hard enough.

To pile onto the Gmail redesign for a moment, I can tell you right now that I am constantly hitting the folder button instead of the label button now that they are icons rather than text. I am still occasionally doing this probably a month after I switched to the new look. It's not a deal breaker for me, but it annoys me every time it happens. The new icons, for me, are honestly harder to use than the old buttons, and they build up a certain amount of unhappiness every time I use them incorrectly.

The interesting thing is that this is exactly the kind of problem that you can surface very easily by simply doing some observational testing of people using prototypes or early versions of the product.

Hell, you could probably even figure that one out with metrics. How often are people hitting the Undo button now compared to previously? If people are undoing their actions more frequently, you can bet that your new design is causing them to make mistakes.

Did You Test with Current Users or Just New Ones?

When you have millions of users, it's not cool just to test on people who have never seen your product before.

New user testing gives you really valuable feedback, but it's just one kind of feedback. It doesn't give you any insight into how your current users (often users who are paying you money) are using your product right now.

It may be that your users are doing something surprising with your product. They may be using it in ways you never anticipated. Making major changes without understanding their work styles can destroy something they were relying on.

It's not a matter of their relearning how to do a task in the new interface. You may literally have removed functionality for people who were using your product in innovative ways.

Similarly, if you're only testing with internal users (that is, users internal to your organization), you're not really getting the full idea of how all sorts of different people are interacting with your product. The more types of people you can observe, the clearer your understanding of real use cases and behaviors will be.

Did You Add Something Useful to Users? Really?

Sorry, improving your brand is not particularly useful to users. Even a nice new visual design tends not to be a big enough improvement if you're also changing functionality that users rely on.

Here are some significant improvements that might be enough to counteract a tendency to change aversion:
  • making your product noticeably faster or more responsive
  • adding a great new feature that users can understand and start enjoying immediately
  • fixing several major bugs that people have been complaining about
That's pretty much it.

The problem here is that often companies mistake doing something that is good for the company with something that is good for the user. That can be a tricky thing to spot, but a good way to handle it is to always ask yourself, "What real user problem is this change solving?" If the answer is, "How to give us more money" or "Well, there's more visual breathing space," you might want to brace yourself for the inevitable shitstorm when you launch that change.

Do You Mind Losing a Portion of Your Users?

This is a 100% legitimate question to ask. Sometimes you make changes to your product that you know will piss off a certain subset of your users, and that can be ok.

I've often advocated for prioritizing changes that help your paying customers over changes that help your non-paying users. But there can be other reasons to make changes that annoy certain groups of your users.

The thing is, you have to know that you're making this tradeoff and be ok with it. If you've gone into the change knowing that you might lose a certain percentage of your users, but hoping that you will make up the loss by making other users very happy or attracting new users, that's a fine choice to make. Just be sure that your metrics show this actually happening.

Have You Honestly Listened to Your Users' Complaints?

Let me give you two common examples of user feedback:
  • I hate it! It's terrible! I want the old way back!
  • I'm constantly hitting the folder button when I want to hit the label button, and I find it really hard to tell which emails are more important any longer. Also, every time I try to Reply to All in the middle of an email thread, it's just ridiculously difficult to do.
Can you spot why they are so different? That's right, one of them is completely non-actionable. There is nothing you can really react to with the first one. You can't fix this user's problem. Yet.

The second one is significantly better because you're starting to get at WHY the user hates the change. You know that the user is having trouble performing specific tasks. You can follow up with the user and have her show you the things that you have made harder to do. You can then figure out if those are things that are done frequently enough and by enough users to justify making them easier to do.

Here's the trick. You can turn the first type of feedback into the second type of feedback by following up with users and asking them for specific things that they hate about your change. If they just keep saying, "It's different!" then they may get over it when they get used to it. But a significant portion of them probably have specific complaints, and writing those complaints off as change aversion is really kind of a dick move.

Have You "Fixed" the Problem by Letting Users Change Settings?

Stop it. Seriously. Just stop it.

The vast majority of your users don't know how to change the default settings.

It's not a failing. They're not stupid. They just don't know nearly as much about your product as you do, so they don't have great understanding of the million different ways you've allowed them to customize their experience. They probably don't even know that those settings are there, and even if they do, why are you making them work that hard?

If you are going to include a few settings that they can change, make them obvious, easy to understand, and don't bury them in a thousand other settings that are incredibly confusing to everyone who isn't in tech and half of us who are.

Like the post? Follow me on Twitter!

I Don't Know What's Wrong with Your Product

When I’m talking with startups, they frequently ask me all sorts of questions. I imagine that they’re probably really disappointed when I respond with a shrug.

You see, frequently they’re asking entirely the wrong question. And, more importantly, they’re asking the wrong person.

It is an unfortunate fact that many startups talk to people like me (or their investors or their advisors or “industry experts”) instead of talking to their users.

Now, obviously, if they just asked the users the sorts of questions they ask me, the users couldn’t answer them directly either. This is the wrong question part. But the fact is, if they were to ask the right questions, they’d have a much better chance of getting the answers from their users.

Let’s take a look at a few of the most common sorts of questions I get about UX and how we might get the answers directly from users.

What’s Wrong With My Product?

I often get people who just want “UX advice.” I suppose they’re looking for somebody to come in and say something like, “oh, you need to change your navigation options,” or “if only you made all of your buttons green.”

Regardless of what they’d like to hear, what they typically hear is, “I have no idea.” That’s quickly followed by the question, “Which of your metrics is not where you want it to be?” If they can answer that question, they are light years beyond most startups.

You see, the first step to figuring out what’s wrong with your product is to figure out, from a business perspective, some realistic goals for where you’d like your product to be right now. Obviously, “We’d like every person on the planet to pay us $100/month” is probably not a realistic goal for a three month old venture, but hey, aim high.

Once you know what you want your key metrics to be, you need to look at which of them aren’t meeting your expectations. Are you not acquiring new customers fast enough? Are not enough of them sticking around? Are too few of them paying you money? While “all of the above” is probably true, it’s also not actionable. Pick a favorite.

Now that you know which of your key metrics is failing you, you need to conduct the appropriate sort of research to figure out why it’s so low. Note: the appropriate sort of research does not involve sitting around a conference room brainstorming why abstract people you’ve never met might be behaving in a surprising way. The appropriate sort of research is also not asking an expert for generic ways to improve things like acquisition or retention, since these things vary wildly depending your actual product and user base.

The appropriate sort of research depends largely on the sort of metric you want to move and the type of product/user you have. You will, without question, have to interact with current, potential, or former customers of your product. You may need to observe what people are doing. You may need to ask them why they tried your product and never came back. You may need to run usability tests on parts of your interface to see what is confusing people the most.

Feel free to ask people like me for help figuring out what sort of research you need to be doing. That’s the sort of things experts can do pretty effectively.

But if any expert tells you exactly what’s wrong with your product without considering your user base, your market, or your key metrics, either they’re lying to you or your problems are so incredibly obvious that you should have been able to figure them out for yourself.

What Feature Should I Build Next?

Let’s imagine for a moment that you have built a Honda Civic. Good for you! That’s a nice, practical car. Now, let’s imagine that you come to me and ask how you should change your Honda Civic to make more people want to buy it.

Well, I drive a Mini Cooper, so it’s very possible that I’ll tell you that you should make your Civic more adorable and have it handle better on curves. If, on the other hand, you ask somebody who drives a Ford F-150, they’ll probably tell you that you should make it tougher and increase the hauling capacity.

Do you see my point? I can’t tell you what feature you need to build next, because I almost certainly don’t use your product! To be fair, even the people who do use your product or might use your product in the future can’t just tell you what to build next.

What they can tell you is more about their lives. Do they frequently find themselves hauling lots of things around? Do they drive a lot of curvy mountain roads? Do they care about gas mileage? What about their other purchasing choices? Do they tend to buy very expensive luxury items? Do they care more about status or value?

You see, there is no single “right way” to design something. There are thousands of different features you could add to your product, and only the preferences and pains of your current and potential users can help you figure out what is right for you.

Should I Build an App or a Website or Something Else?

Another thing that people ask me a lot is whether they should be building an iPhone app, an iPad app, an Android app, a website, an installed desktop app, or some other thing.

That’s an excellent question...to do a little research on. After all, what platform you choose should have nothing to do with what’s popular or stylish or the most fun to design for. It should be entirely based on what works best for your product and market.

And don’t just go with the stereotypes. Just because it’s for teens doesn’t necessarily mean it’s got to be mobile, although that’s certainly something you should be considering. It matters where the product is most likely to be used and what sort of devices your market is most likely to have now and in the near future. It also depends on the complexity of your product. For example, I personally don’t want Photoshop on my phone, and I don’t want a check-in app on my computer.

Talk to your users and find out what sort of products they use and where they use them.

Are You Noticing a Pattern?

Experts are not oracles. You can’t use outside people as a shortcut to learning about your own product or your users. You need to go to the source for those things.

If you find yourself asking somebody for advice, first ask yourself if you’re asking the right question, and then ask yourself if you’re asking the right person.

And if anybody ever tells you definitively what you need to change about your product without first asking what your business goals are, who your users are, and what their needs are, you can bet that they’re probably wrong.

Hey, you got to the end! Now you should follow me on Twitter.

Fucking Ship It Already: Prototype Testing Can Save You Time

So, I was talking to a company the other day, and they had just done a major redesign of their product. Unfortunately, as soon as they released it, they started getting customer complaints. They had removed a particular feature from the main part of the product, and paying customers started to scream.

They were already allowing people to use the previous design, which was a good thing, since folks started switching back immediately. Of course, they went into recovery mode. They started looking at customer feedback and planning a redesign of the redesign to reintegrate the feature they’d removed.

I asked what I thought was a reasonable question: Had they done any prototype testing with current users during the early phase of the major redesign?

Their response was, “We didn’t have time for prototype testing.”

Oh, really? That’s an interesting answer, because they sure has hell had time to do a fairly significant reboot of their redesign after launch to fix a problem that would have been prevented by showing some wireframes to current users.

After all, they already had mockups of the new designs. Showing those mockups to users would have taken a day of work at most.

Look, shipping fast is important. In fact, these days I’d say I do far fewer interactive prototypes than I did back in the days when we were still doing waterfall, mostly because engineers in a continuous deployment process can build, test, and iterate on something almost as fast as I can with an interactive prototype.

But major redesigns that touch all parts of the interface are exactly the kind of thing that you should make time to do prototype testing on. Because in this sort of scenario, more often than not, an interactive prototype, or even just a wireframe or sketch or mockup, can end up saving you a lot of time after launch. They help you get feedback from customers before you go to all the trouble of building something you have to roll back or redesign.

The most important thing to remember is that one of the biggest reasons for shipping fast is to learn as quickly as possible from your mistakes. If you can learn more quickly and efficiently from an interactive prototype, you should do that.

Going really fast in the wrong direction doesn’t actually end up saving you any time in the end. Sometimes glancing at a map before you leave gets you where you want to go faster.

Like the post? Follow me on Twitter.

Fucking Ship It Already: Limited Products vs Shitty Products

In our second installment of Fucking Ship It Already, we deal with a common problem for startups: shitty products.

Look, I know that building a product with one or two engineers and no money is tough. As an entrepreneur, you almost certainly have far more ideas than you have resources to create those ideas. And it doesn’t help that you have people like me screaming, “Ship it! Ship it!” before you’re really ready.

Who could possibly blame you for shipping a product that is, frankly, kind of shitty?

I could. Knock it off.

Let’s take a step back and try to understand the difference between a shitty product and a limited product.

One big difference is that I wholly endorse shipping a limited version of your product. I think it’s stupid to ship a shitty product. But what does that mean?

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn’t crash relentlessly. It doesn’t have enormous usability problems.

It is not half a big product. It is a small but whole product.

Most importantly, a limited product is just big enough and good enough that you can learn something important from it.

But a limited product probably doesn’t do anything else. It doesn’t have bells and whistles. It doesn’t have “nice to have” features. It may only support the problems of a small subset of the market. It may only be released to beta users.

A shitty product, on the other hand, often tries to do too many things at once, and it doesn’t do any of those things particularly well.

You really don’t want a shitty product because, when people don’t use it, you have no idea if they aren’t using it because you have a bad idea or the wrong market, or if it’s just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren’t “polished.” They will abandon products that are just bad.

Here’s an example - remember when Amazon only sold books? If you were around in the ‘90s, the company that now sells fifteen different versions of everything on the planet only sold actual printed books.

And they did it really well. They made it pretty easy to find books. They had a large selection of books. They shipped the books to you reliably. They had nice descriptions of the books. They improved on the bookstore experience by offering me a giant bookstore in my own home.

In other words, they did one thing - sell books online - and they did it well. It wasn’t until years later that they even branched out into selling things similar to books. And it wasn’t until they were wildly profitable (and no longer a startup) that they started adding advanced features like eReaders, cloud storage, and a marketplace where other people could sell things.

What they didn’t do was do a half assed job of trying to sell you everything immediately. They didn’t promise to sell you toasters and jewelry and smoked salmon but then fail to actually ship any of that to your house or charge you three times for the same item. They figured out how to sell things to people online with one understandable market that they could learn from.

Other examples of products that started out doing one thing really well are Instagram, Google Search, and even Facebook. Remember, Facebook started out solving a single problem on a single college campus.

Now, I’m not saying it’s easy to build a product to sell books or share photos or search the web. It’s not. It’s incredibly hard, and it’s even harder to get right.

But that’s exactly the reason why you need to dramatically limit the scope of your initial product. Even building something that seems easy is hard to do well. Imagine how hard it is to build something really big!

So, when I’m yelling at you to Fucking Ship It Already, I don’t mean that you should ship something bad. I mean that you should ship something limited - something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again. Do this over and over again as many times as you can for as long as you can.

Eventually, you’ll build the product of your dreams. It will probably be quite different from what you originally imagined, but that’s a different blog post.

Fucking Ship It Already: Visual Design

I asked on Twitter whether anybody would buy a UX book called Fucking Ship It Already. Apparently some of you are interested. So, in the interest of following my own advice, I’m shipping the book iteratively in the form of this blog. You’re welcome.

I’ve talked in the past about lots of ways to do user research faster. Now, let’s talk about a way to make your design process faster. This is not a new idea, but it’s worth reiterating for those of you who are trying to make decisions like this on a day to day basis.

Today’s chapter will cover the fastest and most useful sort of visual design for your lean startup.

There is some tension out there in lean startup land. Many people favor eschewing visual design polish all together, since it’s more important to figure out if a product is useful and usable before spending time “making it pretty.” Other people argue that a good user experience includes things like trust and delight, which can be enhanced by good visual design.

I’ve seen this work both ways. I was speaking with an entrepreneur the other day who told me a relevant story. Apparently, she had spent time on visual polish for a login screen. There were a few things that took awhile to implement, but they made the screen look much better. Unfortunately, the next week she had to rip it all out to change the feature, and all that time pushing pixels was wasted.

On the other hand, I’ve had dozens of people talk about Path’s gorgeous and delightful interface recently. Would they have gotten that kind of buzz without spending time on the visual details? Most likely not.

So, what does this mean for you? Should you spend time on pixel perfect screens and delightful visual design? No. And yes.

Here’s what you should do: spend a little time developing clean, flexible, easy to implement visual design standards.

What That Means

It’s probably not worth your time to fret and sweat over every single pixel on every single new page, mostly because you should always plan on iterating. When you’re a startup, any new feature may be killed or transformed in a week’s time.

If you spend days getting everything lined up beautifully on a product detail page, that could all be blown to hell as soon as you add something like Related Products or Comments.

Many people think that the right answer is to have a grand vision of everything that will eventually go on the page, but things just change far too rapidly for this. Imagine that you’ve carefully designed a tabbed interface with just enough room for four tabs. Now imagine that you need to add a fifth tab. I hope you didn’t spend too many hours getting all that spacing exactly right.

What You Should Do Instead

How about spending time on the basics that won’t have to change every time you add a feature?

For example, you could establish standards for things like:

  • An attractive color palette
  • Font sizes and color standards for headers, sub-headers, and body text
  • Column sizes in grid layouts
  • A simple and appealing icon set
  • Standards for things like boxes, gradients, backgrounds, and separators
  • A flexible header and footer design

Why You Should Do This

The great thing about having standards like these is that engineers can often combine them with sketches to implement decent looking screens without having to go through a visual design phase at all.

Also, since these things are reusable and flexible, there’s no wasted effort in creating them. Killing a feature doesn’t make knowing that your H1s should be a certain size and color any less valuable.

The best part is that you save time in a few important ways. First, as I mentioned, you don’t necessarily need to involve a visual designer every time you want to create a new screen. Second, this sort of approach tends to encourage a much simpler, cleaner, more flexible design, since items need to work in various combinations. And lastly, it tends to keep things more consistent across your product, which means that you’re less likely to have to go back later and do a complete redesign after things have gotten hideously out of whack.

It won’t solve all of your visual design woes, but it will make developing new features go faster, and you won’t be quite as sad when they fail miserably and you have to kill them.

Like the post? Want more tips on shipping already? Follow me on Twitter.