Why You Must Solve the First User Experience, First
The Bay Bridge is closed, shutting down the major commute artery for thousands and thousands of people. Luckily, there are public transit alternatives – the BART trains that run under the bay and the high-speed ferries.
That doesn’t mean people are using them. Judging by local news radio reports and anecdotes I’ve heard the last few days, many people would rather drive 15-30 miles out of their way to take alternate bridges through heavily-congested traffic.
Not surprising. It’s always hard to change ingrained user behavior. But the other (fixable) problem is that the public transit agencies in the Bay Area have an atrocious first user experience. Signage on BART is confusing – after living here for 10 years and taking it regularly, I still have to double-check which line I should take (walking back and forth to find the ONE map in the station that will tell me). It’s difficult to find a timetable – if you don’t know how to check schedules online, you’re flying pretty blind.
Most people I know who’ve switched from driving to BART love it – the extra time to read, check e-mail, or nap. The savings on gas, tolls, and car maintenance is a lot more than the price of tickets. But the initial hurdle to get there is too much for most people.
Most product demos paint a picture of “what will be” – once you’re using this product, you’ll be faster. Smarter. More effective. More in control. Have more time. Save more money.
But how you get there – the “first user experience” that carries you from uninitiated user to fully-engaged customer – often gets short shrift. It doesn’t make for a sexy demo. Users are only the “first-time” user once; from a pure time standpoint they’re probably spending less than 1% of the life of their usage in that novice stage.
In software, we tend to think of situations like this as an “edge case” – it happens, but rarely, and it’s not worth devoting resources to fixing it.
This mindset is reinforced by the fact that most software initially launches to a somewhat self-selected beta population of people who are either naturally tech-savvy, or have a problem so severe that they’re willing to overlook a painful first user experience because they need their pain solved NOW.
So the first group of users passes through that “first user experience” stage without a lot of complaint.
Then the next wave of visitors are exposed to the product and not many of them convert to loyal customers. At this point, you may recognize that the first user experience is the problem. But by now, your beta customers have started to demand new features.
You face a choice:
- Invest time in improving your first user experience (so that you can attract new customers)
- Build new features (so that you can keep your existing customers, and new customers would probably need those features anyways…)
Most of us have seen #2 win, time and time again. After all, the newly requested features have been validated – customers have asked for them. There’s no proof that fixing the first user experience will draw in more customers. Most of us have learned that “if you build it they will come” is a dangerous philosophy for a product roadmap.
“What if we spend the opportunity cost to improve this “first user experience”, which, honestly, accounts for at most 5 minutes of a customer’s lifespan with us, and then we don’t see new customers? We’ll have wasted time and money and jeopardized our existing customers!”
If BART (or MUNI, or any other local transit agency) wanted to increase ridership, they could do a lot by introducing clear new signs, easy-to-read maps, easy-to-read fare information, and instructions on how to get schedule information. They could upgrade the confusing ticket machines. Publicize how much the average consumer saves by not driving, the fact that the trains get wireless signal in most places.
But public transit agencies are losing money. What if we invested money and resources into improving the first user experience and no one left their cars? Once you have an established product or service, it becomes incredibly hard to take that leap of faith. If you don’t solve this problem early, it may never be solved.
-->
