Building software alongside the people who use it

Software has to fit the work people actually do. A process diagram may show a clean sequence while the people following it check a spreadsheet, repair an identifier, or ask a colleague before taking the next step.

Working alongside users helps an engineer understand those missing parts. It also makes it easier to test whether a proposed change helps. This is often called forward-deployed engineering: bringing product and engineering decisions close to the people and conditions the software must serve.

The useful result is a better product and a clearer understanding of the work. Getting there requires judgement about which local details belong in the software and which need a different response.

Follow one complete task

Start with a real unit of work: an order, a request, a report or a decision. Ask someone to show how they complete it, including the steps outside the main application.

Watch what information they look for and what they already know. An experienced operator may spot a suspicious value immediately without being able to describe a rule in advance. A familiar screen may be useful because it puts two facts beside one another, even if nobody mentioned that comparison in the requirements.

Ask questions at the point where something happens. What made that record worth checking? Where did this value come from? What would make you stop? What tells you the task is finished?

Use approved examples and minimise copied data. A controlled walkthrough or redacted record may answer the question without access to a live account. Discovery should not create an unnecessary copy of the organisation's records.

Separate the rule from the workaround

A procedure might require a field before an order can proceed. The application may allow the field to remain empty. Staff may enter a placeholder because the real value arrives later.

Each tells you something different:

• The procedure describes what is supposed to happen.
• The application determines what is possible.
• The workaround shows how people manage the current constraints.

The new design needs a reasoned response to all three. Perhaps the field should become mandatory later in the process. Perhaps the placeholder hides a genuine control failure. Copying the workaround into a feature would settle that question too quickly.

Record the observation and your interpretation separately. Review the proposed change with the people responsible for the task. One conversation can reveal a problem, but it does not establish how often it occurs or whether everyone needs the same solution.

Investigate beyond the interface

An apparent interface problem can begin upstream. A report may disagree with another system because the systems count different objects, update at different times, or use different units. Rearranging the screen will not resolve that disagreement.

Trace a questionable value back to its source. Check how it was entered, transformed and matched. Establish which system is responsible for it and what should happen when sources disagree. Preserve enough context to explain a correction rather than silently replacing the evidence.

As a constructed example, suppose two systems both use “location”. One means a physical site; the other means a route through which an order arrives. Joining those fields by name could produce a plausible but misleading report. The repair begins by separating their meanings and making the mapping explicit.

When different systems mean different things develops that modelling problem. The same habit applies to dates, currencies, units and account identifiers: check what a value means before automating its movement.

Decide where an exception belongs

Close contact with users produces requests quickly. Each request still needs a product decision.

Some reveal a missing capability that belongs in the shared product. Others are legitimate variations that configuration can represent. A provider-specific requirement may belong in an integration. A temporary source-data problem may need repair without changing the product model.

Discuss the trade-off openly. Adding a feature can save one person time while creating new states that everyone must understand and the team must maintain. Conversely, repeatedly handling a common need as a special case can conceal a missing general capability.

Before generalising, ask whether the concept makes sense beyond the immediate example, whether there is evidence that the need recurs, and whether another engineer could explain and support the result. When the evidence is thin, keep the change small and revisit it as more is learned.

Put a useful change back in front of people

Choose a small change with a clear completion test. Use it to check both the implementation and your understanding of the task.

A release can pass technical checks and still make work harder. Ask the user to complete the task again. Observe where they pause, what they verify elsewhere, and whether the new screen supplies the information they need. Include an awkward but legitimate case as well as the ordinary path.

For integrated software, test delayed data, failed requests and partial completion. A person should be able to tell whether a change was saved, is still pending, or needs attention. They should not have to infer that state from a reassuring message.

Keep normal testing and release controls in place. Working closely with a client makes feedback faster; it does not make an untested production change safer. UX is part of the system considers how feedback, interruption and recovery affect the complete task.

Leave the understanding with the team

Record the decisions that another person would need to maintain the software: important data meanings, why a rule exists, how an integration can fail, and which questions remain open. Keep this close to the code and operating guidance it explains.

Support can remain with the original engineer or move to another team. Either arrangement needs enough shared knowledge to release changes and diagnose problems without relying on one person's memory.

The practical test is whether close work with users changes the product for the better. A clearer model, a useful comparison, or a reliable handoff may matter more than a large new feature. Follow the work closely enough to discover which change is needed, then check it in use.