How a hunch about a hidden behaviour — couriers and customers trying to reach
each other through the app — became a measurable problem, then a working
solution. Driven by UXCam, validated in SQL Server, shipped as a chat.
The product team kept hearing the same anecdote from support: couriers reaching
out about parcel access codes, customers asking where the parcel actually was —
but the app didn't have a chat. Yet.
The hypothesis was uncomfortable: people were already doing it. They just used
a comment field at the bottom of the parcel screen as a chat — a feature it was
never meant to be.
{/* Quote-like callout */}
"Czy wejście do klatki jest wewnątrz osiedla czy na zewnątrz?"
A real comment from October — being used as a question to the customer.
);
// ── The before-state — visible only to a few ────────────────────────────────
const DLBefore = () => (
Before · the original
A comment field nobody was supposed to read like that.
Couriers were typing real questions into the parcel "comment" field. The catch:
the comment was only visible in an internal hub view — and even more clearly to
analysts running SQL Server queries. The customer never saw most of them.
{[
['Comments at the bottom', 'A small grey "comment" field below the parcel info. Built for one-line notes, used as a chat.'],
['Hub-only visibility', 'Only the internal hub view rendered the comments. The mobile customer rarely saw them.'],
['Analyst-grade discovery', 'The pattern was clearest in SQL Server: parcels with multiple comments, time-stamped minutes apart.'],
].map(([t, d]) => (
{t}
{d}
))}
);
// ── Research methodology ───────────────────────────────────────────────────
// Visual thinking process — two lenses converging on a single insight.
// No code snippets, no jargon, no invented keywords.
const DLResearch = () => (
How I proved it
Two lenses. One picture.
Numbers tell us the size of a problem. Observation tells us its shape.
I needed both — one to justify the work, the other to design for it.
{/* Dotted connector lines linking the two lenses to the insight */}
{/* LENS 01 — Data: the scale */}
Lens 01 · Data
The scale.
I looked at one month of comments left on parcels. Where the same
parcel collected more than one note, with short gaps between them,
I treated it as a conversation in disguise.
{/* Mini bar chart: distribution of comments per parcel */}
= 4 && i <= 8 ? DL_ACCENT : 'rgba(246,239,233,.18)',
borderRadius: 2,
boxShadow: i >= 4 && i <= 8 ? `0 0 12px ${DL_ACCENT}55` : 'none',
}} />
))}
1 msgpeak · 5–7 msgs12+
{/* LENS 02 — Observation: the shape */}
Lens 02 · Observation
The shape.
I watched the recorded sessions for those parcels. Couriers opening
the comment, leaving, coming back minutes later to read a reply.
The motion was unmistakable — it was a chat.
{/* Behaviour loop — 6 steps where one conversation should be enough */}
A loop where one conversation should have been enough.
{/* The convergence node */}
The insight
Couriers and customers were already talking. The product just didn’t notice.
);
// ── Toolkit — UXCam + SQL Server as the named research stack ────────────────
// Sits between Hypothesis and Before. Names the tools clearly, says what each
// one did, without leaning on code snippets.
const DLToolkit = () => (
The research toolkit
Built on UXCam and{' '}
SQL Server.
Two tools doing two different jobs — one to see the behaviour, one to size it.
Together they turn a support anecdote into something a roadmap can act on.
{/* UXCam */}
{/* Logo plate */}
{/* Play / eye glyph */}
Behaviour
UXCam
Session replays and heatmaps from the courier app. I watched how couriers
actually used the comment field — opening it, leaving, coming back to read
a reply. The motion told me it was already a chat.
{/* Faux device frame with playhead bar */}
Queried the production parcel data to measure how often a single delivery
collected more than one comment, and how tightly those comments clustered
in time. The behaviour I saw in UXCam scaled into thousands of parcels.
{/* Faux table summary — no SQL, just shape of result */}
);
// ── Decisions / process ─────────────────────────────────────────────────────
const DLDecisions = () => {
const items = [
['01', 'Promote contact to first-class', 'Two big icons — call and chat — directly under the parcel info. Make the option exist on the screen the courier is already on.'],
['02', 'Keep the comment, narrow its job', 'The comment field stays for notes to the next courier shift — clearly separated from the new conversation channel.'],
['03', 'Same UI for both sides', 'The customer-facing app and the courier app use the same chat surface. One mental model, no role-specific quirks.'],
['04', 'Inbox, with unread counts', 'A dedicated "Skrzynka" tab. Notifications + Korespondencja separated, parcel number front-and-centre.'],
['05', 'Anonymised identities', 'Names appear as placeholders. Parcel number, not personal data, is the conversation anchor.'],
];
return (
Design decisions
Five calls, made on the evidence.
{items.map(([n, title, desc], i) => (
{n}
{title}
{desc}
))}
);
};
// ── The redesign — walkthrough ──────────────────────────────────────────────
const DLPrototype = () => {
const steps = [
{ src: 'case-assets/delivery/parcel-redesign.png', n: '01', t: 'Parcel — with contact',
d: 'Two prominent icons under the address: call and chat. The comment field stays, demoted to a "note to next shift" role.' },
{ src: 'case-assets/delivery/inbox.png', n: '02', t: 'Inbox · Correspondence',
d: 'A dedicated tab. Correspondence and Notifications split. Each row is anchored by the parcel number — never a person.' },
{ src: 'case-assets/delivery/chat.png', n: '03', t: 'Conversation',
d: 'A standard messenger surface. The parcel number sits in the header so the user always knows which delivery they are discussing.' },
];
return (
The prototype
From comment field to in-app chat.
Four screens carry the new conversation channel — from the parcel screen the
courier already lives on, through a proper inbox, into a chat that names the
parcel rather than the person.
{steps.map((s, i) => (
{s.n}
{s.t}
{s.d}
))}
);
};
const DLModes = () => (
Light & dark mode
Built for the doorstep, not the desk.
Couriers work in glare, rain and dim stairwells — often one-handed. A full
light and dark theme lets the app match the environment: dark mode saves
battery and eyes at night, light mode stays legible in bright daylight.
One toggle, every screen.
{[
['Why both', 'A delivery app lives outdoors. No single theme works across a 10-hour shift that spans daylight and dark.'],
['Same contrast budget', 'Both themes hit the same legibility bar — status colours (red / green / amber) stay distinct in either mode.'],
['One tap, in Settings', 'The toggle sits in Settings — set once, persists. No per-screen decision, no hunting.'],
].map(([k, v]) => (
{k}{v}
))}
);
// ── Outcome ─────────────────────────────────────────────────────────────────
const DLOutcome = () => {
const stats = [
['1,400+', 'Comment-threads-as-chats', 'Detected in one month of October data — the volume that justified building real chat.'],
['2 → 1', 'Tools, then one', 'Couriers used to switch between the comment field and the support call. The chat collapses them.'],
['Shipped', 'Prototype validated', 'Validated with couriers and customer-side users. Greenlit for engineering.'],
];
return (