PW

UX Design • Team Project

Bike Shop website design

Project summary

A team of four designed a website for a theoretical local Pittsburgh bike shop. We created personas and scenarios to ground the design in real user needs, then selected one scenario to focus on. From there we built wireframes, ran a round of user testing, and iterated into a final high-fidelity prototype.

We centred the work on the tire repair scheduling flow — making it as quick, easy, and painless as possible for someone who depends on their bike daily.

  • Team of 4
  • Pittsburgh, PA
  • Persona & scenario
  • Wireframing
  • User testing
  • Interactive prototype

Persona

John Baker — construction worker, age 28

John lives in the city with no room for a car. He bikes to construction sites carrying everything in a backpack. When something breaks, he needs a fast and affordable fix with minimal friction.

  • Job

    Construction worker

  • Gear

    iPhone, backpack, tool belt

  • Transport

    Depends on his bike daily

  • Need

    Fast, easy access to repairs

I depend on my bike to get around. I need a durable bike and easy access to repairs.

John Baker, persona

Scenario

John rode over a sharp object at a job site and got a flat tire. He needs to schedule a repair as quickly as possible. This is the journey the whole design was built to serve.

  1. John gets a flat tire after riding over a sharp object at the construction site.

  2. He visits the bike shop's website and navigates to repairs via the nav bar or a homepage call to action.

  3. He reads about the repair process and learns about pricing and loaner bike availability.

  4. He fills out step 1 of the scheduling form — selecting repair type, bike brand, and model.

  5. He selects a location, then picks a date and time using the calendar and time slot picker.

  6. He enters his name and contact info, pays a $5 booking fee, and confirms the appointment.

  7. He receives a confirmation email with his appointment details.

  8. He brings his bike in at the agreed time for the repair.

  9. When the repair is complete, he receives a notification that his bike is ready for pickup.

Wireframes

We wireframed all key screens before moving to visual design, keeping layouts simple and focused on the scheduling flow.

  • Wireframe of the homepage: a bicycle illustration behind a hero slider, with a yellow Schedule A Service Appointment Here! button, above stacked Shop and Service photo panels.
    Home
  • Wireframe of the hamburger menu, listing Home, Shop, Service, About and Contact.
    Hamburger menu
  • Wireframe of the repairs landing page, headed Bike Repairs and Services above a yellow Schedule A Service Appointment Today button and two placeholder information sections. This is the call to action user testing found misleading.
    Repairs home
  • Wireframe of step 1 of 3, headed Basic Repairs: a What had to be done dropdown set to Tire fix, a bike model field, a checkbox asking whether the bike was bought in the US, and a comments box.
    Step 1 — Repair type
  • Wireframe of step 2 of 3: a location dropdown above a June calendar and a row of selectable time slots.
    Step 2 — Date & time
  • Wireframe of step 3 of 3, quoting a repair cost of $35 upfront above name and email fields, a Pay Online or Pay In Store toggle, and card details.
    Step 3 — Payment
  • Wireframe of the confirmation screen reading Your repair booking was successful, with a note that an email or text will follow.
    Confirmation

Wireframe decisions

We focused on reducing friction at every step of the scheduling flow.

  • A hero slider with a prominent call to action on the homepage lets users reach the repair flow in one tap.

  • The scheduling flow is split into three discrete steps — repair type, location and date/time, then contact and payment — to keep each screen focused.

  • The calendar only reveals available times after a location is selected, preventing confusion from blocked-out dates.

  • Users can choose to pay online or in store, giving flexibility for those unsure of the final cost upfront.

User testing

Participants navigated the wireframes with minimal difficulty, but testing surfaced two issues that shaped the final design.

Issues found

  • The "Schedule a Service Appointment Today" call to action was misleading — it sent users directly to basic repairs only.
  • Users were uncertain about repair costs before bringing in their bike.

Changes made

  • Removed the confusing services call to action — with only two repair options it wasn't needed.
  • Switched to a $5 reservation fee model, with the remainder paid after the bike is inspected.

Both fixes are visible in the screens below. The generic button on the repairs page became a specific "Schedule a Bike Repair", the step 1 heading changed from "Basic Repairs" to "Schedule Repair Appointment", and the upfront $35 quote became a $5 booking fee with the balance settled after inspection.

Final prototype

The final prototype was designed around a Pittsburgh aesthetic — bold black and yellow branding with a local feel. The screens below cover the complete repair scheduling journey.

  • The final homepage, with the yellow arched logo on black, a rider photograph, the headline A Bike for you, and the mission section Make riding safe in Pittsburgh.
    Home
  • The final repairs landing page: a Bike Repairs and Services photo banner above a Bike Repair section with a yellow Schedule a Bike Repair button — the specific label that replaced the misleading generic one.
    Repairs home
  • Step 1 of the final flow, headed Schedule Repair Appointment, with a yellow step indicator and fields for repair type set to Flat Tire, bike brand, bike model, a checkbox for whether the bike was bought from the shop, and comments.
    Step 1 — Repair type
  • Step 2: a location dropdown set to 123 Smallman St, a June calendar with the 11th selected in yellow, and time slots with 13:00 selected.
    Step 2 — Date & time
  • Step 3: a $5 booking fee with a note that the price is finalized after staff inspect the bike, name and email fields, a Pay in Store or Pay Online toggle, and PayPal, Google Pay and Apple Pay options above a Book Appointment button.
    Step 3 — Payment
  • The final confirmation screen reading Your repair booking was successful! on a soft yellow glow, with a Back Home button.
    Confirmation

What I learned

This project reinforced how much user testing can change a design — even small usability issues, like a misleading call to action label, can meaningfully disrupt a user's flow. Catching that early in the wireframe stage made it straightforward to fix before we invested time in high-fidelity visuals.

Working through a full persona and scenario before touching the interface also made our design decisions feel more grounded. Rather than guessing what a user might need, we had a specific person and situation to design for — which kept the team aligned and made tradeoffs easier to reason through.

On the collaboration side, splitting the scheduling flow into distinct steps was something we debated as a team before committing to it. Seeing users navigate it smoothly in testing validated that decision, and it was a good reminder that clarity often matters more than brevity when stakes are low but confusion is costly.

The project also highlighted that good UX doesn't stop at the screen — it has to account for the real world the user lives in. Offering both online and in-store payment options for the booking fee is a simple example: not everyone wants to enter card details on their phone. Bridging that gap between the digital experience and the physical visit made the product feel more trustworthy and considerate of how people actually behave.