Redesign: Poppins, a two-step destination, and a splash that says what the app does

The effort pass, end to end. Every screen was run through one test — if I
remove this sentence, does the customer make a worse decision? — and the parts
that failed it are gone.

The flow

  Home ▸ BOOK ▸ Where is it going? ▸ When shall we collect? ▸ details ▸ booked

BOOK opens a sheet, not a form. The destination is browsed state-then-district
because a flat list of every serviceable district survives twelve and not
sixty, and search cuts across states because somebody who knows they are
sending to Chennai should not have to know which state it is in. Districts
multi-select, but only where the server allows it: BookingLimits advertises
maxDestinations: 1 until the Miler build keys on consignmentid, and a sheet
that ignored that would sell a booking the network cannot complete.

The pickup window is now a step the customer answers rather than a slot chosen
for them. A pickup window is a promise about somebody's afternoon.

What the screens stopped saying

Home lost the orb caption for returning customers and a four-cell live card.
Send lost the city strip, both address fields, the optional disclosure and
three sentences about charging — the route, the packages and the button are
what is left. Tracking lost a radar with a bike in it, a Milers-in-your-zone
count, a "Step 2 of 7" and a sentence describing the screen you were looking
at. The window sheet lost "Fastest pickup", "4 Milers nearby" and "Relaxed
evening handover".

Type

Poppins, which has no variable release — four static cuts, and the sans styles
set fontWeight alone because fontVariations on a static font is ignored in
silence. Every weight dropped a step and the tracking went deeper: Poppins is
built on near-circles and carries more ink than the humanist faces before it.

Objects

One lit sphere on Home, and the primary button now takes its gradient and rim
because a committing action that is not lit like the hero reads as a different
material. The tracking rail's connector is crimson as far as the parcel has
come, so the line is the progress bar. Confirmation is a white tick on green:
crimson is this app's action colour and that screen has nothing left to do.

Bugs found on the way

The OTP screen dropped digits. Four fields passing focus along lose a keystroke
that arrives mid-transition, so "1234" became "124" and the screen answered
"That code did not match" — blaming the customer for its own race. One field
now, four boxes that only draw.

Nothing ever asked for the customer's location: detectPickupLocation was the
OTP screen's job, so a restored session or an auto-login never triggered the
permission prompt and the pickup map had nothing to centre on.

The launcher icon and both splash screens pointed at a house drawn as two
vector paths — a placeholder that shipped.

The splash clock started when the widget was built rather than when it was
visible, so the truck got 0.45s of a 1.8s beat behind Android's own splash.
It waits on waitUntilFirstFrameRasterized now, raced against a timeout so a
binding that never reports one cannot strand the app.

Also: design/screens/ holds all 19 screens under readable names, tool/ has the
scripts that refresh them and rebrand the Lottie, and DESIGN.md is current.

flutter analyze clean. 88 tests, 1 skipped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EqVJPB9B4QuieZnBAAKgYQ

lib/data/dev_doormile_api.dart

