CDG OneFMS - Movement Order

02From form to workflow

The design problem wasn't really the form

The feature could easily have become a long list of fields: vehicle, date, from, to, address, contact, accessories, documents, remarks. But the real workflow was much easier to understand as five questions - and they became the mental structure of the experience.

Instead of

Design all required fields

I approached it as

Design the lifecycle of a vehicle movement

1. 01

   Plan

   Define what should happen.

2. 02

   Execute

   Handle what is happening.

3. 03

   Record

   Preserve what actually happened.

This distinction became especially important when reality differed from the original plan.

03UX strategy

Make complex vehicle movement predictable without making the interface rigid

Principles

The workflow follows four principles.

1. 01

   Inherit what is already known

   Customer and booking context should flow into the Movement Order automatically.

2. 02

   Focus the interface on movement

   Vehicle, schedule and From → To should visually dominate supporting information.

3. 03

   Reveal exceptions progressively

   One-time addresses and unusual handover information only appear when required.

4. 04

   Preserve intent and outcome

   What actually happened should never overwrite what was originally planned.

04Core experience

Start with context, not data entry

Movement Orders are created from an existing Service Booking, so creation begins by establishing context: Corporate Customer → Booking Reference → Create Movement Order.

Before entering anything, the user already knows whose booking this belongs to, which service it supports, and what business context surrounds the movement. The form can therefore focus only on information unique to the operation.

Supporting information sits below the primary operational decision rather than competing with it.

Make From → To the central object

The movement itself is the most important part of the order. So instead of presenting From and To as unrelated form fields, I treated them as one connected route: a vehicle is moving between two operational states.

For the normal case, the experience stays compact. If the vehicle needs to reach a customer address that isn't stored as a reusable location, additional fields appear only after that option is chosen - never during a normal branch-to-branch transfer.

Standard location

Location→Date→Time3 steps

One-time delivery

Contact→Address→Date / time→Additional information4 steps

Preserve planned versus actual

Creating an order describes intention. Completing it describes reality. Those aren't always the same thing.

A vehicle may be scheduled for delivery at Location A, then during execution the customer requests handover somewhere else. The system shouldn't replace Location A with Location B. Location A tells us what was planned; Location B tells us what actually happened. So completion records the outcome separately.

Planned

Hand-over From→Hand-over To

Actual

Actual hand-over From→Actual hand-over To

Complete records the real operational outcome. Cancel remains a separate path so an order that never happened can never appear as a completed movement.

05Designing for exceptions

The edge cases were part of the core workflow

In many products, edge cases happen rarely enough to remain secondary. That wasn't true here. The movement model needed to support at least three legitimate operational scenarios - and complexity appears only as the operation requires it.

1. 01

   Standard handover

   Minimal input.

   1. Known location
   2. →Known location

2. 02

   One-time delivery

   Reveal address, contact and delivery information only when required.

   1. Known location
   2. →Unique customer destination

3. 03

   Actual handover somewhere else

   Capture the actual handover without destroying the original plan.

   1. Planned location
   2. →Different real-world destination

06Supporting the full operation

More than a vehicle and two locations

The order also needs enough context to remain useful to everyone involved. These aren't the main experience, but they make the workflow operationally complete.

• Accessories

  Additional items handed over with the vehicle stay attached to the order.

• Attachments

  Documents and supporting files remain part of the same operational record.

• Remarks

  Free-form information captures things structured fields cannot anticipate.

• Audit context

  Users can understand who last updated the order and when.

07Designing for scale

One movement model instead of multiple separate forms

A simple solution could have been a delivery form, a return form, a workshop transfer form and an other-transfer form. But the underlying job is still the same: move a vehicle from one state or location to another. So CDG OneFMS uses one Movement Order model whose behaviour adapts to context.

• Location types

  • Known location
  • One-time location
  • Other / actual location

• Lifecycle

  • Create
  • View
  • Update
  • Complete
  • Cancel

New movement cases reuse the same structure instead of introducing another specialised form each time.

08Outcome

From a static movement form to a flexible operational workflow

The redesigned experience supports the complete movement lifecycle.

• Less repeated input

  Existing booking context flows naturally into the order.

• Complexity only when needed

  Exceptional addresses and handover information appear conditionally.

• Better operational history

  The system preserves both what was planned and what actually happened.

09Reflection

Enterprise forms are workflows disguised as forms

Movement Order initially appeared to be a form-design problem. Answering these questions defined the experience far more than arranging individual fields.

• What does the system already know?
• What information genuinely changes?
• What happens when reality differs from the plan?