Flow LGX, part 1: the brief — one platform for one logistics business

About this project

Month by month, how a logistics platform for a Toronto client went from a simple brief to a live, multi-company SaaS product.

• Read the case study
• All Flow LGX stories

In short

A Toronto logistics company wanted one place to run jobs, warehouses and invoices instead of email and spreadsheets. Before designing anything, we wrote down the life of a single job — and that one page guided the whole project.

What the client asked for

The first brief was refreshingly plain. The client ran a logistics and warehousing business and wanted a single web platform for their own team: a place to create jobs, see where freight was, receive and store goods in the warehouse, handle problems, and bill customers. There was no talk of selling the software to anyone else. It was an internal tool for one company.

The pain behind the brief was familiar. A single shipment could touch a quote by email, a phone call to a carrier, a note on the warehouse whiteboard, a photo of a damaged pallet on someone’s phone, and an invoice typed into accounting software days later. Nobody had one screen that told the whole story of a job.

The questions we asked before drawing anything

In discovery we avoid talking about screens too early. Screens are easy to agree on and hard to change once the data underneath is wrong. Instead we asked about the work itself:

• Who touches a job, in what order, and who is allowed to change it at each step?
• What does “done” mean for a job — delivered, signed for, or paid?
• What goes wrong most often, and how is it recorded today?
• Which numbers does the owner look at every morning?
• What must still work when someone is standing in the warehouse with a scanner rather than sitting at a desk?

One job lifecycle, written down

The most useful thing to come out of October was a single page describing the life of a job: request, booking, pickup, warehouse, delivery, and invoice. Every later feature hangs off that line. If a screen could not say which step of the lifecycle it served, it did not belong in the first release.

We also listed the people involved — administrators, warehouse staff, dispatchers, and customers — and what each of them needed to see. At this point there were only a handful of roles. That number grew a great deal later, which is a story for part 7.

Why we kept the first scope small

It is tempting to promise everything in the first meeting. We did the opposite: one company, one lifecycle, a short list of roles, and a first milestone that only covered the user interface. A small, clear scope made it possible to show working software early, and — as it turned out — gave the project a solid base when the client’s ambitions grew six months later.

What we shipped

• A one-page job lifecycle agreed with the client
• A first list of user roles and what each one must see
• A list of the most common problems: damaged, missing, partial, and refused freight
• Milestone 1 defined as the user interface, delivered from the designer’s work

Lesson learned

Write the lifecycle of the core record — here, a job — before you design a single screen. Every later decision becomes easier to judge.