User flow

A user flow is written per goal, not per screen: “return an item”, “add a second driver”, “pay an invoice”. It names the entry points, the decision at each step, the data the system needs at that point, and the exits — success, abandonment, and every error state.

The error states are the part usually missing and the part that decides the experience. A flow that documents only the path where everything works has described the demo, not the product; most of the support load and most of the abandonment lives in the branches nobody drew.

It is also the cheapest artefact in a build. Disagreements that would cost weeks in code are resolved in an afternoon on a flow, because a flow makes the missing decision visible: who is allowed to do this, what happens if they are half way through, what does the system already know.

Drawing screens instead of states

A flow made of screens multiplies as edge cases appear, because each new condition needs a new screen. A flow made of the states the system can occupy stays the same size and covers the cases nobody thought of yet. Model the states; the screens fall out of them.

Information architecture

How the content and functions of a product are named, grouped and nested — the structure a person navigates before they read anything.

---

Funnel

An ordered model of the steps between first contact and purchase, used to locate where people stop rather than to describe how they think.

---

Wireframe, mockup, prototype

Three different artefacts, each answering a different question, routinely used as if they were three levels of polish.

---

Jobs to be done

The framing that a customer is not buying a product but hiring it to make progress in a situation.

All forty-five termsWhat this is regulated by in the UAE

Is this one right in your own numbers?

The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.