The workflow continues after the screen looks finished

A screen can be clear while the workflow around it remains difficult. Someone completes the form, sees a success message, and then has to copy the information into another system. A manager approves a request but cannot tell who is responsible for the next step. The interface has done what it was designed to do, yet the work is still waiting.

That gap is where I like to spend time during product discovery. I want to understand what starts the task, what makes it complete, and who depends on the result. The visible interaction is one part of that story. The surrounding handoffs often explain why the problem exists.

AI makes this distinction more useful. A generated summary can improve one moment while adding a new review burden somewhere else. Before calling that automation, I would want to see what happened to the whole task.

Follow the information through the work

At Spera, clients, projects, time tracking, invoices, and payments belonged to the same business experience. An independent professional could not treat each area as a separate destination. A project created work to record, work informed an invoice, and an invoice created a need to understand payment status.

As Director of Product Development, I worked across research, workflows, design, priorities, and delivery with the team. One lesson from that connected scope is that information gains meaning as it moves. A client name in a directory is useful, but its relationship to a project or an unpaid invoice is what supports the next decision.

When mapping a workflow, I would follow an ordinary piece of information rather than beginning with a list of features. Where does a job description originate? Who changes it? When does an estimate become a commitment? What happens if the customer asks for a revision? Those questions reveal dependencies that a page inventory can hide.

Look closely at the transitions

Transitions are places where people make judgments, wait for others, or correct incomplete information. They deserve specific attention because the software may not own the entire process.

Imagine a contractor turning an accepted estimate into a scheduled job. The estimate may contain the scope and price, but scheduling also depends on availability, materials, and customer access. A button that creates a job is useful only if it preserves the right information and makes the remaining decisions clear.

The Workhorse concept explored connected contractor workflows across estimating, scheduling, jobs, invoices, and communication. My contribution included product direction, scope, and sequencing with design and engineering. It remained a concept and prototype, so I do not treat it as evidence of a deployed operational result. It is a useful example of defining the relationship between steps before deciding which features belong in a first release.

That distinction changes a design review. Instead of asking whether the job screen has all the requested fields, I would ask whether the person can move from an estimate to a job without losing the agreement they already made.

Make ownership visible

A workflow often stalls because the next action is clear but the responsible person is not. Software can make this worse by displaying a status that sounds complete without showing the remaining responsibility.

Consider a hypothetical internal request marked reviewed. Does that mean someone has checked the information, approved the expense, or simply opened the record? Each interpretation could lead a different person to wait. A useful status should describe the operational state clearly enough that the next owner knows what to do.

I would define states with the people who perform the work. For each one, we should know how it begins, what information is required, who can change it, and what makes it end. This does not require turning every process into a complicated diagram. A short shared record can prevent an attractive interface from carrying an ambiguous promise.

The same thinking applies to automated steps. If a system classifies a request, someone still owns the decision about what follows. The product should make that responsibility explicit, particularly when the classification is uncertain.

Evaluate AI by the work it removes and creates

Suppose a team wants AI to draft a customer update from a job record. I would examine more than the time required to produce the first draft. Someone must check that the scope is current, confirm that the message is appropriate, and decide whether it is ready to send.

If reviewing the draft requires reconstructing the entire job history, the feature may have moved effort rather than removed it. A better experience might show the records used, identify missing information, and keep the draft beside the relevant details. That gives the reviewer a practical path to a decision.

There may also be a simpler improvement available. A consistent job status, a reusable message template, or a reliable notification could address much of the problem. I would compare those options before adding generated output. The point of discovery is to understand the constraint well enough to choose an appropriate response.

Include the exceptions people already manage

The ordinary path matters, but exceptions can explain the real cost of a workflow. A customer cancels after materials have been ordered. An invoice is disputed. A staff member is absent when an approval arrives. The product needs a way to represent what happened without forcing someone to invent an unofficial workaround.

I would ask about recent exceptions during research and then walk through them with the team. Where was the information recorded? Who knew the current state? Which steps had to be repeated? These questions are specific enough to reveal actual work rather than a general preference for better software.

An AI proposal should be tested against those exceptions too. If the system writes a confident update from an incomplete status, the interface needs a way to prevent that missing context from becoming a customer-facing claim. An exception path is part of the product, even when it is used less often.

Design the handoff as carefully as the task

A completed step should leave the next person with a usable result. That might be an approved record, a concise explanation, a printable reference, or an alert with enough context to act. The right form depends on where the work goes next.

GOV.UK's alpha-phase guidance includes considering the wider journey and the connection between online and offline channels. That is a useful reminder that product boundaries and user boundaries are not automatically the same.

For a hypothetical contractor workflow, a job-site handoff might need a compact summary that works on a phone. An office follow-up might need the detailed history. Both can come from the same record without forcing both people through the same interface.

Know what completion means

I would finish a workflow review by asking a simple question: what has changed for the person when this task is done? A saved form is a system event. An agreed schedule, an understood payment state, or a clear next responsibility is a user outcome.

That answer helps the team set boundaries and assess whether a release is useful. It also gives any future AI feature a meaningful job. The feature should support a real transition in the work, with an understandable input and an accountable result.

When the whole workflow is visible, individual screens become easier to judge. We can see which details support the task, which states need clarification, and where a handoff still depends on someone remembering what the system forgot to carry forward.