Case 02 / 06 — Tagga — Own product
Kenneth Jensen — Product design — Copenhagen
02 / 06Status: Shipped · Live2022 — ongoing

Tagga®

A live map for people who ride together — and don't want an account to do it.

Spec
RoleFounder / Lead product design
ClientOwn product
Year2022 — 2025
Duration18 months to v1 · ongoing
PlatformsiOS / Android / Web
Team1 design / 2 engineering
My boundaryEverything above the backend
Shipped2024.06 (v1) · 2025.03 (v2)
Fig. 01
Live map — ride of 6, Sjælland, 2024.06
Ride code
KV7QP
Duotone photograph / product frame · drop real hero here
Riders on map
06
02 · Situation

Group rides fall apart at junctions. Someone misses a turn, the crew stops, phones come out, and a location gets shared as a static pin that is wrong within a minute. The tools that exist — Find My, Life360, Google location sharing — assume a persistent social graph and an account. They were built for families who track each other for months, not for eight people who met at a petrol station and will disband by dinner.

I started Tagga in 2022 as a rider with this problem. It became a product when hikers, festival groups and parents at theme parks began asking for the same thing: see where everyone is, right now, for a few hours, and then forget it.

Users at v1
Motorcycle crews
By v2
Hikers · Festivals · Families
03 · Problem

Make a live map a stranger can join in under ten seconds, with gloves on, that stops knowing anything about them when the ride ends.

Constraints — what made it hard
01

No account, no identity layer.

No email, phone number or SSO anywhere in the flow. Whatever identifies a rider has to be created at the roadside and thrown away afterwards.

02

Six hours of GPS for under 15% battery.

Measured on a mid-range Android, screen mostly off. Above that, riders switch the app off at the first fuel stop and it never comes back.

03

Readable in one second at 90 km/h.

Handlebar mount, direct sun, polarised visor. Every element on the map has to answer "who is ahead, who is behind, is anyone stopped" without a second glance.

04

Three platforms, one designer.

iOS, Android and a web share page shipped from a single system. Anything that needed a per-platform design pass didn't get built.

05

Rural routes drop to EDGE, or nothing.

The map must never present a stale position as a current one. Uncertainty had to be visible in the same language as position itself.

04 · Working

The middle of the process, at the size it deserves. Twelve artefacts from eighteen months: interviews, discarded architectures, marker tests in direct sun, battery logs. Captions say what each one is and what it changed.

12 artefacts
2022.09 — 2024.05
A.01 — Interview notes, 11 riders / 3 crews2022.09
A.02 — Junction sketch
A.03 — IA v1, accounts discarded
A.04 — IA v3, session-first2023.01
A.05 — Join flow, 14 variants on one board2023.02
A.06 — Marker test, direct sun
A.07 — Battery log, Pixel 6a, 6h ride2023.06
A.08 — Stale-state studies
A.09 — Keypad iterations
A.10 — Web share page wireframe2023.11
A.11 — Android widget
A.12 — Onboarding copy drafts
05 · Decisions 04 decisions
D.01

The session is the object. Not the user.

On the table

A user model with friends, groups and history — the shape every competitor has. A hybrid where sessions are optional inside a profile.

Why this one

Every real use I observed was bounded: a ride, a hike, a festival day. Modelling the bounded thing directly removed sign-up, contacts, permissions dialogues and the privacy question in one move. A session has a start, a code, participants and an end. That's the whole data model.

What it cost

No retention loop that doesn't depend on someone starting a new session. No monetisable profile. Recurring crews re-enter a code every Sunday — a friction I chose over an account and still hear about.

D.02

Join by a five-letter code. No accounts.

On the table

Phone-number sign-up with contact sync. Magic-link email. Apple / Google SSO. A QR code on the organiser's screen.

Why this one

A crew forms at a petrol station with gloves on. Anything slower than reading five letters aloud loses the group. Five letters from a 30-character set give 24 million codes — enough that collisions within a live window never happened. QR lost because it needs two phones face-to-face; a code works over an intercom.

What it cost

No persistent identity: no ride history, no friends list, no push re-engagement. Retention has to be earned by the next ride, not by a notification.

Component — code entry (live)
_ _ _ _ _empty
D.03

Heading and speed on the marker. Not the name.

On the table

Name labels. Avatars. Initials in a coloured disc — the default in every location app.

Why this one

At 90 km/h the question is never "who is that" — crews know each other. It's "is the group moving, and which way." A chevron that rotates with heading and stretches with speed answers both in one glyph, and stays legible at 24px in direct sun where an initial does not.

What it cost

At a festival with twelve people, markers are indistinguishable. I added a long-press to reveal the name — a second interaction I'd rather not have — and a colour per rider, which capped comfortable group size at eight.

Component — marker states, fading on signal loss
live
30 s
2 min
5 min
stopped
D.04

Stale positions fade. They don't freeze.

On the table

Hide the marker on signal loss. Keep the last known position as-is. Show a "last seen 2 min" label next to it.

Why this one

A hidden marker reads as "they left". A frozen one reads as "they crashed". A label needs reading. Fading the marker in three steps — 30 s, 2 min, 5 min — puts uncertainty in the same visual channel as position, so it's understood at the same glance.

What it cost

Three extra states on every marker, across three platforms. And a rider fading out in a tunnel still triggers a worried phone call — the design communicates uncertainty; it can't remove it.

06 · System

One token set feeding SwiftUI, Compose and the web share page. Rider colours were picked for separation under deuteranopia against the map ground, not for brand.

38 tokens
6 components
Colour — rider set + map ground
rider.01
#1E3A8A
rider.02
#D97706
rider.03
#0F766E
rider.04
#7C2D92
rider.05
#B91C1C
rider.06
#111111
map.ground
#E9E5DA
map.road
#FFFFFF
Type — native stacks, one scale
KV7QPcode · 40/1 · +6%
Ride of 6title · 24/26
Share this code with your crewbody · 16/22
2.4 KM · 41 KM/Htelemetry · 12/16 mono
Component — marker + code entry
live
fading
stopped
K V 7 Q Pvalid · joining
K V 7 Q Xno such ride
07 · Surfaces v2 · 2025.03
iOS — Join screen
S.01 — Join. The whole first screen is the keypad.
iOS — Live map
S.02 — Map. Six riders, two fading, one stopped.
Android — Ride ended
S.03 — End. Route summary, then nothing is kept.
S.04 — Web share page, bare screen, full bleed
tagga.io/KV7QP
08 · Outcome Measured · 2024.06 — 2025.03
0s

Median time from install to visible on the map.

n = 4,120 first sessions

0%

Battery used over a 6-hour ride, Pixel 6a, screen mostly off.

Field log, 14 rides · target was 15%

0%

Of sessions are not motorcycle rides.

Inferred from speed profile

Not measured

Retention. By design there is no user to retain; I count sessions per code re-use instead, and that number is small and honest: most codes are used once.

09 · Reflection

I'd ship the web share page first, not last. It's the only surface that doesn't need an install, and half the people who join a ride are joining from a link someone sent them. Building it eighteen months in meant eighteen months of "download the app" as the first thing a newcomer saw — the exact friction the code was designed to remove.

I'd also stop being proud of the no-account decision sooner and measure what it cost. It was right. It was also the reason I couldn't tell anyone their ride was about to start.

— KJ · Copenhagen · 2025.04

10 · Next case 03 / 06
:Dribe Car leasing, redesigned across every digital surface. →