Back to Case Studies
Mobile / Service Design / On-Demand2024

Booking an Electrician
Shouldn't Feel Like Work

A customer-facing mobile app design for a San Diego electrical contractor that compresses the entire booking-to-payment journey into four screens.

"Service industries treat their app like a phone book with a payment button. The opportunity isn't to digitise the call. It's to make the call unnecessary."

Role

Product Designer

Client

BAV Electric

Location

San Diego, CA

Status

Design complete, build on hold

The Booking Flow

Four screens. Under sixty seconds.

BAV ELECTRIC

What's the issue?

STEP 01

Three visual job-type cards — breaker issue, EV charger, lighting & remodel — so customers don't need to know the trade vocabulary.

BAV ELECTRIC📍

Where's the work?

STEP 02

Address pulled from device location. One tap to confirm or type. No form fields for their own sake.

BAV ELECTRIC📅

When?

STEP 03

Same-day, next-day, or schedule. Time slots shown only when available. No phantom slots.

BAV ELECTRIC🔧

Who's coming?

STEP 04

Technician name, photo, licence number, and review score. Confirmed with a tap. Under sixty seconds, start to finish.

01 — The Context

BAV Electric is a licensed electrical contractor operating across San Diego County. Residential and commercial work. Panel upgrades, EV charger installs, smart home wiring, lighting design, solar tie-ins.

The business runs the way most trades businesses run — phone calls, text threads, and a dispatch board. That model works. It also caps growth. The booking experience is a friction surface that loses customers at every step.

Calling hours

9 to 5 only

Quote turnaround

Up to a day

Arrival visibility

None

Payment

Handed phone on job site

Each of those is a small annoyance. Together they are the reason most homeowners default to a Yelp search instead of repeat business. BAV came to us with a clear ambition: build the customer-facing app that turns one job into a lifetime customer.

02 — The Bet

The app should make the call unnecessary.
Not faster — unnecessary.

01

Compress the inherited model

The default move in service-business apps is to digitise the existing phone call. A form replaces the dispatcher. A booking flow replaces the back-and-forth. The friction stays roughly the same — it just moves to a screen. We bet the opposite. The app should absorb the full journey: discover, book, track, approve, pay.

02

Design for trust first

Trades businesses live and die on trust. The app had to feel like a real licensed contractor, not an on-demand gig platform. That shaped everything: the technician profile design, how pricing is communicated, the credential surface on the tracking screen, and the receipt structure after the job.

03 — My Role

Product Designer

Customer Research

Interviewed real BAV customers to map the existing booking journey and its failure points — where calls were missed, where quotes stalled, where payments felt awkward.

Information Architecture

Structured the full app from the first-open state through job history. Every screen had to earn its place in the navigation model.

Booking Flow

Interaction design for the four-screen booking compression. Translated three distinct customer intents (emergency, planned upgrade, remodel) into a single surface.

Tracking & Credentials

Designed the live technician tracking surface — borrowing the pattern from rideshare, the credential surface from medical apps.

Scope Approval

The most complex screen in the app. A structured proposal that moves from the technician's device to the customer's phone and becomes the legal record for the job.

Payment & Receipt

Apple Pay and Google Pay first. Itemised receipt with licence number and warranty terms. Designed as a referral artifact.

Design System

A trade-specific component library: job cards, technician profile blocks, scope-of-work proposals, receipts. Built to be reused across subsequent service-business engagements.

Handoff

High-fidelity prototypes and design system documentation for engineering handoff. The build is on hold on the client side; the design work is complete.

"Trade businesses live and die on trust. The app had to feel like a real licensed contractor, not an on-demand gig platform."

04 — The Build

Four critical journeys

Book. Track. Approve scope. Pay. Each gets its own design treatment — and its own design rationale.

4 SCREENS

The booking flow

Most service-booking apps run users through a ten-step funnel. We compressed BAV's down to four screens. The first screen surfaces the three most common job types as visual cards so customers don't have to know the trade vocabulary.

The second pulls the address from device location. The third offers same-day, next-day, or schedule. The fourth confirms the technician and the time window. The whole flow takes under sixty seconds end to end.

4A

Live technician tracking

Once the booking is confirmed the app shifts into tracking mode. Real-time location, an honest arrival window — not a five-minute promise that turns into ninety — and the technician's name, photo, licence number, and review history on a single screen. The tracking pattern borrows from rideshare apps. The credential surface borrows from medical apps. The combination is the reason a customer opens the door without anxiety.

DESIGN DECISION

