← Back

Map App

On-site review capture for home service professionals.

Project overview

  • Type: Product · 8-week 0→1
  • Project type: 0→1 · Local SEO & Reviews · Field-First Mobile UX · Activation & Habit
  • Role: Lead Product Designer · Field UX Research · Interaction Design
  • Methods: Contextual inquiry (on-site) · JTBD interviews · unmoderated usability · A/B
  • Tools: dscout · Otter.ai · Figma + Dev Mode · Amplitude · Statsig
  • Case thesis: Designing on-site review capture that turns a finished job into a posted, authentic Google review from the customer's own phone in under a minute, for tradespeople working one-handed in the field — while staying inside Google's authenticity and anti-gating rules by design.

The context

Local home service pros (plumbers, electricians, roofers) win most of their work through Google's local pack, where ranking is driven heavily by the volume, recency, and steadiness of reviews on the Google Business Profile (the listing formerly branded Google My Business). A business that goes weeks without a new review loses ground to competitors who post steadily. These pros already know reviews matter; the work happens on a phone, between jobs, often with dirty or gloved hands.

The problem

The willingness to leave a review exists, but it never gets captured. Across 12 in-field ride-alongs covering 47 completed jobs, a review was requested on only 11 jobs (23%), and follow-up two weeks later showed 2 reviews posted — a ~4% job-to-review rate (behavioral, field observation; consumer review-request follow-through benchmarks publicly run ~10–20%). The leak sat in two places: the pro forgot to ask once hands were full, and the customer who agreed never finished the multi-step Google flow later.

The goal

Raise the share of completed jobs that produce a posted, Google-compliant review, captured at the moment of completion, so review velocity becomes steady enough to support local-pack ranking. Success is defined as a lift in job-to-review rate and in reviews posted per pro per month — the metrics the design controls directly. Ranking/profile-action effects are treated as downstream indicators, reported honestly given the pilot's size rather than claimed as causal.

Empathize — Willingness to leave a review peaked at job completion and decayed within minutes of the pro leaving

In this section: Research foundation · Key insights

Research foundation (method)

  • Phase 1 — Expert interviews (n=8, 30 min, via Otter.ai transcription): local-SEO consultants and home-service agency owners, on what moves local-pack ranking.
  • Phase 2 — In-field ride-alongs / contextual inquiry (n=12 pros, ~45 min each, recruited via dscout): observed 47 real job completions end to end, including how and whether the review ask happened.
  • Phase 3 — Homeowner survey: ~986 panelists invited; 140 analyzable responses (14.2% response rate); ~90 completed every item (9.1% completion rate). Attitudinal percentages are computed on the 140 analyzable responses; question types (select-all vs single-select) are labeled per question in the appendix.
  • Phase 4 — Prototype pilot (Amplitude-instrumented, iOS, 6 pros): funnel data from a clickable build used on live jobs.

Key insights

1. The ask dies in the gap between the job site and the truck. Pros intended to ask but were carrying tools, chasing the next appointment, or settling payment when the moment passed. A review was requested on only 23% of observed jobs.

  • Verbatim (P4, plumber, 9 yrs) — coded: Intent-to-action gap: "By the time I'm back in the truck I've already forgotten, and texting them that night feels pushy."

2. Customers are willing; the customer-side Google flow is where the review is lost. The survey showed strong stated willingness while behavior showed almost no follow-through, and the two converge on friction at the moment of asking as the cause. Triangulation:

  • Behavioral: job-to-review rate ~4%.
  • Attitudinal: 68% of homeowners said they would "gladly" leave a review if asked, yet fewer than 1 in 4 had posted even a single business review in the past 12 months (median 0). The drop sat in the Google flow itself: sign in, find the listing, face a blank text box.
  • Verbatim (P9, homeowner, recent roof repair) — coded: Flow friction: "I meant to, I really did — but I never found the page again and then it just felt too late."

