Yahoo! JAPAN · 0 → 1 · 2021–2022
I owned this one from before it was a product — market research and concept proposal through interaction design — and used it to unify navigation across cars, walking, and bicycles.
Bicycle navigation was a gap in Yahoo's mobility lineup. I took part from stage zero — not just product design but pre-design planning: market research, concept proposal, and requirements definition. The two hardest design problems were a weather function that could scale to every transport mode (I prototyped four interaction patterns and chose by evidence) and unifying the navigation screens of cars, walking, and bicycles so users always know which mode is running — solved in collaboration with the other two navigation teams.
The project ran in two stages — a planning stage to prove the product was worth building, and a design stage to build it right. I was responsible for both, which is rare and was the point: requirements written by the same person who has to design against them tend to be honest.
As main designer and planner from stage zero, my responsibilities covered market research, planning and proposing the concept, defining requirements, interaction design, wireframing, prototyping, and usability evaluation — working closely with the PM, planner, and engineers.
Research showed weather is the deciding factor for whether people ride at all. We already had a Rain Radar (6-hour rainfall forecast) in the Map app — the question was how to bring it into navigation in a way that could later extend to car and walking modes too. I prototyped four interaction patterns and evaluated them against learning cost, map visibility, and extensibility:
Plan A — Button tap: easy to switch time by tapping, but checking weather beyond an hour takes several taps, the forecast range is unclear, and the map gets covered.
Plan B — Slider: low learning cost (same UI as the known Rain Radar) and easy to reach far-future times, but fiddly to tap precisely, and the map still gets covered.
Plan C — Switch cards (chosen): low learning cost, easy time switching, the map stays visible, and — decisive for the long term — transport modes map naturally onto cards, so the same pattern extends to car and walking navigation.
Plan D — Switch screen: matched C on most criteria, but you can't change transport mode while the weather view is open, and engineers flagged a meaningfully higher build cost.
User voices told us people got confused about which navigation mode was currently running — the three modes deliberately shared a UI family, which made them hard to tell apart. I explored dialog, snackbar, and icon-based solutions, then collaborated with the walking and car navigation teams to ship a unified navigation screen that keeps the shared design language while always showing the active mode.
The design was completed and handed to development. The weather-card pattern and the unified navigation screen were designed to outlive the bicycle feature itself — they are system decisions, not feature decisions.
Owning the planning stage changed how I design: when you've written the business case yourself, you stop defending screens and start defending outcomes. And cross-team UI unification taught me that the hardest part of systems design is not the components — it's the negotiation.