01
Result
I took Iomob from pre-funding wireframes to a consumer travel app. Four months later, we killed it and rebuilt it as a white-label platform.
Role
Sole product designer
Team
Founders, CTO, COO, Engineers
Company
Iomob | Mobility | 0 → 1
Timeline
10 months, 2019
92%
Task completion in the core journey, across 3 studies and 61+ participants.
61%
Of pilot users said they would switch from their current setup.
91%
Positive response to integrated ticketing.
0 → 1
Owned design from pre-funding wireframes to an enterprise pilot with 80 users as the sole designer.
Client-driven pivot
Led the shift from consumer app to white-label platform after identifying infrastructure as the core value.
Platform design
Built a modular system enabling flexible, multi-client deployments without custom builds.
Research impact
92% task completion, 61% willingness to switch, and 91% positive response to integrated ticketing (3 studies, 61+ participants).
02
Problem
Travel is a disconnected experience
I analysed 12 travel and commuter apps and found the same pattern: each provider operated in isolation, forcing people to switch between multiple apps, accounts, and payment methods to complete a journey.
The founders were convinced the opportunity was to build a product that covered the entire journey, from discovering a destination to booking every leg of a trip
No single product handled multi-city planning, combined transport modes, and ticket purchasing in one place.
I needed to validate three things
Whether people cared about discovering locations nearby.
Whether multi-modal routing was discoverable.
Whether people would switch from their current setup..
I built a clickable prototype
I tested the prototype with 28 travellers and commuters in parks across Barcelona.
Consumer app prototype: explore, search, trip planning, live journey and booking screens.
03
Research
72%
Of participants the value of combining transport types into a single trip.
12 competitors analysed
28 test participants
4 prototype iterations
Some users expected more flexibility within a trip, trying to leave and return to journeys in ways the experience didn’t yet support.
Integrated ticketing had the biggest impact, highlighting how much friction came from switching between multiple apps to complete a journey.
Integrated ticketing: routes from Renfe, OUIGO and iryo in one booking, one payment and one ticket.
Useful but not always
The Explore feature was occasionally useful but mostly for tourists. Locals mostly want to plan future trips. It wasn’t a strong enough reason to choose the product.
We secured our next funding round and dropped destination discovery. The product would focus on planning, booking and managing trips across providers.
04
Pivot
Four months in, our first enterprise client changed how we understood the product.
They needed our routing and booking infrastructure to improve their own product, which already had an established user base but a poor user experience.
Explore was the first feature to go. It had no clear path to revenue, relied on expensive APIs, and would have put us in direct competition with products like Google Maps.
The real value was in the platform, not the consumer experience
We pivoted to a white-label model
I led the redesign of the product as a platform enterprises could brand and configure, while keeping the experience coherent for the user.
Every design decision had to work across different clients, not just one. The challenge now wasn’t just designing a product, but a system that could flex without feeling fragmented.
Trip history: bookings from different providers in one list.
05
System
Modular Architecture for a Non-Linear Experience
I led the redesign of the product as a platform enterprises could brand and configure, while keeping the experience coherent for the user.
The white-label model introduced a new constraint: different clients needed different capabilities, so users could enter the product from multiple points instead of a single, linear flow.
This drove me to design the system as a set of independent modules that were independent but interconnected..
I mapped the entry points and how each one connected to the rest of the product.
This clarified the scope of the product and made it easier to distinguish between modules that changed by client, like trip planning, and modules that stayed stable, like trip history.
That let us enable or disable capabilities per client without rebuilding the product each time, and gave design and engineering shared priorities of what needed to ship together.
06
Journey
Door-to-Door at the Core
The next challenge was the core journey: planning and taking a multi-modal trip.
To validate, I needed to understand whether the routes made sense, whether people cared more about time or route, how they planned and booked longer trips, and when they wanted trip assistance.
Client requirements dictated which transport types we could support first. I needed to balance immediate client needs with a longer-term direction: combining rail, taxis, e-bikes, and public transport into a single, seamless trip.
Taxis, trains and electric scooters, each with its own journey states and ticket.
I built a prototype and tested it again in parks across Barcelona to see how people moved through the journey, not just how they reacted to the idea.
07
Signals
92%
Of participants completed all tasks successfully, which showed the core journey was usable.
Over four days, I tested with 33 participants. 92% completed all tasks successfully, which showed the core journey was usable.
Signals That Shaped the Product
Over four days, I tested with 33 participants. 92% completed all tasks successfully, which showed the core journey was usable.
Didn’t know they could plan a trip this way
85%
Expected to be redirected elsewhere to complete a booking
91%
Didn’t realise they could change transport types within a route
80%
Saved an upcoming trip
76%
Combining transport types was familiar but 85% didn’t know they could plan a trip this way, and 91% expected to be redirected elsewhere to complete a booking. Keeping everything in one place was a meaningful shift.
Six route options for one trip, mixing walking, metro, Renfe and OUIGO, then the step-by-step route.
Tourists preferred public transport
They would sometimes use taxis and scooters too because navigating timetables felt overwhelming. Locals preferred public transport and sometimes e-bikes.
Saving was a strong signal of intent. 76% saved an upcoming journey, and one participant described it as a thing to look forward to.
Change transport: swapping a leg inside the route.
80% didn’t realise they could change transport types within a route, pointing to a discoverability issue, not a problem with the concept itself.
Step-by-step navigation
What people expect and what they use often differ. Talking to users shows you that gap in a way surveys don’t.
Active trip: a train leg and a scooter, each with its own control.
Expected step-by-step navigation
88%
Use step-by-step navigation now
49%
08
Travellers
Business users
Needed to combine taxi and train in a single flow, with clear receipts.
Frequent travellers
Valued having all providers in one place with easy access to tickets.
Tourists
Planned multi-city trips and preferred to book everything in advance.
Business users stood out as the high-value segment
But they are also the hardest to convert. Their expectations were higher, and their habits harder to change. This shifted our focus to the scenarios where the value was strongest and most defensible.
09
Pilot
61%
Said they would switch from their current setup.
We tested inside the client’s environment with 80 internal users who travelled regularly for work or leisure, without committing to a full rollout.
I also pushed for access to the business lounge at Barcelona’s main train station to spend more time with our high-value business travellers, this time using an early version of the real product.
The taxi–train–taxi flow stood out
Especially when it could be booked in a single payment. That was the clearest sign that the product was solving a real coordination problem.
Adoption was a different challenge.
Said they would switch from their current setup
61%
Needed direct invoice support
18%
Wouldn’t switch: habits too strong, or the company already handled travel
29%
This clarified our next priorities. Business users had the highest potential value, but needed a much stronger reason to change.
10
Reflections
Ten months from wireframes to an enterprise pilot
The early concept worked, but the pivot showed where the value actually lived. From there, what survived did so because users consistently proved it mattered.
In-app ticketing removed the biggest friction
It became central because it removed the biggest point of friction. Its longer-term success would depend on whether mobility providers allowed payment integration.
Focus on the power user
Sometimes there’s only time to focus on the power user. That’s not a compromise, it’s a strategy. If the core experience works for the most demanding user, the rest can be refined with time.