Mobile Mechanic App UX/UI Case Study

01 — Discovery & Requirements

Understanding the problem before designing the solution

Problem Statement

Roadside breakdowns are high-stress situations where every additional tap increases frustration and delays getting help. Many existing roadside assistance apps require drivers to complete lengthy forms, manually enter vehicle information, navigate multiple screens and wait until after diagnosis before a mechanic is dispatched. The result is unnecessary cognitive load during an emergency. The opportunity was to redesign the experience around one principle: Dispatch help first. Gather richer diagnostic information afterwards.

How Might We

How might we help stranded drivers request roadside assistance in under one minute while still giving mechanics enough information to arrive prepared?

The Challenge

Imagine you're stranded on the motorway.

Your phone battery is on 8%.

It's raining.

You don't know what's wrong with your vehicle.

Yet the app immediately asks you to fill long forms before anyone is even looking for help.

That became the starting point for this project.

Industry Observation

Existing roadside assistance experiences often optimise for collecting data instead of reducing stress.

Users are expected to:

Identify the vehicle issue

Enter vehicle details

Select service types

Confirm multiple screens

Wait before dispatch begins

During an emergency, these steps increase anxiety rather than confidence.

Product Vision

Mobile Mechanic was designed around a different philosophy.

Get the mechanic moving first.

Once help has been dispatched, AI can continue gathering useful information while the driver waits.

That approach reduces friction without reducing the quality of information mechanics receive.

Constraints

High stressPoor connectivityLow batteryUnknown vehicle issuesDispatch speedTrust

02 — Research & UX Strategy

Understanding the existing experience

Competitor AnalysisUser Journey MappingPersona DevelopmentHeuristic EvaluationTask Flow Analysis

01

Users prioritise speed over complexity

During a vehicle breakdown, users want immediate assistance and are unlikely to engage with lengthy forms or complex processes.

02

Trust drives mechanic selection

Users rely heavily on reviews, ratings, experience, and verification badges when deciding which mechanic to book.

03

Uncertainty increases stress

Not knowing arrival times, repair costs, or service progress creates anxiety and reduces confidence in the experience.

04

Many drivers struggle to explain vehicle issues

Users often lack technical knowledge and find it difficult to accurately describe mechanical problems.

05

Real-time visibility improves confidence

Live tracking and proactive status updates help users feel informed and in control throughout the service journey.

Personas

Journey Map

Competitive Analysis

Understanding the market

Before designing the experience, I reviewed several roadside assistance products to understand how drivers currently request help and where opportunities existed to improve the experience.

The review focused on three questions:

How quickly can a stranded driver request help?

How much information is required before a mechanic is dispatched?

Where could AI reduce user effort without slowing down assistance?

Products Reviewed

AA UK

Strengths

Trusted UK roadside assistance brand

Clear service offerings

Familiar experience for existing members

Weaknesses

Multi-step request process

Heavy reliance on manual information entry

Limited guidance for users unsure of their vehicle problem

RAC

Strengths

Well-established roadside network

Reliable tracking after dispatch

Good customer support

Weaknesses

Dispatch depends on collecting extensive information first

Users are expected to know their vehicle issue

Diagnostic assistance is minimal

HONK

Strengths

Simple booking experience

Live technician tracking

Transparent pricing

Weaknesses

No intelligent diagnosis support

Mechanics receive limited contextual information before arrival

Little assistance for non-technical drivers

Key Opportunity

Across all products, I noticed the same pattern:

Users were required to provide detailed information before help was dispatched.

For someone stranded at the roadside, this increases stress and delays the one thing they care about most:

Getting help on the way.

This insight became the foundation of the Mobile Mechanic experience.

Design Direction

Rather than delaying dispatch, Mobile Mechanic separates the journey into two distinct phases:

Dispatch first using only the minimum information required.

Diagnose while waiting using AI, voice input, photos and dashboard warning light scanning.

This allows mechanics to prepare for the likely issue without slowing the initial request.

Why this mattered

Competitive analysis helped shift the design focus away from collecting more information upfront and towards reducing friction during the most stressful moments of the user journey.

UX Strategy

Turning insight into product direction

Product Goal