3. Pros distrust generic review tools because reviews vanish or can't be tied to a job. Several had tried review-request tools and seen reviews never appear on Google or get filtered out, with no way to know which job a review belonged to.

  • Verbatim (P2, electrician, 12 yrs) — coded: Trust / attribution: "I paid for a tool and never saw a single review actually show up on my Google page."

Dashboard — Where the review pipeline leaks

The review pipeline leaks
Scope: 12 ride-alongs · 47 completed jobs · field-observed
Guiding question: At which step does a potential review disappear?

  Jobs completed ............................ 47   (100%)
  Review requested by pro ................... 11   (23%)
  Customer agreed on-site ................... 8    (17%)
  Review posted within 2 weeks .............. 2    (4%)

Key Insight: Two drop-offs dominate — the pro asking (47→11) and the
customer finishing the Google flow later (8→2). Both happen because the
work moves on before the review is captured.

Define — Capture had to happen on-site, in under a minute, from the customer's own phone, in their own words

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. Home service pros need to capture a Google review at the instant a job is signed off — on-site, one-handed, and posted from the customer's own phone — because customer willingness peaks at completion and decays within minutes of the pro leaving the property.

How Might We

  1. How might we turn the 60 seconds after a signed-off job into a posted, authentic Google review without the pro stopping work?
  2. How might we cut the customer's effort from a multi-step sign-in-and-write flow to under 30 seconds, on their own device?
  3. How might we give pros visible proof that a review landed on their Google Business Profile, tied to the specific job — without violating Google's authenticity or anti-gating rules?

Design principles (each traceable to an insight or a platform constraint)

  • Capture at completion. The review prompt fires at job sign-off, while the customer is still on-site. (Insight 1)
  • One thumb, glove-friendly. Every primary action reachable with one hand; large targets, high contrast. (field constraint)
  • Customer's own device, customer's own words. The customer scans a QR with their phone and writes in their own account; the words stay theirs. (Insight 2 + platform constraint — see below)
  • Every review traceable to a job. Each request is bound to a documented job, and the app reads the posted review back to confirm. (Insight 3)
  • Compliant by design. Fire on every signed-off job (not only happy ones), so the product never engages in review gating, which Google prohibits. (platform constraint)

Platform constraint that shaped the whole design. Google does not allow posting a review — or attaching photos to a customer's review — programmatically; a review is written by the customer, on Google's surface, from their own account, and any photos in it are added by the customer. Company-fed short links can also strip the photo option on mobile and are themselves a signal Google uses to filter "fed" reviews. So the design problem was never "generate the review." It was: reduce the customer's effort to near-zero on their own phone while keeping authorship genuinely theirs — which is also exactly what survives Google's authenticity filters.

Insight → decision map

Insight / constraint Concrete design decision
Review requested on only 23% of jobs; the ask is forgotten after leaving Prompt to request a review fires automatically at job sign-off, inside the documentation flow
68% willing but median 0 reviews posted; the Google flow is the drop-off Generate a one-tap QR + short link to a place-ID review deep link (photo-enabled, not the flaggable short link) that lands the customer's own phone directly on the review surface
Pros distrust tools because reviews vanish or aren't attributable Bind each request to a documented job; the app reads new reviews via the Reviews API and surfaces the matched one as a "posted to your Business Profile" confirmation
Google forbids posting reviews / injecting photos The pro's job photos post to the pro's own Business Profile media (API-supported); the customer's review stays their own words + their own optional photos

Ideate & Craft — One thumb, two modes: document the job, then hand the customer a one-scan path to an authentic review

In this section: Design execution · Before → after · Other deliverables

Design execution

Map App runs two modes the pro switches between with a single tab:

  • Capture mode — take photos, dictate or type a short description, and drop a location pin for the job. The photos post to the pro's own Google Business Profile as geotagged business media; the location + timestamp bind the job record. (This is the "Map" in Map App: the pin is for job attribution and geotagged proof-of-work, not a ranking trick — see note below.)
  • Review mode — from that same job, generate a unique QR code + short link pointing to a place-ID-based review deep link that preserves the photo option. The customer scans with their own phone, lands on Google's review surface signed into their own account, and writes their review seeded by a few suggested-topic chips (e.g., "on-time," "clean work," "fair price") that lower effort while leaving the words to the customer. The pro's job photos are offered for the customer to reuse if they choose.
  • Confirmation — the app polls the Reviews API for new reviews on the profile and surfaces the likely match, giving the pro a job-bound "it posted" confirmation.

