The CLIENT Approach for FDE System Design
Explore the CLIENT approach, a six-step checklist that extends the technical deep dive for integration-heavy design rounds. Learn how to turn workflow facts, source meanings, and access constraints into a first design. Understand how each step's output constrains the others and how the case studies apply the method.
We'll cover the following...
- What to learn before proposing the readiness screen
- What each CLIENT step produces
- Cedar’s landscape inventory
- When “ready” and “HOLD” seem to contradict each other
- A connected design that fits the available interfaces
- When evidence is missing or stale
- Why the read-only view wins
- Practice: Six CLIENT outputs for enrollment preparation
Suppose Cedar Rentals asks for “one equipment-readiness screen so desk staff can prepare handovers faster.” Drawing connections between its tools is straightforward; deciding what those connections can honestly tell staff takes more work. The CLIENT checklist turns workflow facts, source meanings, and access constraints into a first design that holds up under questioning.
What to learn before proposing the readiness screen
Start with the people doing the work, their obstacles, and an observable outcome. Working alongside domain experts to understand a consequential workflow and agree on what better looks like is central to FDE delivery.
At Cedar, desk staff find a reservation, look up its assigned asset in a maintenance export, resolve identifier mismatches, and complete checkout in the existing reservation tool. Discovery reveals competing needs:
Desk staff: Shorter handovers and fewer repeated lookups.
Maintenance staff: Unresolved safety holds must remain visible.
Reservation system owner: No reservation writes from the integration.
The outcome statement is: “During a one-branch pilot, reduce median time from starting reservation review to recording checkout from 12 minutes to 5 minutes, without checking out an asset with an unresolved safety hold.”
This defines the task, baseline, target, and safety condition. The architecture proposes a way to help; pilot measurements establish whether the target is achieved.
Scope the first version to displaying readiness evidence for assigned assets at one branch. Exclude reassignment, automated checkout, and replacement of either source application.
What each CLIENT step produces
CLIENT expands to Context, Landscape, Integration points, End-to-end design, Non-happy paths, and Trade-offs. It builds on the four-step approach from the technical deep dive covered earlier in the course: start with the problem, match the architecture to it, account for enterprise constraints, and define evaluation before deployment. CLIENT keeps those steps and adds the parts that integration-heavy rounds probe hardest: integration points, failure paths, and trade-offs. Its Context and ...