The goal of Mobile Mechanic was to redesign the roadside assistance experience around speed, simplicity and confidence. Instead of asking stranded drivers to complete lengthy forms before help could be dispatched, the product focuses on getting assistance moving as quickly as possible using only the minimum information required. Once a mechanic has been assigned, AI continues the experience by collecting richer diagnostic information through voice, photos and dashboard warning light recognition. This allows mechanics to prepare before arriving without delaying emergency assistance. Every product decision was guided by one principle: Dispatch help first. Diagnose while waiting.

Success Criteria

Reduce request timeReduce cognitive loadImprove mechanic preparationIncrease user confidence Create an end-to-end experienceBuild trust

Product Principles

Dispatch before diagnosisDesign for stressAI should assist, not replaceProgressive disclosureTrust through transparencyAccessibility first

Decision Log

Decision 01

Dispatch help before completing AI diagnosis

The initial journey required users to provide diagnostic information before a mechanic could be assigned. I moved diagnosis after dispatch so stranded drivers could get help moving immediately while AI gathered additional information during the wait.

Intended impact: The core request journey was reduced to two steps, making the experience faster and lowering cognitive load during stressful roadside situations.

Decision 02

Simplify the help request flow

Earlier concepts introduced too many screens before users reached dispatch. I consolidated the journey into identifying the problem and confirming essential dispatch details.

Intended impact: Users only need to select what happened, confirm their location and contact details, then dispatch help.

Decision 03

Move AI diagnosis into the waiting experience

AI diagnosis is a key product differentiator, but requiring it before dispatch conflicted with the user's immediate goal. I repositioned it as an optional assistant while the mechanic is travelling.

Intended impact: AI adds value without becoming a barrier to receiving roadside assistance.

Decision 04

Use multimodal issue reporting

Drivers may not know the technical language needed to describe a mechanical fault, particularly when stressed.

Intended impact: Drivers may not know the technical language needed to describe a mechanical fault, particularly when stressed.

Decision 05

Use progressive disclosure for driver information

Intended impact: Only information required to locate and contact the driver is prioritised before dispatch, while secondary information is collected later when appropriate.

Decision 06

Provide persistent emergency access

Earlier designs used multiple emergency banners and prominent SOS treatments, which competed with the primary roadside assistance journey. I consolidated emergency access into one persistent navigation action.

Intended impact: Emergency support remains consistently accessible without overwhelming the rest of the interface.

Decision 07

Only recommend a mechanic after the request is understood

An earlier home screen recommended a mechanic before the driver had described the problem. This undermined trust because the recommendation appeared predetermined rather than intelligent.

Intended impact: Mechanic matching now happens after the user submits the minimum required information, making the recommendation feel contextual and credible.

Decision 08

Make live tracking the primary post-dispatch experience

Once assistance has been requested, the driver's main question changes from “How do I get help?” to “Where is my mechanic?”

Intended impact: The post-dispatch interface prioritises mechanic location, ETA and communication while keeping AI diagnosis available as a secondary task.

03 — Information Architecture & User Flows

Structuring the experience around customer intent

Information Architecture

1. LAUNCH │ ├── App loading ├── Location detection └── Continue to request help │ ▼ 2. REQUEST HELP │ ├── What happened? │ ├── Won't start │ ├── Flat tyre │ ├── Flat battery │ ├── Accident │ └── Other │ └── Continue │ ▼ 3. CONFIRM DISPATCH │ ├── Current location │ └── Change location │ ├── Phone number │ └── Edit │ ├── Vehicle │ └── Add / confirm vehicle │ └── Confirm & Dispatch │ ▼ 4. MECHANIC ASSIGNED │ ├── Mechanic profile ├── Rating ├── Vehicle / identification ├── ETA ├── Distance ├── Call / message └── View Live Tracking │ ▼ 5. LIVE TRACKING │ ├── Live map ├── Mechanic location ├── ETA ├── Call mechanic ├── Message mechanic │ └── AI Assistant ──────────────┐ │ ▼ 6. AI DIAGNOSIS — OPTIONAL │ ├── Describe issue │ ├── Text │ └── Voice │ ├── Upload photo ├── Scan warning light │ ├── AI analysis │ └── Diagnosis summary │ ├──────────────► Shared with mechanic │ ▼ 7. REPAIR │ ├── Mechanic arrived ├── Initial inspection ├── Diagnosing issue ├── Repairing ├── Testing └── Job complete │ ▼ 8. PAYMENT │ ├── Cost summary │ ├── Labour │ ├── Parts │ ├── Service fee │ └── Total │ ├── Payment method │ ├── Apple Pay │ ├── Google Pay │ ├── Card │ └── Cash to mechanic │ └── Pay │ ▼ 9. RECEIPT │ ├── Payment confirmation ├── Job number ├── Total paid ├── Email confirmation ├── Download receipt ├── Rate experience └── Back to Home

