Talabat Pro

The problem the component solves

A Pro customer gets free delivery only above a minimum order value. Below it, nothing on the menu says how close they are, and that gap is invisible at the moment it matters: while the basket is being built. The answer is a progress bar docked to the basket bar.

A Talabat restaurant menu on mobile showing the Shake Shack page with delivery details, a free delivery with Pro badge, and a docked footer holding a progress bar reading add AED to order and get free delivery above a View basket button. — The component in place. It lives in the docked footer, under the basket CTA, where the decision is actually being made.

Everything after that is making one small component survive two platforms, two writing systems and every basket value a customer can reach.

The anatomy

Every element resolves to the global library; nothing on the sheet states a hex. Two of the five are instances of components someone else owns, recorded so a change upstream has a known blast radius.

Spacing is a scale, not a number

The layout and spacing specification, showing redlines marking a 16 pixel side margin labelled with the S spacer token, and vertical spacer instances measuring the gaps between the bar, the message and the button. — Redlined against the spacer scale. The margin is labelled S, so it moves when the scale moves.

The margins are redlined as S, not as 16. A number is a decision someone repeats on every screen. A token is a decision made once.

Acceptance criteria, because a state is not a picture

The written acceptance criteria for the component, in given, when and then form, covering the case where the basket does not meet the minimum after a discount is applied, the case where it still does not meet it, and the case where it does. — The criteria as written for engineering. Three branches, each with what the customer is told and what the basket CTA shows.

Three outcomes, written rather than drawn, because the discount interacts with the threshold:

Basket below the minimum after the discount: say how much more to add.
Still below after more items: same message, updated number.
Basket meets it: say free delivery is unlocked, and the bar vanishes.

That last clause gets missed. A full bar that stays on screen is a component still asking for something it already has.

Motion and the Arabic mirror

The behaviour specification, showing the bar at several fill levels with the rule that it moves 11.4 pixels for every dirham spent, and an Arabic right to left variant where the message and the Pro badge swap sides. — Movement as a rate, and the mirror. Both on the sheet, so neither was invented during the build.

The rate: 11.4px per dirham, so the fill is correct at every basket value, not only the two I happened to draw.

The mirror: message and badge swap sides, the fill runs from the right, and the type moves to the Arabic scale. Specified beside the English, not in a follow-up.

Two hard calls inside one small component

Hard call

Arabic needs more room than English left behind

The free delivery message runs long in Arabic, and at small widths the message and the Pro badge collide. Translated strings can grow far beyond their English length, and a mirrored layout does not create space.

RejectedShrink the type until it fitsMinimum legible size on a phone is a floor, not a preference, and Arabic script suffers at small sizes before Latin does.
RejectedTruncate with an ellipsisThe amount still needed is the entire message. Cutting it defeats the component.
TakenLet the message wrap, keep the bar on its own line, and draw the Arabic beside the EnglishThe mirror is specified on the same sheet, so the layout was designed for its longest language rather than patched for it.

What it cost One extra line of footer height on some devices, agreed with the app team before the build. That conversation is the reason the RTL frame sits on the main sheet rather than in an appendix.

Working with engineering on a release cadence

On mobile the specification is the deliverable, and the release cadence is why.

Acceptance criteria written with engineering, not handed to them. The discount interaction surfaced in that conversation rather than in QA.
Upstream dependencies named on the sheet, so a change has a known blast radius.
One review before the build, one after, against the states, in both writing systems, on a real device.
Arabic reviewed by someone who reads Arabic. Part of the definition of done, not a follow-up ticket.
The fix lands in the component, never on the screen. Patching the screen is how a component ends up with four versions.

Why this is the sheet I would show

The smallest thing in the project, and the one where every decision is written down: what each part is called, what it binds to, how fast it moves, what it says in three situations, and what it does in a second writing system. A web component can be fixed in an afternoon. A Flutter build ships to an app store and waits.

Impact at a glance