How to avoid getting burned building your first (web) startup
I just attended a UX feedback session this morning. And I left feeling bitter at the startup world.
I was one of four attendees who gave user feedback on a new website (the company product is a website). The business idea is beautiful and smart. A lot of work went into designing and building the site. Prior to launching, 100 interviews were done to improve the idea, the pitch & to get early user feedback on screenshots. The founder did a lot to make sure that users were involved.
So why did I leave feeling bitter?
Because that founder had just done the exact same mistake I did when I first launched. That was the mistake that got me really close to quitting, cost me 7 months of stress and thousands of dollars.
I felt for her, for all her hard work and for how she must be feeling right now as we gave her feedback... and as we suggested that she start her site all over.
Let me first explain the anatomy of the problem she (and I) experienced:
- Your business is a website or an app.
- You speak to a lot of people to validate your pitch & even show them screenshots of your future site.
- Based on feedback, you improve your idea/screenshots, validate further (and repeat updating-validating cycles). Then you get on to building the beast.
- Building takes a while and costs money (darn) -however, you have an amazing feeling of accomplishment and excitement as you see your website coming to life.
- You've read the Lean Startup. The whole time, you keep on thinking about "keeping it lean" so you only include 30% of all the features you want your site to have. You feel apologetic whenever you present the site to others because of it.
SO, WHERE'S THE PROBLEM?
1) Seeing vs doing
I've noticed that when users can only see something that is meant to be used, most of the feedback has to do with visuals. "I like the colors." "The sign-up section looks clear." "The layout looks a bit confusing."
That's all helpful but it's only scratching the surface.
By seeing screenshots (or high fidelity mockups), they'll imagine themselves using your website. But imagine doing the same for a car. Between imagining yourself driving a car vs actually driving it, there's a world of difference. When imagining, you might give feedback on your first impressions, lots of which might have to do with style and looks. When actually driving it, you'll give much more concrete feedback. You might discover that you don't like the rear window visibility or that the stick shift is not where you expected it to be.
That's often why there's a massive gap between user feedback on static images of your website vs. your actual website.
By being able to click through content, there's something that tends to shift in how they look at your website. Users will start noticing:
what they expect to see vs. what is there (e.g. missing buttons or items which they thought were clickable -but aren't)
how they understand or don't understand what you're trying to make them do (for instance, does your sign up process make sense to them?)
- whether you have built something that keeps them interested and motivated. (Are they doing you a favor by visiting your website or are they genuinely eager to keep on browsing further?)
As the website/app builder, you also gain a huge advantage by having users interact with your site live: you get to see the unspoken reactions. The sour faces when trying to understand a confusing process or how they scrolled all the way down and then back to the top if they're still uncertain about what they're supposed to do on that page.
These will tell you that there's a problem with UX even if no word is spoken. If you care about building something right, you'll want that invaluable insight.
2) Users aren't great at speaking their minds
Remember how, in order to test your idea, you shouldn't just ask users whether they like it or not because most people will say "Yes"?
Similar for UX. Most people are polite, which makes for an amicable and peaceful society. Yet politeness also restricts people from speaking their real thoughts and that's really harmful while trying to obtain feedback. Users often don't want to offend you/your work so they'll give you genuine comments, up to the point where they start feeling bad about all the negative things they've told you. They'll then stop and tell you that the rest looks good to "save" your feelings. So you start thinking that there are some issues that you need to address, but that there's also lots (deeper into your site) that is ok.
Sorry to break it to you but that might be wrong.
3) Your "lean" version is already too fat
This is almost a rite of passage for new website/app builders.
When you start thinking about what your future website looks like, you imagine all kinds of fancy features. Notification, messaging, social media integration, etc. You know that your first version should be "lean", so you get rid of most of them. But it's still too fat.
By having too many features, you'll run into a few problems:
- Once your website is built, you'll have a hard time getting feedback that aligns. Because your users have so many options to navigate through, you'll get an incredibly wide range of observations. It's easy to get confused when you have lots of feedback on lots of features and it becomes harder to know "what should we tackle next".
- When there's too much to navigate, users tend to give up. They're able to give very precise feedback on the very first few pages but if you've done the same mistake I did and built too many pages, after some time their feedback will stop being precise and their comments might go from "I don't like your wording" to "Hm, it's confusing". Precise feedback is a whole lot more valuable and actionable.
- Removing features is a lot more difficult than adding new ones. Trust me.
4) Feature creep
Feature creep happens when you think that adding a feature might solve an existing problem, or when you find yourself having too many features too quickly (as in the previous point).
This can happen at any stage of the website building (or improving) process but I find it to become a slippery slope especially when your website isn't lean enough to start with.
While reviewing your site, users will see that there are issues with it. And their recommendation is often to add features.
For instance, if you're building an e-commerce site and your checkout feels like a maze, users will recommend adding elements that they've found helpful in other checkout pages. For instance, this checkout map used on Amazon might be a recommendation:
Certainly, adding this can be helpful. But it detracts from what really needs to be done which is to trim, simplify and clarify the flow and content.
I'VE DONE ALL THESE MISTAKES - WHAT CAN I DO?
A whole lot of time and effort went into your project and you're feeling crushed, cheated, and foolish. At least, that's how I felt when it happened to me. But where there are problems, there are solutions:
Stop coding or paying for coders. Just stop. For the sake of this exercise, put aside everything that you've built so far. It's not going in the garbage but we just can't allow ourselves to get distracted by it.
- Think about what is the core functionality your website should have. Trying to trim down features from your fatty first version is a lot harder than picking the one core functionality it should have -so let's do that.
- ("But wait: my site has to have all that it has! It isn't the same without it.How do I pick a single core functionality?" That core functionality is the one thing that makes your product most valuable, the one thing that turns users into fans. Yes, they might feel like features are missing but they'll LOVE what they can already do with your site. If Facebook was doing this exercise, their core functionality would be to enable users to befriend others and see each others' profiles. All the rest is extra.)
- Use a wireframing tool (e.g. Balsamiq) to create a very basic version of your new website. Only focus on offering this core functionality to your users.
- Ask a few people to have a look. What do they think they're supposed to do on the homepage? How would they explain your site to a friend? The goal of this exercise is to ensure that your core functionality is actually valuable and clear. I could write a full book on this alone but let's keep it to the basics for now.
Get user feedback, then improve your wireframe and functionality as necessary (do they really care about what you're building?) A few loads of rinse and repeat can be useful.
- Once you have a consensus amongst users that your core is clear and valuable, build basic mockups. That's an image of what each web page will look like. A great tool for this is Sketch (for Mac). I do mine in PowerPoint. It's not the "right" tool for it but it's the one I'm fastest at so that works for me.
- Use a prototyping tool like InVision to string all the pages together. This means that you can connect all your mockups to each other so that when a user clicks a button on screen A, screen B will load, or if he clicks on the menu, menu options appear. From a user perspective, it will feel like navigating through a real website.
Test it with five users. Put it in front of them and see how they interact with it. Again, I could write a lot more about this but if you're unsure of knowing what this entails, google "How to do user testing".
And that's when you need to be patient. I know, we're all eager to have a real website built (it feels more productive than "playing" with designs) but it's invaluable to do as many cycles of testing > feedback > update > more testing as necessary to get you to the point where your website is 100% clear for users. Imagine if you had to code all of this. That would be incredibly time consuming (and expensive, if you're paying for dev). That's why all these cycles happen without touching any code from your first website version.
- Now that you really know what you should build, you can finally look at your (old) code again. See what can be reused from your prior version. In my case, it was faster for my developer to scrap the first version and start over. (What doesn't kill you makes you stronger, right?)
Yes, it might sound like a harsh conclusion but, really, it isn't.
Starting over with a crazy lean version, it becomes a whole lot easier to 1) perfect the very few elements of your site; 2) know what features to add next (simply ask users "what is one extra thing you wish this site could do?" and see what's most popular. Don't forget to prototype this new feature and test it prior to building it).
When I went through this process, my new super-lean version had one page with two tabs on it. As a result, all the feedback was incredibly precise. I had also stopped wasting time/money perfecting features no one really cared about.
Image: My original "lean" version vs. my second version, which consisted of a single page (and looking back -it still had too many features).
It was a humbling process to go through and there's a massive amount of learning that came from it. If you know anyone going through the process of building a website or an app, please share this with them. If this post can prevent even one person from going through this mistake, I have done my job.
And if you've had a different experience or have learned your own lessons going through the process, share it below.
The more we share, the more we learn, the more we succeed.
Note: I barely scratched the surface on user testing but let me at least add an extra note on whom you should be testing this with:
Make sure that the users testing your product are real candidates for it. For instance, as I'm building a website for early stage startups, I make a point to always test it with new startup founders. I don't care if a corporate lawyer loves or hates it -he's not who I'm trying to onboard right now.
If your users are people who build websites or apps, their feedback will be VERY different. They tend to understand product building pitfalls such as feature creep and therefore will not only give you their feedback but also helpful recommendations and new ways to look at problems. Asking these people feels more like adding a teammate to your startup than asking a user -try to find these valuable folks!