The Constraint Is the Brief

Most workflow conversations start too clean. Someone describes the ideal path: the request comes in, the data is correct, the owner is obvious, the system updates, the report reflects reality. That version is useful for orientation, but it is rarely where the design work is.

The real brief is the constraint. The warehouse count happens before the day gets loud. The vendor answer arrives after the person who needs it has moved on to another fire. The dashboard depends on fields that people only fill out correctly when the form is easy enough to use under pressure. The system has to survive those conditions or it is mostly theater.

I like starting with the question: what makes the correct behavior hard? Sometimes the answer is time. Sometimes it is unclear ownership. Sometimes it is a tool that technically has the field but makes the field painful to maintain. Sometimes it is a handoff where the next person receives an outcome but not the context behind it.

Once the constraint is named, the work gets more honest. The fix might be a smaller form, a better exception list, a scheduled export, a clearer close condition, or a rule for when something gets escalated instead of interpreted. None of that is glamorous. That is usually a good sign. Useful operations work often looks obvious after it exists.

This is also why I do not trust automation as the first move. Automation is powerful when the constraint is movement, repetition, or visibility. It is weak when the constraint is judgment, ownership, or bad input. If the underlying behavior is unstable, automation mostly makes the instability faster and harder to argue with.

A better sequence is to respect the constraint first. Design for the actual morning, the actual handoff, the actual missing field, the actual person who has to use the thing while doing three other jobs. If the system works there, it has a chance everywhere else.