Logic Gates Logistics

This project did not begin with a formal discovery study. I did not conduct interviews, surveys, personas, or usability testing before the design work. Instead, the starting point was my direct exposure to transport operations while working at Logic Gates and the practical steps involved in moving a request from customer enquiry to fulfilment.

A customer may only need to choose a service, describe the trip, add security support, understand the price, and track what happens next. Behind that apparently simple journey, the company still needs to review the request, confirm payment, adjust pricing when necessary, assign a driver and vehicle, record security requirements, and keep the booking status current.

That difference between what the customer should see and what the operations team must manage became the central design problem.

Logic Gates is one service ecosystem expressed through two product formats: the mobile app I designed in Figma and the responsive web platform developed later. Within the web platform, the customer-facing experience and the internal operations portal work with the same booking journey from different sides.

The experience is organised around one booking journey. Customers create and review a request through the public and account-facing screens. Operations staff use the internal portal to add the details needed to coordinate fulfilment and move the same request forward.

On the customer side, I designed service discovery, registration and sign-in, a four-step booking flow, price review, payment options, booking history, and status visibility. On the operations side, I designed booking and customer records, payment visibility, price adjustments, driver and vehicle assignment, security coordination, and status progression.

Keeping the interfaces distinct allowed each side of the service to stay focused. Customers do not need to see internal coordination fields, while operations staff need more context and control than the customer interface should expose.

Submitting a booking is only the midpoint of the service. The request still needs operational attention before it can become a completed trip.

The service blueprint connects five stages: discovery, access verification, trip configuration, payment or submission, and fulfilment tracking. For each stage, it separates what the customer does, what the interface shows, what the system records, and what operations needs to handle.

This distinction was important because a customer-facing confirmation screen cannot prove that resources have been assigned. The operations portal needs its own explicit controls for reviewing the request, checking payment, adjusting the commercial details, assigning a driver and vehicle, recording security support, and moving the booking through paid, assigned, completed, or cancelled states.

The bookings list supports scanning across multiple requests. Staff can see customer details, service type, date, price, payment state, and booking status before opening the full record.

Assignment and commercial controls sit beside the booking details so operations can act without switching between disconnected tools. The workflow brings driver and vehicle details, security assignment, price adjustment, payment state, and booking progression into the same context.

Three principles kept the mobile and web work aligned as the service expanded: progressive disclosure for customers, explicit status language for uncertain moments, and contextual controls for operations staff.

1. Reveal booking questions in a clear sequence instead of presenting one dense form.
2. Keep payment, assignment, and trip progress as separate states so the interface does not imply more certainty than exists.
3. Place operational actions beside the booking context needed to make each decision.

These principles allowed the customer screens to remain calm and guided while the operations portal could support denser information and more frequent decision-making without feeling like a different product.

The mobile app exploration came first and uses light surfaces, mint service cues, and compact selection cards. The later responsive web product established its own navy and teal interface rules for public booking, customer accounts, and operations. The two formats belong to the same service journey, but they are separate visual explorations.

Palette in use

Navy

Headings and key actions

#093655

Teal

Booking and service cue

#1CC5A7

Off-white

Quiet page surface

#F9F9F9

Muted grey

Supporting information

#6F6F6F

Type and hierarchy

The responsive web UI specifies Inter. Strong navy headings and compact supporting copy keep service choices clear while denser operations views use labels and status badges for scanning.

Screen evidence

Open the existing screen at full size.

Recurring interface patterns

• Action hierarchy

  Teal and navy actions distinguish primary booking from supporting paths.

• Form surfaces

  Rounded cards and inputs group each decision in the staged booking flow.

• Status badges

  Payment and fulfilment use distinct labels and semantic colour treatments.

What I learned

Logic Gates taught me that a service product has to be designed across both sides of the experience. A simple booking form is not enough if the organisation cannot review, assign, update, and fulfil the request behind it. The strongest part of this project is not an individual screen; it is the connection between customer intent and operational action.

The project also showed me how designing the full service exposes gaps that individual screens can hide. Service categories have to align across marketing and booking. Payment states need to be distinct from trip states. Price changes need a reason and visible source. An assignment is not only a checkbox; it needs enough context for operations to understand what has been confirmed.