How bad user feedback changed my indie Travel App - and saved it from certain failure
Date: 2024-03-01 | create | tech | business | travelmap |
I'm building a travel app that creates maps of your travels - TravelMap. My wife and I do a good bit of traveling so I like having an easy way to reflect and share where we've been - ideally one more engaging than a very long list.
After building and releasing the initial version, I used it to map my 2023 travels. It worked fine so I figured it was ready for broader release.
So I enlisted my perfect customer - my wife. She loves traveling and posting things on socials so I figured if she didn't want to use this thing no one would.
The app allowed me to map my own travels so surely she would be able to use it to map hers as well. After all, we both went to the same places.
As you might expect, she did not in fact map her own travels. Software rarely survives initial contact with the real world.
I thought it would be a fun case study to share what went wrong and some of the evolutions of the app to survive first contact. After all, we're always testing in prod so might as well find good techniques for doing so fast and safe.
In the rest of this post I'll share the feedback I got from my app's first user and how it's changed the app for good.
The State of TravelMap
First let's talk about the state of the app before it hit prod.
It was basically a barebones website with:
- A big map
- A table with LatLong coordinate rows including some CRUD controls
When the coordinates change, the map updates.
This was enough functionality for me to create a basic map of my 2023 travels. But ofc it was not enough for my first user.
Problem 1: No one knows LatLong Coordinates
My wife referred to this first iteration as "unusable".
"No one knows LatLong coordinates! I just want to type in the location and put it on the map. What do you expect me to do - go lookup the coordinates and copy them into the site?!"
In fact that is what I expected people to do. That's what I did to make my 2023 travel map so I expected others to do so as well. Sure it was clunky but it did the job I hired it for - making me a map.
But I think this is a good lesson - it doesn't really matter what you think / want. It really matters what the customer wants.
You don't know what the customer wants. I (and I'd guess many others) often think we know what the customer wants. But the truth is you may not be representative of the customer. Even if you have the same problem as your customers there may be other variables that cause the solutions / understanding to not apply. So in the end you must test in prod to find out.
Customers have low patience. I (and I'd guess many other engineers) tend to have a pretty thick skin when it comes to technology problems. We're used to things breaking and the work required to debug it - largely that's what we're paid to do. But most people (and certainly most paying customers) do not have this patient curiosity. They hired this thing for a job and it either does it or it doesn't.
So here this thing that I thought was "nice-to-have" actually turned out to be pretty important. So important that I couldn't even get my wife to use it.
If I'd kept building based on my own experience without testing in prod, I would've never known this was an issue and TravelMap likely would've wilted away with zero usage, joining dozens of my other dead projects.
So - I built a very simple version of this feature:
- You type in an address
- It spits out LatLong coordinates
- You can add it to the map
Nice! Crisis averted! Now it will surely work!
So I gave it back to my wife... and she used it! She started putting stuff on the map and everything was dandy.
Til it wasn't.
Problem 2: I can't figure out which location is which
My wife had a map with several locations on it - one in Spain, one in New York, one in San Diego, and one in... Africa? But we hadn't been to Africa. Thus the problem.
With several markers on the map, each described by its LatLong coordinates:
- She couldn't figure out which location was the incorrect one
- Because she couldn't identify it, she couldn't delete it
- So she gave up
On reflection, this was largely due to the solution to Problem 1 not actually solving the full problem.
- You can search by address to put things on the map
- But the locations still appear as LatLong
- So when you have several locations (>5) it becomes increasingly hard to differentiate which is which because people don't really think in coordinates
So I went back to the drawing board and ended up with a simpler design that allows you to label markers while still providing LatLong visibility (cause that's how locations work duh). This meant moving the LatLong controls lower and removing the ability to update them but overall I think it makes the interface simpler.
Again this is something I probably wouldn't have built for myself because it doesn't really seem necessary - LatLongs are how coordinates work so they must be good enough.
But prod proved my assumptions false and in the end prod is the only source of truth thus why it's good to test in prod.
Next
So this is where TravelMap stands today. But my wife has promised to try it once again with the new features so I can't promise it will be the same by the time you read this - change is inevitable.
An app never deploys into the same prod twice. For it's not the same prod, nor it the same app.
What do we do about this? We test in prod.
If you liked this post you might also like:
Want more like this?
The best / easiest way to support my work is by subscribing for future updates and sharing with your network.