Sold to the parent, used by the teenager.
Roadling is an app for first-time drivers. The person who downloads it is not the person who uses it, and almost every decision in the product follows from that.
Start from who pays.
Two people have to be satisfied and they want opposite things. The parent wants visibility and reassurance. The teenager wants to not feel supervised. A product that serves only one of them gets deleted, and which one deletes it depends on which one you served.
So the design question is not what features a new driver needs. It is what a worried parent will pay for that a teenager will still tolerate.
Three moments.
The product is organised around the three moments that actually matter to a first-time driver, rather than around a curriculum.
Before they go. While they are out. And the moment something goes wrong, which is the one every other app treats as an edge case and is the one the parent is actually buying for.
Prepared. What to check and know before pulling out.
Guided. Support while they are driving, without a voice in the passenger seat.
Alert. The moment it goes wrong, in a form a panicking teenager can actually follow.
Where it is.
In build, and the name is still going through clearance, so treat it as a working title.
What exists now is the structure and the flows. The build follows the same rule as everything else here: the part most likely to fail gets built first.
What this proves
- I start from who pays and what they are afraid of, then design backward.
- I can hold two conflicting users in one product without splitting the difference into something neither of them wants.
- I name the unfinished thing as unfinished.
Tell me what you are trying to finish.
Design backward from the person holding the credit card.
Send me the project that has been sitting there. I will tell you what I would do with it and whether I am the right person to do it.