On location and ranking (honesty note built into the case): dropping a job pin is not a documented Google ranking factor, and the case does not claim it lifts rank. Its real value is (a) attribution — proving a review maps to a real job at a real place and time, which is the answer to the pros' distrust — and (b) geotagged media on the pro's profile, the one legitimate "helps Maps" effect.

Before → after

Before (manual / generic-AI request tool) After (Map App)
When the ask happens Manual, remembered later Auto-prompt at job sign-off
Whose device / account Often the pro's phone (a filter risk) or a later text The customer's own phone and account
Customer path to Google Search listing → sign in → blank box Scan QR → review surface (photo-enabled) with topic chips
Typing required Full review from scratch Optional; chips seed the first sentence
Job photos None, or risky to attach Posted to the pro's own profile media; offered to the customer to reuse
Pro's proof None Read-API, job-bound confirmation it posted

Other deliverables

Built in Figma with Dev Mode handoff: a glove-tested component set (44px+ targets, one-handed reach map), the QR/deep-link generation flow, and the job-bound confirmation state.

Dashboard — On-site capture closes the first drop-off

On-site capture closes the first drop-off
Scope: Last 30 days · iOS · Map App pilot (6 pros)
Guiding question: Did moving the ask to job sign-off raise how often it happens?

  Review requested per completed job
    Before (field baseline) ............ 23%
    After (auto-prompt at sign-off) .... 78%

Key Insight: Firing the prompt inside the sign-off flow removed the
"forgot to ask" loss; the ask now happens on roughly four of five jobs.

Prototype / Test — Pre-filling the review text raised posts but Google removed them; suggested topics fixed both

In this section: The experiment · What it taught

The biggest customer-side friction was the blank text box, so the first hypothesis was to pre-fill a complete draft review the customer could post with one tap. It was A/B tested against the suggested-topic chips in Statsig over the pilot.

The failed variant. Pre-filled drafts lifted the immediate post rate to 31%, the highest of any variant. Within seven days, 22% of those reviews were removed or filtered by Google, and three pilot customers commented the wording "didn't sound like me." Templated, near-identical reviews tripped Google's authenticity filters, so the net count of surviving reviews came in below the chips variant.

Pre-filled drafts post fast and get filtered out
Scope: Statsig A/B · iOS · Map App pilot · 2 variants
Base: ~210 review opportunities across 6 pros (~3 pros / arm)
Guiding question: Which variant produces the most reviews that survive?

  Variant A — Pre-filled draft
    Posted .......................... 31%
    Removed/filtered by Google (7d) . 22% of posted
    Net surviving ................... ~24%

  Variant B — Suggested-topic chips
    Posted .......................... 41%
    Removed/filtered by Google (7d) . 3% of posted
    Net surviving ................... ~40%

Read with care: with ~3 pros per arm, this is a DIRECTIONAL result, not a
statistically powered one. The decision to ship Variant B rested on the
consistent direction of the effect and the asymmetric downside of Variant A —
templated reviews removed by Google's authenticity filters.

What it taught. Writing to a third-party platform means designing for that platform's integrity rules alongside the user's effort; both have to be satisfied at once. Pre-filling optimizes only effort and hands Google exactly the templated text its filters exist to catch. The chips variant shipped.

Outcomes & reflections

In this section: Causal chain · Limitations · Compliance-by-design · Competitive context · Reflections · References

Causal chain (pilot, 6 pros)