Primary User Flow

Stage

User action

Product response

1. Launch

Opens Mobile Mechanic

Detects location and prepares the emergency journey

2. Request Help

Selects what happened: Won't Start, Flat Tyre, Flat Battery, Accident or Other

Captures enough context to begin matching

3. Confirm & Dispatch

Confirms location, phone number and optional vehicle details

Starts searching for the nearest suitable mechanic

4. Mechanic Assigned

Reviews mechanic, ETA and distance

Confirms that assistance has been secured

5. Live Tracking

Tracks mechanic in real time

Provides ETA, location updates and communication

6. AI Diagnosis — Optional

Describes the problem by voice/text, uploads a photo or scans a warning light

AI analyses the information and shares useful context with the mechanic

7. Repair

Follows repair progress

Shows arrival, inspection, diagnosis, repair, testing and completion

8. Payment

Reviews costs and selects payment method

Processes payment securely

9. Receipt

Reviews confirmation and receipt

Closes the journey and provides proof of payment

Secondary Flows

Secondary Flow 01

AI Diagnosis

An optional post-dispatch flow that allows the driver to provide additional information while the mechanic is already on the way. Users can describe the issue by voice or text, upload photos, or scan a dashboard warning light. The AI analyses the information and shares a diagnostic summary with the assigned mechanic, helping them arrive better prepared without delaying assistance.

Secondary Flow 02

Location Management

The app automatically detects the driver's location to reduce input during a stressful situation. If the detected location is inaccurate, the driver can choose a different address or adjust their position before dispatching help.

Secondary Flow 03

Request Cancellation

Drivers can cancel an active roadside request when assistance is no longer required. A confirmation step protects against accidental cancellation while keeping the option accessible throughout the active job.

04 — Wireframes

Translating the journey into screens

Wireframes

The wireframes were designed around one principle: get help moving first, then use AI to make that help smarter.

The workflow maps the complete roadside assistance journey from launching the app to completing payment. Rather than forcing a stranded driver through diagnosis before they can request help, I prioritised dispatch speed, low cognitive load and clear system feedback.

User Flow

The primary journey was deliberately kept linear:

Launch → Request Help → Confirm & Dispatch → Find Mechanic → Mechanic Accepted → Live Tracking → Repair Progress → Payment → Receipt

AI diagnosis sits within the active assistance journey rather than blocking it:

Live Tracking → AI Assistance → Diagnostic Summary → Mechanic Preparation

This separation became an important design decision. The user can get a mechanic moving towards them first, then provide richer diagnostic information while they wait.

Key Screens

1. Request Help The first interaction asks one simple question: “What’s happened to your vehicle?” Common problems such as Won’t Start, Flat Tyre, Flat Battery and Accident reduce typing and support quick decision-making. An Other option handles situations outside these predefined categories.

2. Confirm & Dispatch Before sending the request, the user reviews only the information required to get assistance to them: location and phone number, with vehicle details treated as optional. GPS accuracy is surfaced so the user can correct their location before dispatch.

3. Finding a Mechanic A focused matching state communicates that the system is actively searching nearby mechanics. Availability and distance provide useful feedback without asking the user to make another decision.

4. Mechanic Accepted & Live Tracking Once a mechanic accepts the request, the experience shifts from uncertainty to reassurance. The user receives the mechanic's identity, vehicle information, ETA and distance, followed by live map tracking and direct communication options.

5. AI Assistance While help is travelling, AI becomes a secondary tool rather than a prerequisite. Users can describe symptoms, use voice input, upload a photo or scan a dashboard warning light. The resulting diagnostic summary is then available within the job context to help the mechanic arrive better prepared.

