WheelieProduct story · 4 min read
Different starting points. One place to meet.
A group-riding beta that connects rendezvous planning, rider location, helmet voice, and ride summaries.
Read the case study
Actual Android sign-in screen. Ride planning and group features are described from the project documentation; no account or rider location was used.
View full size ↗01 The problem
Which coordination decisions belong before the group is moving?
Group riding begins before everyone reaches the same road. People start in different places, need a meeting point, and can lose contact after setting off. Wheelie brings planning, group location, and helmet voice into one service concept, with large, simple controls as an explicit design constraint.
Designed for Ride organiser coordinating a group. Review a rendezvous and understand group connection status.
User context Design assumption
Preparing meeting points and keeping a group in contact.
- The friction
- Different starting places and physical interaction constraints complicate coordination.
- Design implication
- Prioritise preparation, large targets, and clear connection feedback.
Example situation · illustrative scenario. Imagine a group starting from different parts of a city. Sharing a destination does not yet answer where to meet or how to stay coordinated once the ride begins.
02 The direction
Coordination comes first
The ride starts with a rendezvous. Planning, rider location, and helmet voice solve different moments of the same service.
Beta artifact · controlled evaluation next
My direction. I connected those moments while treating attention, large controls, and clear connection states as design constraints.
Process and product scope
I framed three moments: meeting before a ride, coordinating with the group, and looking back afterwards. Each moment needs a different level of detail and attention.
The constrained physical context informs large targets, restrained choices, and clear connection states. The next evaluation belongs in stationary or controlled settings; the beta is not evidence of safe in-motion interaction.
- 3
- documented product pillars
- 64px+
- primary target intent
- Beta
- not a safety validation
- Plan
Review a suitable meeting point while stopped.
- Coordinate
Know who is where and whether the information is current.
- Reflect
Tell the ride’s story after it is over.
03 The outcome
Prepare together. Coordinate clearly. Reflect later.
I organised the beta around meeting before a ride, coordinating with the group and reviewing the ride afterwards. Meeting points, group location, helmet voice and summaries serve those different moments. Large controls are a design intention, not evidence that the app is safe to operate while moving.
More about the experience
- A connected service. The three pillars cover meeting, communication, and ride summaries.
- A beta with evaluation ahead. Accessibility and glove polish remain in progress.
04 Design decisions
Change the interface around the ride.
Open a decision to see the reasoning and trade-off.
01Begin with a rendezvous, not just a destination
The service computes a meeting point for people starting from different places.
Why this matters. The group’s coordination problem exists before shared navigation can begin.
The trade-off. A fair computed point may not be a suitable physical stopping place; people need to review the suggestion.
02Reduce reliance on precise gestures
The design calls for large primary targets and simple tap/drag interactions.
Why this matters. A constrained physical context should affect the interface model from the start.
The trade-off. Large buttons alone cannot establish safe in-motion use. Evaluation should begin in stationary or controlled settings.
03Separate coordination from reflection
Live map and voice support the current group; ride summaries serve the post-ride story.
Why this matters. Different moments deserve different information and levels of attention.
The trade-off. Social summaries can create incentives around speed; the content priorities deserve review before wider use.
05 Reflection
Good coordination should ask for less attention at the busiest moment.
I would move as much setup as possible into the time before the ride. The next checks belong in a stationary or controlled setting, with particular attention to connection status and anything that asks the rider to look away.
What I would evaluate next proposed work
- test rendezvous planning and headset controls while stationary, then assess attention demands under an appropriately controlled protocol.
- poor connectivity, location permission changes, unavailable voice, battery use, and clarity about whether rider positions are stale.
Less scrolling. A film worth saving.