BCN --:--
03 / 06Service ecosystem · B2B + B2C

Cicles JK

Designing the bicycle-rental ecosystem — the platform staff use to run the fleet, and a proposed booking flow for customers.

Role
UX/UI designer
Timeline
2025
Context
Client project · 100x100net
Products
Admin platform · Public booking (proposal, not built)
Users
Staff · customers
Backstage — staff
Cicles JK dashboard: bookings, fleet by category and returns
Mobile booking step 1: bikes
01 — Context

A bike-rental shop on the Costa Brava.

Cicles JK rents electric, road, gravel, mountain, touring, junior and kids’ bikes from Palafrugell — by the day, the week or longer, to individuals, hotels and campsites, with accessories, delivery and pick-up. Bookings, fleet, customers, prices and holidays were all handled by hand. The project brought the whole operation into one platform, and proposed how customers could book directly.

02 — The ecosystem

Behind every booking, an operation.

Renting a bike isn’t just a booking screen. The bike has to be available, in the right place, maintained; staff need the rental details; it has to come back, be checked and become available again. So I designed the service, not a single interface.

Frontstage — what customers would see (proposal)
  1. Bikes & dates
  2. Details
  3. Delivery
  4. Payment
  5. Confirmed
↕ one booking, shared dataBackstage — what staff manage
  1. New booking
  2. Bikes → Rented
  3. Deliver / collect
  4. Register return
  5. Free / Workshop
The internal product exposes complexity because staff need to manage it. The customer experience hides it, so people can simply rent a bike.
03 — Internal platform

The backstage.

The dashboard answers the morning questions first — active bookings, bikes out, returns this week, payments pending — then shows the fleet by category and state, and the rentals that end soon. Every bike has a state that decides whether it can be rented, so availability is never just “does the bike exist?”.

LlogadaRented — out with a customer
LliureFree — ready to book
Al tallerWorkshop — in maintenance
Cicles JK dashboard: bookings, fleet by category and returns
Bike fleet with state per bike
04 — Returns

Closing the loop.

A rental only ends when the bike is back and checked. The return flow goes bike by bike: good condition, to the workshop (with what’s wrong and a photo), or not returned — and checks every accessory, so a missing GPS is charged before the booking closes.

That single screen is what turns a bike from “Rented” back into “Free” — or into “Workshop” — keeping availability honest for the next booking.

Booking record with delivery and bikes
Register return: each bike marked good, workshop or missing
05 — Customer experience

The frontstage — a proposal.

For customers, I proposed a public booking flow that hides all of that: choose dates and a type of bike (with size on the card), add accessories, enter your details, choose shop pick-up or delivery to your accommodation, pay, and get a confirmation that tells you exactly what happens next.

Design proposal — not built yet
  1. 1Bikes
  2. 2Details
  3. 3Delivery
  4. 4Payment
  5. ✓Confirmed
Public booking: choose a type of bike and size
Public booking: delivery and pick-up
Public booking: confirmation with what happens next
Public booking portal — design proposal for Cicles JK. Not yet built.
06 — The decision

Why types, not models.

If a customer books one specific Atala Cult 8.1 and that bike goes to the workshop, the booking breaks. If they book “an electric bike, size M”, staff can hand over any free one. Booking by type protects availability — the backstage stays flexible while the frontstage stays simple. It also matches how people choose a rental: by type, size and price.

I explored three early versions. The proposal builds on the third, and refines it: size is picked on the card, availability shows on each type (“Available”, “Last 3”), and anyone unsure gets a WhatsApp shortcut to the shop.

Early version 1By type · 3 steps
Early version 1: delivery and payment on one step
  • + Flexible for the shop
  • – Delivery, addresses and payment crammed into one last step
Early version 2By model · 3 steps
Early version 2: booking by bike model
  • + Familiar e-commerce pattern
  • – A bike in the workshop breaks the booking
ProposalBy type · 4 steps
Chosen
Public booking: choose a type of bike and size
  • + Protects availability
  • + Size and availability on each card
  • + Delivery gets its own step
07 — Responsive

Built for the street, not the desk.

People rent bikes on holiday — walking around town, at the hotel, a few minutes before riding. So the booking proposal works one decision per screen, with a sticky total and “Continue” always within thumb reach, and delivery times as big tappable slots.

Mobile booking step 1: bikes
Mobile booking step 2: details
Mobile booking step 3: delivery
Mobile booking step 4: payment
Mobile booking confirmation
Mobile booking — design proposal, not yet built.
08 — Bridging both sides

One booking, both sides.

Following a single booking through the system shows why the two products have to be designed together.

  1. 01CustomerBooks 2 electric bikes (M, L) and a junior bike for 14–21 October, delivered to the hotel
  2. 02SystemThe booking appears on the dashboard and in Bookings
  3. 03SystemA free bike of each type and size is assigned → Rented
  4. 04StaffPrepares bikes and accessories, delivers to the hotel at 11:00
  5. 05CustomerRides the Costa Brava
  6. 06StaffRegisters the return bike by bike: good → Free, damaged → Workshop, missing GPS → charged
09 — Final product

The details that make it run.

Bookings with filters by customer type, a calendar where holidays and seasons drive the price table, customer and bike records with their full history, and accessories managed like stock.

Calendar of seasons and holidays driving the price table
Bookings list with filters by customer type
Client record with rental history
Bike record
10 — Learnings

Designing connected experiences.

Cicles JK taught me to design frontstage and backstage together: every choice a customer makes becomes work for someone in the shop. Designing for staff and customers at once — B2B and B2C — meant one consistent model of bikes, states and bookings across every touchpoint, with business rules like holidays, prices, delivery windows and returns shaping the UX.

2
sides — staff & customers
17
admin screens
10
proposal screens, desktop + mobile
3
bike states drive availability
Next project — 04 / 06Giave