6. Repair Progress A simple status timeline communicates where the job is: Mechanic arrived → Initial inspection → Diagnosing issue → Repairing → Testing → Job complete. This reduces uncertainty while avoiding unnecessary technical detail.

7. Payment & Receipt The final screens make cost transparent before payment, separating labour, parts and service fees. Multiple payment options are supported, followed by a clear success state, downloadable receipt and route back home.

Key Design Decisions

Reduced pre-dispatch friction: Only information necessary to locate and dispatch assistance is requested upfront.

AI after dispatch: AI diagnosis enhances the service without delaying the user's primary goal of getting roadside help.

Progressive disclosure: Additional information appears when it becomes relevant rather than overwhelming users at the beginning.

Strong system status: Searching, accepted, en route, diagnosis and repair states continuously communicate what is happening.

Accessible interaction targets: Large cards, clear labels and prominent CTAs support use in stressful roadside conditions.

Multiple input methods: Tap, voice, photo and warning-light scanning accommodate different circumstances and levels of user knowledge.

Transparent costs: The payment screen exposes the cost breakdown before the user commits to payment.

Escape routes: Cancellation, mechanic communication and alternative location handling prevent the happy path from becoming a dead end.

Why This Mattered

The wireframing process shifted the product from an AI-first diagnostic experience into a driver-first roadside assistance experience powered by AI.

That distinction shaped the final product: dispatch solves the urgent problem; AI improves what happens next.

Ideal portfolio visual

Use the attached end-to-end workflow as the main visual for this section, but present it at a larger scale with the journey grouped into four labelled phases:

1. Get Help → Request + Dispatch 2. Get Connected → Matching + Mechanic Accepted 3. Get Supported → Live Tracking + AI Assistance + Repair 4. Complete → Payment + Receipt

Wireframes

Key Iterations

Iteration 01

01 — From long onboarding to a 2-step request flow

Iteration 02

02 — Help first, AI second

Iteration 03

03 — Making system status visible throughout the journey

Iteration 04

04 — Build trust through transparency

05 — Design System

Building a consistent visual language

The visual system needed to feel calm, fast and dependable in a situation that could be anything but.

I avoided an overly decorative interface and built the visual direction around clarity, trust and immediate recognition. Strong hierarchy, generous spacing and a restrained colour system help users understand what requires attention without adding unnecessary cognitive load.

The interface uses blue as the primary action and trust colour, green for successful or confirmed states, red only for genuinely urgent or destructive actions, and neutral surfaces for supporting information.

Why this mattered: The visual language needed to reinforce the product's core promise: help is available, the system is working, and the user remains in control.

Design System

Accessibility Decisions

1. Reduced cognitive load Reduced the urgent help journey to two steps, allowing users to request assistance without completing unnecessary onboarding or diagnosis first.2. Large, clear touch targets Used large, well-spaced controls for issue selection and primary actions to support quick, accurate interaction, including one-handed use.3. Colour is not the only indicator Combined colour with icons and text labels for important states such as Available, En route, Verified and Payment Successful.4. Clear visual hierarchy Made primary actions such as Continue, Confirm & Dispatch and Pay visually dominant, while keeping supporting information secondary.5. Plain and reassuring language Used short, familiar language such as “What’s happened to your vehicle?” and “Mechanic accepted!” instead of unnecessary automotive or technical terminology.6. Multiple input methods Allowed users to describe problems using text, voice, photos or warning-light scanning, giving users flexibility depending on their circumstances.

06–07 — Final UI

The final responsive product experience

Solution Introduction

The final solution turns roadside assistance into a fast, focused journey that prioritises getting help first and gathering additional information second.

Mobile Mechanic was designed around a simple principle: when a driver is stranded, they should not have to diagnose their vehicle, navigate a complex onboarding process, or complete unnecessary forms before help can be dispatched.

The final experience reduces the core request journey to two essential steps. The driver identifies what has happened, confirms their location and contact details, and the system begins searching for the nearest available mechanic. From there, the experience provides clear mechanic assignment, ETA and live tracking so the driver always knows what is happening.

AI diagnosis was deliberately moved out of the critical dispatch path. Instead, it becomes an optional assistant while the mechanic is travelling, allowing the driver to provide additional context through text, voice, photos or warning-light scanning. This information can help the mechanic arrive better prepared without delaying the initial request for assistance.

