Checks

The flow checks

Nine checks that read the shape of the flow: where each control goes, and whether every screen can be reached and left.

EC-101 A control with no destination

Tapping it does nothing, so the flow dead-ends mid-task. Wire it, or remove the control.

EC-107 Several dead controls on one screen

Most of what can be tapped goes nowhere, which reads as a broken screen rather than one loose end. Usually a screen that has not been wired yet.

EC-112 A screen you cannot reach

Nothing leads to it, so somebody walking the flow would never arrive there. Wire a control to it, or take it off the board.

EC-118 A failure with no screen

A control leads to a screen that is missing from the file, often an undesigned failure branch: the code that expired, the payment that was declined. Design the destination and rewire it.

EC-124 Ends here, no way onward

A final screen with nothing to tap leaves somebody with no way back into the app. Give it a way home or to the next task.

EC-131 No back, no close

No control on the screen leads anywhere else, so the flow would stop there. Add a back, a close or a way forward.

EC-140 A state nobody drew

The screen's kind owes a state that is not on the board. When a whole flow is missing the same state, it is said once, as a decision nobody has made yet.

EC-156 Can load, can never fail

There is a loading state but no failure beside it, so a request that fails leaves somebody on the spinner forever.

EC-163 Search with no empty result

A search or filter that matches nothing drops somebody on an unexplained blank list. Design the zero-result state with a way out.

Something missing or wrong here? Write to us