Every curb is a decision point for 3 million people.
For a 12-hour innovation marathon with an open brief, our team of four chose our own problem, researched it before the event, and built WiseWay: walking routes planned around what a wheelchair, a walker or a stroller can actually get past. It won first place.
My part: I led the team, coordinated the research and the partnership talks with Yanosik, and designed one of the app's two core flows in Figma. A teammate designed the other.
The brief was open. The problem had to be found.
No theme, no user, no spec. We had to choose what was worth building before the clock started.
The marathon had no set topic. Teams could build anything that joined design, technology and business. So the real work started before the event: we picked a problem, tested it with a survey and short interviews, and pitched a first idea to Yanosik, a Polish navigation app.
To narrow the space I asked one question: where does a map lie to the person using it?
The answer was sidewalks. On a map they all look the same. On the ground, one curb without a ramp can block a whole route for a wheelchair, a walker or a stroller. Navigation apps optimise for the shortest path, and accessibility, where it exists at all, is a filter added on top.
People with limited mobility can't tell from a map whether a route is passable for them, so they find out only when they reach the obstacle.
Show a route's real barriers before someone leaves home, and keep that information true as streets change?
For one in five, a bad route isn't slower. It's impossible.
Before the marathon: a survey with about 86 responses, plus seven short conversations on the street with two people with disabilities, three mothers pushing strollers, a friend and a skateboarder.
of respondents run into problems on everyday walking routes regularly, not just occasionally.
Pre-event survey, n ≈ 86say steep ramps and high curbs don't slow them down. They stop them.
Pre-event survey, n ≈ 86people in Poland have a legally confirmed disability, more than the population of Warsaw.
Source: GUS, National Census 2011Four decisions that shaped the product.
Each one with the obvious alternative and why it didn't make the cut.
-
01
Rank routes by "can I get through", not by time.
The route screen leads with what was avoided, such as a missing curb cut or a flagged obstacle, and only then the walking time.
Rejected: an accessibility toggle on a normal map. It hides why a route was chosen, so people can't judge whether to trust it.
-
02
Show slope as a number. Warn on change, not on a fixed limit.
Slope appears in %, with a warning when a stretch is noticeably steeper than the rest of the route.
Rejected: one "too steep" threshold. A power wheelchair and a manual one have very different limits, and a stroller different again.
-
03
Places are verified by people who were there.
Restrooms, elevators and accessible venues come from user confirmations.
Rejected: importing a public register. It says a building has a ramp, not that a van is blocking it today.
-
04
Reporting takes one tap, at the moment of the problem.
A report is one tap on a pre-filled type. The next person confirms it or marks it fixed with one more.
Rejected: a form with photos and a description. Richer data, far fewer reports.
A wrong "all clear" is worse than no data.
A community map is only as good as its newest report. At the marathon I designed how WiseWay behaves when its information is old, missing or contradicts itself.
Every report has a state, and the map shows it
Reported
One person flags an obstacle.
Grey marker · "1 report, 20 min ago"Confirmed
A second person confirms within 48 h.
Solid marker · route avoids itPossibly outdated
No confirmation for 14 days.
Faded marker · "last seen 2 weeks ago"Fixed
Marked fixed, and one more person agrees.
Removed from map · kept in historyEdge cases, designed on purpose
No data for a street
Shown as unknown, never as clear. The route says how much of it is unverified.
Two reports disagree
Both are shown, newest first. The route treats the spot as a risk, not a blocker.
The only route is blocked
Say so plainly, show the obstacle, and offer the nearest accessible transit stop.
Obstacle appears mid-walk
Re-route from the current position and show how much longer the new route takes.
The 48 h and 14-day thresholds are starting points to test with users, not research findings.
First place, and an honest look back.
Revenue would come from accessible venues paying for visibility, only after their accessibility is verified. Money buys exposure, not a pass on the standard.
The jury picked WiseWay because it put people with disabilities at the centre, solved a problem they could recognise from the street, showed real cross-team work, and already had a conversation going with Yanosik.
Yanosik stayed interested after the event. We decided not to take the project further: all four of us were working and studying at the time, and a product like this needs more than spare evenings.
What I'd do differently
-
Bring the screens back to the people we interviewed.
We talked to seven people before designing, but nobody outside the team used the prototype. Watching one wheelchair user try the route screen would have tested our assumptions about slope and curb height.
-
Let people describe how they move.
One warning rule can't fit a power wheelchair, a manual one and a stroller. A short setup question about how you get around would let each route use the right limits.
-
Prototype on real map data.
We stopped at a clickable Figma prototype. A small coded version on OpenStreetMap data would have shown whether the routing works on real streets, not just on our screens.
© Joviri 2026
Joanna Cichoń
Phone: +48 698 450 897
Email: studio@joviri.com