The end-to-end solution supports the complete roadside journey:

Request Help → Confirm & Dispatch → Mechanic Matching → Mechanic Assigned → Live Tracking & Optional AI Assistance → Repair Progress → Payment → Receipt

By combining rapid dispatch, transparent system feedback, optional AI assistance and clear payment information, the final solution aims to reduce uncertainty while keeping the driver informed and in control throughout the experience.

Why this mattered: The product evolved from an AI-led diagnostic experience into a help-first roadside service, where technology supports the emergency journey rather than becoming another step the user must complete.

Experience 01

1. Requesting Roadside Help

The core emergency journey was reduced to two steps. Drivers select what has happened, confirm their location and essential details, and dispatch a request without completing unnecessary forms or diagnosis.

Two Mobile Mechanic screens showing vehicle issue selection followed by location, contact and vehicle confirmation before dispatch. — A two-step request experience designed to get drivers from breakdown to dispatch with minimal friction.

Experience 02

2. Finding & Assigning a Mechanic

After dispatch, the system immediately communicates that work is happening in the background. Drivers can see nearby mechanics being searched before receiving confirmation of the assigned mechanic, ETA and distance.

Mobile screens showing the search for nearby available mechanics followed by an accepted request with mechanic details, ETA and distance. — Visible system feedback reduces uncertainty between requesting assistance and receiving mechanic confirmation.

Experience 03

3. Live Tracking & AI Assistance

Once help is secured, live tracking becomes the primary experience. Optional AI tools allow the driver to provide additional information through text, voice, photos or warning-light scanning while the mechanic is travelling.

Live mechanic tracking screen with optional AI assistance alongside a job screen showing vehicle information and an AI-generated issue summary. — AI supports the roadside journey after dispatch rather than delaying the user's request for urgent help.

Experience 04

4. Repair Progress & Status

The repair experience keeps the driver informed after the mechanic arrives. A simple progress timeline communicates key stages such as arrival, inspection, diagnosis, repair, testing and completion.

Mobile Mechanic job and repair screens showing mechanic arrival, vehicle information and a vertical timeline of repair progress. — Clear progress states keep drivers informed from mechanic arrival through to job completion.

Experience 05

5. Payment & Completion

The final stage provides transparent pricing before payment and a clear confirmation afterwards. Drivers can review labour, parts and fees, select a payment method, receive a digital receipt and return home.

Payment screens showing an itemised repair cost, payment options and successful payment confirmation with receipt access. — ransparent costs and clear completion states provide confidence at the end of the roadside assistance journey.

Prototype

Testing the complete journey

The interactive prototype brings the complete roadside assistance journey together, demonstrating how a driver can move from an unexpected breakdown to receiving help, completing the repair and making payment with minimal friction. The prototype focuses on the product’s primary journey: identifying the roadside problem, confirming essential details, dispatching a request, matching with an available mechanic and tracking their arrival in real time. The core request experience is intentionally kept to two steps, reflecting the need for speed and simplicity when users may be stressed or stranded. Once a mechanic has been assigned, the prototype demonstrates how AI becomes a supporting feature rather than a barrier to getting help. While waiting, drivers can optionally provide additional information through text, voice, photos or warning-light scanning. This information can help the mechanic understand the likely issue before arriving without delaying dispatch. The prototype also covers the later stages of the service, including mechanic arrival, repair progress, transparent cost review, payment and receipt confirmation. Clear status changes and feedback throughout the journey help users understand what is happening, what happens next and when action is required. Prototype flow: Request Help → Confirm & Dispatch → Find Mechanic → Mechanic Assigned → Live Tracking & Optional AI Assistance → Repair Progress → Review & Pay → Payment Confirmation Why this mattered: The prototype allowed the end-to-end experience to be evaluated as one connected journey, validating whether the product remained simple, understandable and reassuring from the moment assistance was requested through to successful completion.

Core Roadside Assistance Flow

A walkthrough of the primary roadside assistance journey from requesting help through payment and completion.

Explore Interactive Prototype →

08 — Edge Cases & System States

Designing beyond the happy path

Edge Case 01

01 — No Mechanic Available