@@ -442,6 +442,7 @@ class DevDoormileApi extends DoormileApi {
     required List<DestinationGroup> destinations,
     required String? slotId,
     FareEstimate? fare,
+    String? contactPhone,
     String? idempotencyKey,
   }) => _respond(() {
     if (destinations.isEmpty ||

lib/data/doormile_api.dart

@@ -123,11 +123,17 @@ abstract class DoormileApi {
   ///
   /// [idempotencyKey] must be **held across retries of the same intent**. A new
   /// key is a new booking, which is exactly what a double tap must not create.
+  ///
+  /// [contactPhone] is who the Miler calls at the pickup door. Null means the
+  /// signed-in customer, which is what it was always sending — the parameter
+  /// exists because the person handing over the parcel is not always the
+  /// person who booked it.
   Future<Booking> createBooking({
     required Place pickup,
     required List<DestinationGroup> destinations,
     required String? slotId,
     FareEstimate? fare,
+    String? contactPhone,
     String? idempotencyKey,
   });
 

lib/data/live_doormile_api.dart

@@ -382,6 +382,7 @@ class LiveDoormileApi extends DoormileApi {
     required List<DestinationGroup> destinations,
     required String? slotId,
     FareEstimate? fare,
+    String? contactPhone,
     String? idempotencyKey,
   }) async {
     if (slotId == null || slotId.isEmpty) {
@@ -404,7 +405,10 @@ class LiveDoormileApi extends DoormileApi {
         'slotId': slotId,
         'pickup': pickup.toBookingJson(
           contactName: customer?.name,
-          contactPhone: customer?.phone,
+          // The customer's own number unless they said somebody else is
+          // handing the parcel over. Same field either way — the contract has
+          // always carried it; it simply had one possible source.
+          contactPhone: contactPhone ?? customer?.phone,
         ),
         'destinations': [for (final d in destinations) d.toBookingJson()],
         // The delivery instructions the customer typed per destination. The

lib/data/models.dart

@@ -94,22 +94,52 @@ enum JourneyStage {
   static JourneyStage at(int i) =>
       JourneyStage.values[i.clamp(0, JourneyStage.values.length - 1)];
 
-  /// What a status pill should say. Operational stages roll up so the customer
-  /// never reads "Order created" as their status.
-  String get milestoneLabel => CustomerMilestone.of(this).label;
+  /// What a status pill should say.
+  ///
+  /// Deliberately **not** [CustomerMilestone.of]. The rail collapses the whole
+  /// pickup visit into "Booking created", which is right for a journey read
+  /// over days — but a pill on Orders, or the live row on Home, is answering
+  /// "what is happening to my parcel *now*", and "Booking created" is a poor
+  /// answer while a named Miler is two kilometres from the door. The two
+  /// surfaces want different granularity from the same stage, so they get
+  /// their own vocabulary.
+  String get milestoneLabel => switch (this) {
+    JourneyStage.booked => 'Pickup booked',
+    JourneyStage.assigned => 'Miler assigned',
+    JourneyStage.onTheWay => 'Miler on the way',
+    JourneyStage.arrived => 'Miler at your door',
+    JourneyStage.pickedUp => 'Package collected',
+    JourneyStage.orderCreated => 'Order created',
+    JourneyStage.inTransit => 'In transit',
+    JourneyStage.outForDelivery => 'Out for delivery',
+    JourneyStage.delivered => 'Delivered',
+  };
 }
 
 /// What the customer sees on the timeline.
 ///
-/// The backend keeps nine operational states; the customer gets seven
-/// meaningful ones. Operational detail ("Miler on the way", "Order created")
+/// The backend keeps nine operational states; the rail shows five. Operational detail ("Miler on the way", "Order created")
 /// appears as context under the current milestone rather than as another
 /// permanent row.
+/// The shipment's journey, as five milestones.
+///
+/// ── Why the pickup is one milestone and not four ──
+///
+/// This had seven: booked, assigned, pickup in progress, collected, in
+/// transit, out for delivery, delivered. Four of them described the *visit* —
+/// a Miler being found, riding over, arriving, weighing — which is an hour of
+/// somebody's afternoon, and the tracking screen already narrates all of it
+/// live in the crimson card at the top, by name, with a distance and an ETA.
+/// The rail was repeating that hour in four rows and then giving the whole
+/// rest of the journey — the part measured in days — the other three.
+///
+/// The rail's job is the shipment. Everything before the order exists is
+/// **Booking created**; the moment the Miler creates the order the parcel is a
+/// consignment with a tracking number, and the four milestones after that are
+/// the ones a customer checks back for over the following days.
 enum CustomerMilestone {
-  booked('Pickup booked'),
-  assigned('Miler assigned'),
-  pickupInProgress('Pickup in progress'),
-  collected('Package collected'),
+  booked('Booking created'),
+  orderCreated('Order created'),
   inTransit('In transit'),
   outForDelivery('Out for delivery'),
   delivered('Delivered');
@@ -119,13 +149,17 @@ enum CustomerMilestone {
   final String label;
 
   /// Which milestone an internal stage rolls up into.
+  ///
+  /// Everything up to and including the handover is the booking: the customer
+  /// has arranged a visit, and until the order exists there is nothing else to
+  /// call it.
   static CustomerMilestone of(JourneyStage stage) => switch (stage) {
-    JourneyStage.booked => CustomerMilestone.booked,
-    JourneyStage.assigned => CustomerMilestone.assigned,
-    JourneyStage.onTheWay || JourneyStage.arrived =>
-      CustomerMilestone.pickupInProgress,
-    JourneyStage.pickedUp || JourneyStage.orderCreated =>
-      CustomerMilestone.collected,
+    JourneyStage.booked ||
+    JourneyStage.assigned ||
+    JourneyStage.onTheWay ||
+    JourneyStage.arrived ||
+    JourneyStage.pickedUp => CustomerMilestone.booked,
+    JourneyStage.orderCreated => CustomerMilestone.orderCreated,
     JourneyStage.inTransit => CustomerMilestone.inTransit,
     JourneyStage.outForDelivery => CustomerMilestone.outForDelivery,
     JourneyStage.delivered => CustomerMilestone.delivered,