Work with real constraints

01 / Learn

The idea

Professional practice involves more than finding the ideal interaction. You must understand what the system can know, who can change it, the release window, and the cost of failure. Separate a minimum safe change from later improvements. State which risks need an operational answer rather than a new component.

A useful proposal includes the user's goal, evidence, alternatives, dependencies, a decision owner, and what will be checked after release. Do not call a locally queued renewal complete when the central account has not accepted it. If a staff-assisted path is proposed, verify that staff can see the relevant state and have capacity to help.

02 / See the reasoning

Worked example

Fictional scenario

A public library's self-service renewal kiosk sometimes loses network access during busy hours.

An expert learns that the kiosk cannot synchronously confirm renewals during an outage. They recommend a clearly labeled pending receipt and a way to check status later, while operations defines an exception path for due items. A later release could add reliable sync acknowledgment. They assign ownership for the queued-record service and for visitor communication.

03 / Decide

Guided decision

The team can change kiosk copy this week, but reliable server acknowledgment needs another release. What do you recommend now?

04 / Apply elsewhere

Independent application

Fictional scenario

An enterprise expense app queues manager approvals during an outage; payroll closes that evening.

Write a staged recommendation for the current release and the next release. Identify the manager, employee, finance operator, decision owner, and evidence needed to accept the risk.

Make: A one-page staged decision memo with constraints, dependencies, owners, and release checks.

05 / Keep working

Sources and related patterns

• Nielsen Norman Group: Service Design 101 ↗

Apply this skill: Design decision memo and state model →