Zenbike

Why this brief existed.

The brief the team was handed was about electric cars. It argued that the near future of the automotive industry is electric, that London had seen a massive shift from conventional to electric cars over the previous few years because car emissions are dangerous for health and the environment, and it asked the team to imagine a London where only electric cars are available, understand what those drivers need, and explore a solution helping them manage their car battery well enough to use the car effectively.

Generative research overturned it. The team went to talk to Londoners and found that most of them would not use a car to commute in the city at all, because public transport is efficient. There was no battery-management problem to design for, because there was barely a driver to design for. The brief, in the team's own words, changed drastically.

There was a real problem underneath - it was just a different one. What people described was the stress of commuting, especially in rush hour: the feeling of being squashed in a crowd, which is overwhelming and costs time, and complaints about how much it costs to travel on TfL.

So the team reported back that the brief was wrong and proposed the problem they had actually found: how might we improve people's work commute experience. Everything after that point is designed against evidence rather than against the assignment.

What the students worked within.

Who the design had to serve

People aged 18 to 45 who live in London and already own a bike but do not use it often. The team chose that group deliberately - the barrier is not access to a bicycle, so the design problem is about motivation and route, not equipment.

Constraints in the brief

• The original brief was about electric-car battery management. The team had to be willing to go back and say the premise did not hold up.
• The first concept was dropped after testing. It involved a partnership supplying rental bikes free or close to free during rush hour - abandoned once the team found an existing app already had a rental-bike partnership in place, and once early user interviews showed their sign-up process was too complex.
• Cycling in London competes with a public transport network the research found people consider efficient. Convenience alone was not going to be the argument.
• The team stated their own limit rather than overclaiming: the concept still needed validation through usability testing.

What the team actually did.

Taken from the team’s own final presentation back to the client — the research they ran, what it told them, and the design decisions it drove. Including the ones that did not work.

The team ran generative research against the brief they were given and let it fail. Rather than salvaging the electric-car premise, they wrote down the insight that killed it - we do not use a car to commute - and generated a fresh set of How Might We questions from what people had actually described.

Picking one, they defined the problem as improving the work commute experience, with the specific pain being rush-hour stress: being squashed in a crowd, losing time, and the cost of travel. They built a persona around Londoners aged 18 to 45 who own a bike but rarely ride it, which is the group where the gap between intention and behaviour is widest.

The first concept was a partnership supplying rental bikes free or near-free during rush hour. Evaluative concept testing killed that too: an existing app already had a rental-bike partnership, and the first round of user interviews found the team's sign-up process was too complex. Two concepts discarded on evidence before the one that survived.

What emerged was an incentive app rather than a bike-supply app - working with the bike people already own, and attacking motivation instead. The added value is a points-per-mile system that converts every mile cycled into points, redeemable as discounts with travel, eco-friendly, wellbeing and gym partners.

The onboarding puts the benefits screen alongside the login and sign-up, so users can see what they are getting in exchange for their personal details before they hand them over - a direct response to the sign-up friction that sank the previous concept.

The landing screen starts the journey with a destination rather than a dashboard, and adds daily tips based on the weather, because weather is the thing that actually decides whether someone cycles on a given morning.

Route selection is where the research shows through most clearly. Rather than the fastest route, the app lets a rider pick a route by noise, pollution and reported stress level - the three things people complained about, made into the primary filter. The team's framing was that a rider should not have to dig through layers of information in other transport apps to find this.

Finishing a journey does three things: it shows the rider what they have achieved, invites feedback on the conditions they met so the accuracy of the route mapping improves for everyone, and awards the miles. The feedback loop makes the stress and pollution ratings a product of the riders rather than a static dataset.

A dashboard holds accumulated points, cycling level, and weekly and permanent challenges, and is where vouchers and discounts are redeemed. The team closed with the honest next step: validation through usability testing.

The deliverables.