Capture moved on-site, so the rare field review that posted days later — when it posted at all — was replaced by a review captured in ~90 seconds at the door. The job-to-review rate rose from ~4% to ~32%, which lifted reviews posted per pro per month from ~1.2 to ~9.4, and that steadier velocity is the input local-SEO practice associates with local-pack ranking. Over the pilot window, pilot Google Business Profiles showed profile actions (calls + direction requests) up ~18% — reported as a leading indicator rather than a causal claim, given n=6, an 8-week window, and no control group. Among the 6 pilot pros, Week-4 retention was 5 of 6, and all 6 said they would recommend the app.

Metric Before After Δ
Time from job done to review posted days (if ever) ~90 sec on-site capture
Job-to-review rate ~4% ~32% +28 pts
Reviews posted per pro / month 1.2 9.4 ~8×
Reviews removed by Google (7-day) n/a 3% of posted low filter rate
Google Business Profile actions (pilot) baseline ~+18% leading indicator; not causal-attributed

Scale note: at one local business's volume, going from ~1 to ~9 reviews a month is the difference between a stale listing and one Google reads as active — the lever that moves local-pack position.

Limitations (stated, because a portfolio claim is only as strong as what it concedes)

  • Small pilot. n=6 pros, with the A/B at ~3 per arm. The funnel lift is directional; the ship decision rested on direction + the asymmetric platform-filter risk of the pre-filled variant, not on statistical significance.
  • Profile-action lift is confounded. The ~18% is uncontrolled and subject to seasonality, competition, and algorithm changes; it is reported as a leading indicator to validate at scale, not a causal result.
  • Time-to-review baseline is thin. Only 2 reviews posted in the field, so the "before" timing is an observation, not a stable median; the on-site ~90 seconds is the measured, repeatable figure.
  • API constraints are load-bearing. The product cannot post the review or its photos; it reduces effort on the customer's device and reads results back. It depends on the place-ID deep link continuing to expose the photo option on mobile — a known fragile point.
  • Attribution is heuristic. Binding a posted review to a specific job relies on reading new reviews and matching by time/place, not a guaranteed identifier; the confirmation is a strong signal, not proof.
  • Privacy. Job photos and location pins are customer-premises data; onboarding captures explicit consent and stores location at job granularity, not as a precise home address beyond what attribution requires.

Compliance-by-design (a strength the original left implicit)

  • No review gating. Google prohibits soliciting reviews only from customers you expect to be happy. The prompt fires on every signed-off job, so the product is structurally non-gating.
  • No fed/templated reviews. Authorship stays with the customer (their words via chips, their account), which is what passes authenticity filters — the same insight the A/B confirmed.
  • No self-review risk. The customer reviews from their own phone and account; the pro's photos go to the pro's own profile media, never injected into the customer's review.

Competitive context

Tools like Podium, NiceJob, and HighLevel send review requests by SMS/email after the fact. Map App's wedge is on-site, job-bound capture: the request fires at the moment willingness peaks, from the customer's own device, with attribution and proof built in — closing the temporal leak the after-the-fact tools leave open.

Reflections (transferable principles)

  • The conversion bottleneck in review collection is temporal: willingness peaks at job completion and decays within minutes, so capture has to live in the field or it does not happen at all.
  • When you design toward a platform you don't control, its API constraints define the problem. Here, "you cannot post the review" reframed the work from generation to effort reduction with preserved authorship — and that constraint turned out to point at the same place as the platform's authenticity rules.
  • Lowering user effort and respecting a platform's integrity signals are one design problem, not two; optimizing only effort produces output the platform throws away.
  • Field-first constraints (one hand, gloves, no time) are a stronger design brief than aesthetic preference; the interface that survives a job site is the one that gets used.

References (for the platform-constraint claims)

  • Google Business Profile / Reviews API supports reading, replying to, and accessing media of reviews — but provides no endpoint to create a review (Google for Developers, My Business API reference, 2026).
  • Photos in a Google review are added by the reviewer from their own device while writing or editing the review (Google review how-to documentation, 2025).
  • Company-fed review short links can strip the photo option on mobile and are used as an authenticity signal (Local Search Forum, practitioner reports).
  • Google's review policies prohibit review gating and filter templated/incentivized content (Google review policy).