When bad metrics are good metrics: Things we learned from redesigning our landing page, part one.
We made a new landing page, but was it better or worse?
The appear.in landing page has remained more or less unchanged for the last 2 years. But as 2016 came to a close, it was time to do something about that. New year, new opportunities and all that.
I’m a designer so this decision obviously made me happy 🎉. (Spoiler: We love to design landing pages.) So at this point I was all caught up in thinking about stuff like:
- Should we do parallax scrolling? On what elements?
- What’s the best way to prevent the user from scrolling naturally?
- Do we need an arrow pointing down to encourage people to scroll past the fold to navigate between the elements?
- Is the fold even a thing anymore?
- Do we need to pay someone to shoot a video that’ll loop in the background of the header section? How much? Will our developers loose it if it’s above 1 megabyte?
Just kidding, I wasn’t thinking about any of these things.
The landing page is our first impression on new users who want to try our product, and improving that onboarding was our main goal, with the added bonus of updating our brand visually and message wise in the process.
So, aside from the old landing page being, well, old, what is there to fix and why? As read on countless blogs a good design process starts with a problem, because if you don’t have one well what are you gonna solve?
Users: Everybody has a reason
First of all, we need to assume that anyone that finds themselves on https://appear.in have a specific reason for being there. Their browser didn’t magically type that url on its own.
Something made them visit appear.in, so we can assume they have a specific user task to perform. I could write paragraph after paragraph about this, but I won’t , let’s just agree that users come from somewhere, for a reason, and leave your site either:
A: Happy 😀, after managing to do what they came for without friction.
B: Angry 😠, because they didn’t manage to do what they came for, or managed but only after a long struggle trying to understand how this product works.
In our case, it’s natural to assume that users want to test or have a video conversation without the hassle of, well, using tools that aren’t ours. We’re awesome, after all, and think we‘ve got the simplest video conversation solution available. Before arriving at our landing page, they’ve learned about appear.in somehow, and now they’re at our doorstep ringing the doorbell and want to get into the action.
We’re not fixing something that’s not broken, so what’s broken?
Besides the design and copy being dated when it came to explaining how the product works, the main UX issues were all related to the room generator at the top:
- A lot of users assumed they created a new room from the landing page, when in fact they’re just entering any url.
- The issue above causes confusion later on, especially if you enter names that are already claimed by other users. You’ll assume that a room is yours, when it’s actually is someone else’s.
- Encouraging random auto generated urls is not perfectly aligned with our business goal, wanting users to register to claim a room and keep using it ater.
- Appear in does not work on iOS/Safari+other unsupported browsers, and there is no way to learn without entering a room.
We have pretty good ideas about how to fix these issues, and we’ve already implemented a lot of them in our iOS app after multiple prototype iterations coupled with usability tests. More about that in another writeup.
On the web however, we’re doing this step by step, and decided to get started with the easy part, the content/design excluding the room generator.
Enough talk about problems, let’s design
We wanted a simple and to the point landing page, enhancing our position as a simple solution for video conversations. Personally I would want the site to be as close to this (warning: adult language) as possible, but that’s me.
Assuming new users come to our site mainly to have video conversations, how can the landing page help them towards that goal?
- By prioritising and encourage users to create/enter a room.
- By explaining how the product works in an as simple way as possible.
- Explaining what the product can do for you (features!)
- Why this product is better at doing this than others. (bragging or testimonials as it’s usually referred to)
- Overall: Make it appear (pun intended) trustworthy. This is where that thing that hardcore UX people refer to as visual design comes in handy. (Would you trust a surgeon who dressed like he was on holiday? Probably not. Same goes for product landing pages.)
New content with old header: How did it go?
After pushing this to the www we held our breaths for about a week, before we finally gave in and opened Google Analytics to see if anything had changed.
Spoiler: Nothing really changed. The average number of users getting into rooms from the landing page (it’s main goal) was exactly the same as the week before. Time spent on page was similar, bounce rates were stable. Why did we even make a new landing page?
Some things can’t be measured, and we strongly believed it explained the product better, plus served as a more trustworthy facade with its updated to the point design and copy.
Someone even tweeted us to praise the footer:
We didn’t know big footers were a thing that went away, but we’re glad to be bringing them back.
Second release: New header!
Now we’re getting into the juicy stuff! New design for the room generator, one of the most important div elements of our entire product. Let’s not screw this up, or we’ll be fired 😱.
Wait! One more thing…
Jamy and I had one more thing we wanted to squeeze in during this sprint though: Browser specific error messages.
WebRTC video technology is great (just ask our team member Philipp Hancke), but sadly it’s not yet supported by all browsers 😞. Most importantly apple’s Safari. Previously all users were treated equally, iOS and Safari/IE web users who attempted to create rooms were able to click the button, only to be surprised with an error message after the fact.
When we added up the numbers, turns out this happens to a lot of people. Safari(web and iOS) + Internet Explorer makes up 14.1% of first time users on the landing page.
So around 14.1% of first time visitors are not getting a nice user experience. We should fix that before releasing the new header section!
I told Jamy “let’s make some kind of logic that if this, then that for those browsers, isn’t that what programming is all about?” To which my dear South African colleague answered: “Yeah, that’s basically what it’s about.” (See, designers are learning to code.)
This led to the new header, while keeping it’s old functionality (we’re gonna do more fancy stuff later, remember?) now telling iOS users to get the app, and users on Safari/unsupported browsers to well, try another browser. Pretty sweet! This was released on December 19th, just a week after the first release. LEAN! 🙌
How did it go this time?
Emojis and high-fives were shared in #general, as a team we were happy about our new digital first impression. No tweets praising the footer this time though, so I guess we’ll have to look at the numbers*.
Remember the most important job of the landing page, getting users into rooms? Well, conversion rates were down 😱! By 4.6%! Fewer users are doing what they want to do (bad!) and what we want them to do (also bad!).
This also means that fewer users are getting into conversations from the landing page. At this point I’m thinking I might be in trouble. What was happening? I went to look at the bounce rates. Uh oh:
Bounce rates had gone up by 43.3%! This was really bad. I was just about to close Google Analytics, clean my desk and prepare an “I’ve learned so much but it’s time to move on” email when I realised:
This isn’t bad at all. It’s exactly what we wanted to happen.
Why are bad metrics good metrics?
Remember all those Safari/IE and iOS users? The 14.1%? They are the ones who are bouncing and not getting into rooms anymore, and that’s great.**
Instead of being tricked to perform an action that seconds later is revealed as impossible, they are now nudged towards actions more likely to solve their user tasks.
Of course, we don’t really know how many just give up vs how many actually proceed to download the app or try another browser. Average time on page has increased significantly for iOS/Safari users, that might suggest they keep the tab open and proceed to use another browser.
If not, at least they know why it doesn’t work and how to make it work.
So lesson learned: When you encourage certain users to bounce, they bounce. Which is great, if that’s what you’re aiming for. We didn’t revert to the old landing page.
The big improvements to come will be related to giving better feedback on availability when creating a new room. We’ve already done this on iOS and know from usability testing that it works. The login button will also probably be a thing.
*Number disclaimer: We never did this as an A/B test (yes, shame on us), so seasonality is a concern, but by comparing averages of a 3 month period before vs after the changes, we have get a pretty accurate idea about how the changes affected these numbers.
**How can we be sure? We‘re pretty sure because bounce rates for Chrome users did not change at all after the release.