Design decision: showing the licence number on the tracking screen was a deliberate trust signal, not a compliance detail. Customers told us in research that knowing who was coming mattered more than knowing when.

4B

On-site scope approval

When the technician arrives and the job scope shifts — and it always can — the technician sends a structured scope-of-work proposal directly to the customer's phone. Line-itemed parts, labour, time estimate, total. The customer approves with a tap or requests changes. Every approved scope becomes the on-record agreement for the job. The awkward doorstep negotiation over a paper estimate is gone.

DESIGN DECISION

Design decision: the proposal had to feel like a document, not a pop-up. Heavy typography, clear line items, visible totals. The customer is signing off on work happening in their home — the screen had to earn that weight.

4C

Payment and receipt

Payment happens through the app, not by handing a card reader to the customer after a long day on a job site. Apple Pay and Google Pay first, card fallback second. The receipt is structured, itemised, and downloadable — with the technician's licence number and warranty terms embedded. Trade businesses that handle payment cleanly earn referrals. The receipt is part of the referral funnel.

DESIGN DECISION

Design decision: the receipt is as important as the booking flow. A homeowner who gets a clean, itemised, warranty-stamped receipt for a panel upgrade will show it to their neighbour asking about EV charger installs.

Customer profile and job history

Returning customers see their job history as a persistent record. Every panel upgrade, every circuit added, every smart home device wired — dated and itemised. That history is genuinely useful for any subsequent electrical work, and turns into the natural reason a customer picks BAV again instead of starting a new Yelp search.

05 — Design System & Visual Direction

The visual system is deliberately quiet. Trade businesses lose customers when their app looks like a startup.

Typography

Heavier weight. Restrained size hierarchy. The app reads closer to a banking interface than a delivery app — a deliberate choice to signal reliability over speed.

Colour palette

Navy and warm yellow that mirrors the existing BAV brand. Both colours read as established and trusted. Neither reads as startup-adjacent.

Motion

Generous spacing. No animation that doesn't serve a clear purpose. The UI earns attention through clarity, not movement.

Trade-specific component library

Generic mobile design systems don't handle trade-business surfaces well. The component library covers the gaps: job cards with status, scope, and pricing; technician profile blocks with licensing and review credentials; scope-of-work proposals with line-itemed parts and labour; receipts with embedded warranty terms.

These components were designed to be reused across other service-business builds, not just BAV's app. Two subsequent service-business briefs at the studio have already referenced this library as a starting point.

06 — Deliverables

38 screens across the full customer-facing flow

Complete component library for trade-specific UI patterns

High-fidelity interactive prototype — book, track, approve scope, pay

Design system documentation for engineering handoff

Customer research findings mapping the booking journey and its failure points

07 — Why It's on the Portfolio Even Though It's on Hold

Design work is design work. The build status of any given project depends on factors that are often outside the design team's control — funding, internal priorities, leadership changes. The work here is real, the customer research is real, and the design system is reusable on any subsequent service-business build.

It demonstrates range

Most of the rest of the Luvon portfolio is Web3 and AI. BAV proves we can design for a normal consumer audience in a service industry.

It demonstrates research-led thinking

The customer journey mapping and the choices made in the four-screen booking flow are textbook examples of how to compress an inherited business model into a modern interface.

It demonstrates reusable design system thinking

The trade-specific component library will outlive this project and inform every subsequent service-business engagement we take on.

08 — What It Unlocked

BAV is the project that clarified the Luvon position on non-Web3 work. The agency can design for any consumer audience. We don't pretend everything needs a wallet or a token.

The trade-specific component library has already been referenced internally as a starting point for two subsequent service-business briefs. The four-screen booking compression has become a default constraint we apply to any on-demand booking flow that comes through the studio.

Booking compression as a default constraint

Four screens. Under sixty seconds. The constraint has become the opening question on every service-business brief since: how many steps can we actually remove?

Trust as a design material

The credential surface, the receipt structure, the scope-approval flow — all of them are now studio patterns for any context where the customer is letting someone into their home or business.

"Service industries treat their app like a phone book with a payment button. The opportunity isn't to digitise the call. It's to make the call unnecessary."

"Trade businesses live and die on trust. The app had to feel like a real licensed contractor, not an on-demand gig platform."

"Trades businesses that handle payment cleanly earn referrals. The receipt design is part of the referral funnel."

Start a Project

Building something for real people?

Consumer apps, service businesses, on-demand flows. If the brief is a real product for a real audience, we'll build it that way.

Start a Conversation