Scenario

The driver has successfully submitted a roadside assistance request, but no available mechanic can be found within the initial search area. At this point, the user may already be stranded and uncertain about how long they will need to wait.

Problem

Rather than leaving the driver on an indefinite searching screen, Mobile Mechanic clearly explains that no mechanic is currently available nearby. The system preserves the existing request details and provides recovery options, including expanding the search radius, retrying the search or contacting support.

Response

Expand Search Area

Edge Case 02

02 — Location Access Denied

Scenario

The driver has denied location permission, GPS is unavailable, or the device cannot determine an accurate location. Because location is essential for dispatching roadside assistance, the experience needs an alternative that does not block the user from requesting help.

Problem

Mobile Mechanic explains why location information is required and gives the driver two clear ways to continue: enable location access or manually enter a postcode or address. This keeps the user in control while ensuring the service can still identify where assistance is needed.

Response

Enter Location Manually

Edge Case 03

03 — Mechanic Cancelled

Scenario

An assigned mechanic becomes unavailable after accepting the roadside request. The driver has already completed the request journey and may have been waiting for assistance, making this a particularly sensitive failure point.

Problem

Mobile Mechanic immediately informs the driver of the change and automatically begins searching for a replacement mechanic. The original location, vehicle and issue information is retained, so the driver does not have to restart the request. Once another mechanic accepts, the user receives updated mechanic details and a new ETA.

Response

Automatically Find Replacement

10 — Impact & Outcomes

From business problems to product outcomes

Mobile Mechanic evolved from an AI-led roadside concept into a focused, help-first experience designed around what stranded drivers need most: speed, visibility and reassurance.

The strongest impact of the project came from simplifying the critical journey. Instead of asking users to complete diagnosis before receiving assistance, the final experience prioritises a two-step request and dispatch flow, allowing help to start moving while additional information can be gathered afterwards.

The redesigned experience also addresses uncertainty throughout the journey. Mechanic matching, clear ETA information, live tracking, repair progress and transparent payment give drivers greater visibility into what is happening, who is helping them, what happens next and what they will pay. Optional AI assistance adds value without becoming a barrier to receiving help.

Key design outcomes included:

Reduced friction: simplified the core journey to Request Help → Confirm & Dispatch before mechanic matching begins.

Help first, AI second: repositioned AI diagnosis as an optional waiting-state tool rather than a mandatory pre-dispatch step.

Greater transparency: introduced mechanic identity, ETA, live location, repair status and itemised costs throughout the service.

Improved recovery: designed edge cases for unavailable mechanics, denied location access and mechanic cancellation so users are not left at dead ends.

Accessibility by design: prioritised clear language, strong hierarchy, large touch targets, sufficient contrast and status communication that does not rely on colour alone.

End-to-end continuity: created a connected experience from the initial breakdown request through dispatch, tracking, repair, payment and receipt.

Because this is a concept project, these outcomes represent design improvements rather than measured production results. The next step would be usability testing with drivers to validate task completion, time to dispatch, comprehension of system states and perceived confidence during the roadside journey.

Why this mattered: The project demonstrates that the value of roadside technology is not simply adding more features or AI. It is using technology at the right moment to reduce uncertainty, accelerate access to help and give drivers greater confidence during a stressful situation.

Target ≥ 90%

1. Help Request Completion

Target percentage of users able to complete the two-step Request Help and Confirm & Dispatch flow without assistance.

Target ≤ 60 sec

2. Time to Request Help

Target time for a stranded driver to identify the issue, confirm their details and submit a roadside assistance request.

Target ≥ 90%

3. Live Tracking Comprehension

Target percentage of users able to correctly understand their mechanic’s location, ETA and current service status.

Target ≥ 4/5

4. User Confidence

Target usability-testing score for how informed, reassured and in control users feel during the roadside assistance journey.

Design Outcomes

A faster core journey: The request experience was reduced to two essential steps, identifying the problem and confirming dispatch details, before the system begins searching for a mechanic.

AI repositioned around real user need: AI diagnosis moved out of the critical dispatch path and became an optional tool while the mechanic is travelling. Drivers can use text, voice, photos or warning-light scanning without delaying assistance.

