Journey Check

Find the real entry point

Before judging a single screen, pin down who is here, what they believe they are doing, and the result that would actually satisfy them. Trace the entry point they will really use, not the one on the diagram, and follow every branch to its real ending — success, partial success, failure, and the moment someone simply gives up.

• Name the person and the job they came to finish
• Trace the path they will actually take, not the intended one
• Follow every branch to its real ending, including quitting
• Separate what is built today from what is only proposed

Count the hoops

Walk the recommended path and literally tally the clicks, logins, copied identifiers, repeated facts, and context switches between browser, terminal, and app. The count is not a grade — it is a forcing function that makes every step justify its own existence.

• Screens, fields, and confirmations along the happy path
• Facts the person types twice because two systems will not talk
• Waits with no honest progress and no way to recover
• Steps that configure the machine instead of producing the result

Hide the plumbing, not the person

An interface that just exposes database columns, config flags, or internal states is not a UI, it is a leak. Group inputs around intent, default what the system already knows, and offer one confident path instead of five equally plausible buttons. Push expert knobs behind an advanced view instead of asking everyone to learn the internals first.

Close every dead end

Every state needs a next step, an honest way back, or a deliberate place to stop.

• No blank screens with nothing useful to do
• No error message that only says try again
• No success screen that hides work still left unfinished
• Resume interrupted work instead of restarting from zero

Completion is the result, not the receipt

A saved record, a successful response code, or a finished sign-up step is not completion if the person still cannot do the thing they came for. Pin down the first moment the work becomes genuinely useful, and push every optional integration or preference past that line.

Pair people and Familiars as equals

When a person and their Familiar act on the same task, they need one shared object, matching underlying powers even when the surfaces differ, visible and attributable actions, and a real undo. Never turn the Familiar into a suggestion box the person has to retype by hand, and never let it act through a shortcut the person cannot see or reverse.

Put judgment and execution in the right hands

Familiars are for the fuzzy part: intent, ambiguity, and priority calls. Tools are for the exact part: parsing, counting, converting, storing, retrieving. A converter converts and returns a result or a precise error — it never hides a secret "figure it out" mode. Favor a handful of clear tool families over a sprawling catalog that forces guesswork, and make sure every tool explains what it will do before it runs and what actually happened once it has.

Name the limits out loud

Every cap, timeout, and retry policy needs an owner. Before quietly truncating a large job, expose the real scope and let the person or the Familiar choose to process everything, sample, or stream. When a result comes back partial, say so, say what is missing, and say how to get the rest.