Service design matters more when software gets cheaper

The cost of implementing software has fallen. The need to think carefully about the service has not. We can build a form, connect a provider or automate a workflow much faster than we could before. Deciding what to ask of someone, what to remember about them and what should happen when something goes wrong still takes judgment.

Cheap implementation makes it easier to accept every request. Another eligibility check. Another dashboard. Another field collected just in case. Each may take little time to build while adding years of work for the people who use and operate the service. Service design has to account for that cost before the requirement becomes software.

Decide what the service is for

Start with the outcome for the person using it. Then examine every proposed step against that outcome. What problem does it solve? Who does the work? Who might give up? What new information would we become responsible for keeping safe?

In a public-health program we helped build, people could request no-cost naloxone by mail. The early idea was a detailed questionnaire that would guide them through the request. A wizard is a familiar answer to a collection of requirements: ask the questions in a manageable order, then move the person to the next screen.

We applied a simpler principle: begin with what the person needs, then ask what the service actually requires to provide it. The purpose was to get naloxone to someone who wanted it. The useful question became where they wanted the package sent. That changed the design more than making the questionnaire easier to complete would have done.

A single intake questionnaire can look convenient from inside a program: gather everything upfront and distribute it later. But delivery, reporting and learning did not all need the same information. Delivery needed a mailing address. Reporting could use aggregate information. Questions that might help the program learn could belong in an optional, anonymous survey, separate from the request. During a later fulfilment rehearsal, we also removed email collection and kept questions about overdose experience out of the order form.

Privacy was central to the service. Someone seeking a public-health resource should not have to supply a personal history simply because the program might find it interesting. The resulting request requires no account or identity check. The address still needs to be usable and within the delivery area; collecting what the delivery needs does not require tying every subsequent report or survey to that person.

The simpler arrangement also serves the operators better. There are fewer fields to validate, less sensitive information to protect, and a clearer distinction between a delivery problem and a research question. The working surface can show what needs to happen to a request and where someone needs to intervene. Reducing what we ask of the recipient removes work from the operation as well.

The service still extends beyond the website. A request has to reach the people fulfilling it, become a package and find its recipient. Someone needs to handle an uncertain address or an interrupted transaction. We designed that whole journey together: a request moves through clear states, routine steps happen reliably, and operators can see the exceptions that need their judgment.

Omission needs a reason, just as inclusion does. An eligibility rule may be necessary without requiring someone to upload identification. Repeated requests may need attention without justifying a permanent record of everyone who has used the service. A useful control addresses a specific risk with a proportionate burden. The possibility of misuse alone is a poor specification.

Speed belongs to the product

Time to delivery changes the value of a service. While a team debates another requirement or builds another control, people continue with whatever inadequate alternative exists. The time spent waiting belongs in the product decision alongside cost, reliability and scope.

What people know while they wait matters too. Someone who knows their request arrived and understands what happens next is in a different position from someone wondering whether to start again. A service might reassure them with a clear confirmation or a way to ask for help. That reassurance depends on the operation behind it: someone needs to be able to find a stalled request, explain what happened and help resolve it.

Thoughtful service design should help a team move sooner. Agree on the essential journey, the information it requires, the exceptions people must handle and what would make it safe to open. Rehearse that complete journey with the operators. Questions become concrete: can an accepted request get lost, can a mistake be corrected, can someone take over tomorrow?

That rehearsal is useful friction. It gives the people operating the service a chance to understand what happens, find a problem and practice resolving it. The point is what they learn and change, rather than the existence of a completed readiness document.

When implementation becomes faster, those decisions can be tested earlier. That is an opportunity to shorten the distance between an unmet need and a working service. Filling the saved time with extra features gives away that advantage.

Put reliability into the structure

A simple experience needs dependable machinery behind it. A request should have a known state, a defined set of possible next steps and clear conditions for moving between them. This is what a state machine makes explicit. Gates prevent actions whose prerequisites have not been met; failures leave a recoverable state; people can see where their judgment is needed.

The service we built carries those decisions through fulfilment. An uncertain address pauses for review. An interrupted postage purchase must be reconciled before another purchase is allowed. Automated tests exercise the full transaction and deliberately interrupt it at failure points, checking which actions remain safe. Progress survives interruptions without an operator having to reconstruct it from memory.

This is a service-design decision as much as an engineering one. If reliability depends on someone copying the right cell into a spreadsheet, remembering a special case or checking three places before acting, the person is carrying rules the system could enforce. Encode the repeatable rules and give people a clear place to resolve the exceptions. That makes the work simpler to run and easier to hand over.

Design the point at which the work ends

Collecting information creates a future obligation. A delivery address may be necessary today and unnecessary once the delivery and its support window are complete. Retention and deletion need their own conditions, automated work and checks. A promise in a privacy policy does not perform the deletion.

The same discipline applies to a tracker, a questionnaire or an approval step. Decide why it belongs, what it costs the person encountering it and when its job is done. Sometimes the most useful design decision is to leave it out. Faster software delivery makes that judgment more valuable: we can put a smaller, dependable service into people’s hands sooner, and keep improving it from what the work teaches us.

The broader question is which friction earns its place. A simple request for the recipient and attentive work by the operator can belong to the same thoughtfully designed service.