Iomob
As the sole designer, 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, launching an enterprise pilot with 80 users.
Mobility
10 months
2019
At a glance
0→1 product: 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).
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.
No single product handled multi-city planning, combined transport modes, and ticket purchasing in one place.
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.
I needed to validate three things: whether people cared about discovery, whether they could understand multi-modal routing, and whether they would switch to a single platform for the full experience.
I built that into a clickable prototype and tested it with 28 travellers and commuters in parks across Barcelona.
72% immediately understood the value of combining transport types into a single trip. The concept didn’t require explanation.
Integrated ticketing had the biggest impact, highlighting how much friction came from switching between multiple apps to complete a journey.
Some users expected more flexibility within a trip, trying to leave and return to journeys in ways the experience didn’t yet support.
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 moved forward with a clear direction: focus on reducing the friction of planning, booking, and managing trips across multiple providers, rather than helping people decide where to go.
The 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. This revealed that the real value was in the platform, not the consumer 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.
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.
Modular Architecture for a Non-Linear Experience
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.
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.
This approach made it clear that the modules were independent but interconnected.
Door-to-Door at the Core
The next challenge was the core journey: planning and taking a multi-modal trip.
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.
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.
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.
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.
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.
80% didn’t realise they could change transport types within a route, pointing to a discoverability issue, not a problem with the concept itself.
Tourists preferred public transport but would sometimes use taxis and scooters 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 “something to look forward to.”
Step-by-step navigation exposed a tradeoff: 88% expected it, but only 49% said they’d use it.
The Pilot
The pilot let us test the product 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. 61% said they would switch from their current setup, 18% needed direct invoice support, and 29% wouldn’t switch because their habits were too strong or their company already handled travel.
This clarified our next priorities. Business users had the highest potential value, but needed a much stronger reason to change.
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 also became central because it removed the biggest point of friction. Its longer-term success would depend on whether mobility providers allowed payment integration.
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.
In the end, the pandemic slowed the wider rollout with the first client, and the work was deprioritized with other partners.