Synthesis: Assembling A Complete AI-Native Flow With An 8-Step Checklist
Assemble the previous 9 lessons into a single 8-step checklist, run it on LeaseReader to see how the decisions constrain each other in order.
Synthesis: Assembling A Complete AI-Native Flow With An 8-Step Checklist
The last nine lessons separated out each decision - confidence, latency, error states, human-in-the-loop, steerability, explainability, onboarding, prototyping. In a real product, they don't stand alone: choosing one creates constraints for the others. This final lesson doesn't teach a new concept - it's a checklist that reassembles everything into one design process, plus an example that runs the whole checklist on a complete flow.
1. An 8-step checklist - applies to any AI feature, in the order you learned it
- Identify which axis of the output will vary (Lesson 27) - shape, time, or certainty? Whichever axis doesn't vary, skip it - don't over-design for it.
- How open is the input, and how is discoverability handled (Lesson 28) - if input is still a rigid form, skip this step.
- Confidence thresholds and matching behavior (Lesson 29) - how many tiers, what each one does differently.
- Expected latency and the technique for masking/reducing the wait (Lesson 30) - if the task is always fast (under 1-2s), a static spinner is enough.
- How the 3 failure types are handled (Lesson 31), and which human-in-the-loop stopping point fits the Cost of Failure (Lesson 32) - these two always go together, since the fallback plan is exactly where a human steps in.
- How much steerability and explainability are needed (Lessons 33, 34) - scaled to output complexity and Cost of Failure, not switched on by default.
- Onboarding at the point of interaction (Lesson 35) - if step 2 opened up free-text input, this step is mandatory.
- Pick the prototyping technique that matches the exact question you need answered, before building the real thing (Lesson 36).
This order isn't arbitrary - steps 1-2 shape the kind of problem the product will run into, steps 3-6 are the response to that problem, step 7 teaches the user to live with the design you chose, and step 8 is the cheap way to test before committing to a real build.
The 8-Step Checklist: Assembling A Complete AI-Native Flow
The order isn't arbitrary - steps 1-2 shape the problem, 3-6 are the response, 7 teaches the user, 8 tests cheaply.
2. A full checklist run: LeaseReader (used back in Lesson 29)
The AI tool that answers questions about lease agreements, now assembled in full:
| Step | Decision for LeaseReader |
|---|---|
| 1. Varying axis | Mainly confidence (an answer can be clear or vague depending on the lease), length varies little (always 1-3 sentences) |
| 2. Input | Still open (free-text questions), but narrow scope (only about the lease), so discoverability needs are light |
| 3. Confidence | 3 tiers, as already designed in Lesson 29 |
| 4. Latency | Fast task (under 3s, since it's just lookup, not multi-step reasoning) → skeleton state is enough, no need for streaming |
| 5+6. Failure & HITL | Medium Cost of Failure (misreading a lease clause can cause a real dispute) → level (b) execute + easy undo: answer immediately, but always with a "View original clause" button to self-verify, no per-answer review gate |
| 7. Steerability/explainability | Explainability form (a) citation is mandatory (point to the exact lease passage); steerability isn't needed since the output is short, nothing to "adjust separately" |
| 8. Onboarding | 3 sample-question chips ("Am I allowed to have a pet?", "Who pays for repairs?"...) right below the input box |
| 9. Prototype | Start with (b) mock response - fix a few sample question/answer pairs to test the 3-tier confidence UI on its own, before wiring in real RAG |
3. The decisions constrain each other - why the checklist must run in order
Looking at the table above, the decisions constrain each other: because latency is low (step 4), no streaming is needed; because Cost of Failure is medium rather than high (step 5), review-before-execute isn't needed; because the output is short (step 1), steerability is dropped entirely. That's exactly why the checklist has to run in order - running step 6 (steerability) before knowing step 1 (whether the output has multiple parts) leads to over-designing.
Final module exercise: Pick 1 of the cases used throughout the module - HireFlow, InvoiceBot, ShiftPlanner, PitchCraft, or BudgetAdvisor - and run all 8 checklist steps into a table like LeaseReader's above. The output should be a design detailed enough to hand straight to an engineer/designer to build a prototype - true to the spirit of "module ends = working demo."