A study session should not start with an incomplete exam

A learner asks to start a full exam. The system has loaded only part of the question set. The Start button is still active.

That was the product failure: the interface allowed a learner to begin before the data needed for the full session was ready. A warning on the page did not make the action safe. The button needed to reflect whether the exam could actually proceed as promised.

The bug was in the decision, not the warning

The exam flow expected 180 questions. In one captured response, only part of that set had arrived. The exact reason for the partial response has not been established, and the missing source rows were not repaired by the interface change.

The immediate issue was narrower: the UI still enabled Start. The learner could interpret that as confirmation that the complete exam was ready.

I changed the readiness rule so a partial response keeps Start disabled and gives the flow a retry path. A complete response can enable the action. The screen now links the message and the available action to the same state.

Test the failure state and the recovery state

For a loading problem, testing only the successful path misses the point. The important checks were both sides of the boundary:

• With an incomplete response, Start stays disabled.
• With a complete response, the exam can proceed.
• The learner has a clear way to retry rather than being left at a dead end.

A synthetic check against the production build confirmed the first two behaviors. That gives evidence that the interface guard works for the tested responses. It does not establish why the original data was incomplete, repair the source, or show that no other partial-data path exists.

The operator still needs a data repair path

UI safeguards protect a user from an unsafe action. They do not replace source-data monitoring. The complete system needs a way for an operator to see that expected data is missing, investigate the source, and verify the repair without asking the learner to discover the problem first.

This is a useful pattern beyond exams. A booking system should not confirm a slot before checking availability. A payment flow should not show success before receiving the needed confirmation. An inventory action should not promise stock based on a partial read.

The rule is simple: important actions should be gated by the data they depend on, and the system should say what can happen next.

Make readiness observable

When a system depends on a complete set of records, define completeness explicitly. What is expected? What counts as ready? What does the user see when the answer is no? What can the operator inspect? Which step can be retried safely?

Those questions are often more valuable than adding another loading animation. Animation can show that time is passing. It cannot tell a learner or operator whether the result is complete.

In any product I build, I want the interface to block the misleading action, the operator to see the underlying issue, and the repair to be checked against the original failure. If your business has a workflow that can look ready while important data is still missing, tell me where it happens.