Let's Design the Work
The screen is not the work.
Teams often begin a project by asking what the product should look like. It is an understandable question, but it arrives too early. The interface is only the visible edge of a larger operating system: people interpreting information, making decisions, negotiating constraints, and recovering when something goes wrong.
When we start with screens, we quietly encode our assumptions about that system. A field becomes required because the mockup needs it. A workflow becomes linear because the prototype is easier to explain that way. Soon the representation is driving the reality instead of helping us understand it.
The first design material is not the interface. It is the work itself.
Treat the operation as the product.
A dependable capability has several layers, and they must be designed together.
The work layer explains how something moves from request to trustworthy completion. The decision layer explains who judges what, with which evidence, and under whose authority. The system layer holds the objects, states, information, permissions, and handoffs that make those decisions possible.
The interface matters, but its job is to make this structure usable and legible. It should reveal the state of the work, support judgment, and make the next responsible action clear. That is a much stronger brief than simply making a process digital.
Work
Follow the real path from request through completion, including delays, detours, and recovery.
Decision
Make evidence, authority, judgment, and escalation explicit.
System
Define the objects, states, rules, and relationships the operation depends on.
Move from evidence to capability.
Good design work progresses through a sequence. First, frame the real work through research and operational evidence. Then architect the system that can support it. Prove the proposed capability under real conditions. Finally, enable the organization to operate and improve it without permanent dependence on the original project team.
This sequence keeps technology in its proper role. AI, automation, and interfaces become deliberate interventions inside a coherent system—not impressive objects searching for a use case.
What would change if you designed the work first?
The next time a project begins with a request for a dashboard, chatbot, portal, or workflow, pause before drawing. Ask what capability the organization is actually trying to create. Ask how the work happens now, where judgment lives, what people are protecting, and how failure is repaired.
Those answers will not make the interface less important. They will give it something coherent to express.
Design the work, then give it an interface.
The next field note continues the BFL framework from evidence to lasting capability.