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.
Pages
▼
Wednesday, February 15, 2012
Monday, February 13, 2012
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.
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.
Thursday, February 9, 2012
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.
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.
For example, you could establish standards for things like:
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.
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.