Greater visibility during waiting: Mechanic matching, identity, ETA, distance and live tracking provide continuous feedback, reducing the uncertainty commonly associated with waiting for roadside assistance.

Clearer service progression: Repair status communicates key stages from mechanic arrival and inspection through diagnosis, repair, testing and completion, helping users understand what is happening without repeatedly asking for updates.

More transparent payment: Itemised labour, parts and service fees are presented before payment, followed by clear confirmation and receipt access. This gives drivers greater visibility over the financial side of the service.

Recovery beyond the happy path: Edge cases such as no available mechanic, denied location access and mechanic cancellation provide clear recovery routes rather than leaving users at dead ends.

More accessible interaction patterns: Plain language, clear hierarchy, large touch targets, strong contrast and icon-plus-text status communication were incorporated to support users who may be stressed, distracted or operating in difficult roadside conditions.

A consistent product system: Reusable components, predictable interaction patterns and a defined visual language create consistency across dispatch, tracking, AI assistance, repair and payment experiences.

11 — Reflection & Next Steps

Learning from the product and looking forward

Next Steps

1. Conduct usability testing to validate the two-step dispatch journey and target metrics.

2. Test optional AI assistance to understand which diagnostic inputs provide genuine user and mechanic value.

3. Validate live tracking and edge cases under realistic roadside and poor-connectivity conditions.

4. Run a WCAG 2.2 AA accessibility review across the critical journey.

5. Validate the mechanic-side service model, including availability, cancellations, pricing and job management.

6. Prepare a validated MVP for development, working with engineering on tracking, payments, location services and AI feasibility.

What I Learned

1. Reduce cognitive load before adding capability In stressful situations, fewer decisions and clearer actions can be more valuable than additional functionality.

2. Help first, AI second AI should support the roadside assistance journey rather than become a mandatory step before users can receive help.

3. Visibility builds trust Mechanic identity, ETA, live tracking, repair progress and transparent costs reduce uncertainty throughout the service.

4. Design beyond the happy path Edge cases revealed that good recovery experiences should preserve user progress and clearly communicate what happens next.

5. Validate assumptions with real users As a concept project, the next step would be usability testing with drivers to validate the two-step dispatch flow, AI assistance, tracking comprehension and recovery states.

Reflection

Mobile Mechanic challenged me to think beyond designing individual screens and focus on how the entire service should respond when someone needs help under pressure.

One of the most important shifts came from questioning the role of AI in the original experience. Early concepts gave diagnosis greater prominence, but this introduced additional steps before the user could access the service they actually needed. I refined the journey around a clearer principle: dispatch help first, gather richer diagnostic information afterwards. This led to the simplified two-step request flow and repositioned AI as optional assistance while the mechanic is on the way.

The project also reinforced the importance of visibility as a trust mechanism. A successful dispatch alone is not enough when a driver is stranded. Mechanic identification, ETA, live tracking, repair progress and transparent costs were designed to answer the questions users are likely to have throughout the journey: Has someone accepted my request? Who is coming? Where are they? What is happening to my vehicle? What will I pay?

Designing beyond the happy path was another significant learning. Exploring situations such as no mechanic being available, location access being denied and an assigned mechanic cancelling changed how I thought about resilience. Rather than treating these as isolated error screens, I designed recovery paths that preserve the driver's information, explain what the system is doing and provide a clear next action.

Accessibility also became more than a compliance consideration. Roadside assistance may be used when someone is stressed, distracted, outdoors, working with limited connectivity or trying to conserve their phone battery. Clear language, strong hierarchy, large touch targets, visible system feedback and reducing unnecessary decisions therefore became fundamental product decisions.

Most importantly, this project strengthened my view that good product design is not about adding the most features. It is about deciding what users need now, what can wait, and how the product should respond when circumstances change.

As Mobile Mechanic is currently a concept project, I would not consider the design finished. The next step would be to validate the key assumptions through usability testing, particularly the two-step dispatch flow, live-tracking comprehension, optional AI assistance and recovery from failure states. Those findings would determine what should be refined before defining and building an MVP.

Ultimately, Mobile Mechanic helped me move from designing a roadside assistance interface to thinking about the complete service experience: the user, the mechanic, the technology and the moments of uncertainty connecting them.

Links

Explore the project

Open Figma →