Planning your digital project with Ulties

The brief: retrieve an approved service report

Purpose: let a customer contact retrieve a service report for equipment covered by their current access permission. Today, in this fictional business, the coordinator checks the request and sends the approved report through the existing authorised channel. The proposed portal must preserve that permission check. Reducing coordinator work is the desired outcome, not a measured saving.

First production release, if approved: sign in through the agreed identity service, list reports the current contact may access, and retrieve an approved report. An unavailable report needs a clear explanation and a route to the coordinator. Uploading reports, changing equipment details and paying invoices are outside this release. The existing process remains available while the portal is investigated.

Candidate input: a public synthetic report called SAMPLE-SERVICE-REPORT and invented customer and equipment identifiers. Discovery uses no customer documents or live credentials. The source system is only assumed to expose report approval and customer access relationships; whether it actually does is the principal open question.

Proposed acceptance: the permitted contact can retrieve the intended approved report, an unrelated contact cannot retrieve it by changing an identifier, and a removed contact cannot make a new authorised retrieval. Also check direct document access rather than testing only the list screen. These are required future demonstrations, not tests that this article claims have passed. A previously downloaded copy cannot be recalled by changing portal permissions.

Give each unknown an owner and a consequence

Mia is the fictional client’s operations lead and owns business acceptance. Lee is its systems administrator and owns evidence from the source system and identity service. Rene is the proposed technical lead for this hypothetical project and owns the prototype and technical release recommendation. These names assign responsibility inside the example; they do not identify Ulties staff or commit anyone to support.

Access decision: Lee must show how a signed-in contact maps to current customer permissions and approved reports, including how removal becomes visible. Mia confirms whether a contact may represent several customers. If that evidence is unavailable, Rene records the gap and does not substitute a browser-supplied customer identifier for a permission rule. Production delivery stays on hold.

Operating decision: Mia must choose who handles denied or unavailable reports, and Lee must confirm that the existing authorised request channel remains staffed. If that fallback is unavailable, the proposed first release is incomplete. It cannot present “contact support” as recovery when nobody owns the request.

Commercial decision: the client’s purchasing owner and Ulties must agree the contracting company, budget currency, payment terms, source ownership and ongoing services in a proposal. This brief sets none of those terms. A missing commercial agreement is a reason to withhold the relevant commitment, not permission to fill the gap with an assumed policy.

Choose a discovery deliverable before a build commitment

I recommend approving a bounded discovery milestone here rather than a fixed production build. Its deliverable is a reviewed access map and a disposable prototype using synthetic records. Lee supplies the relevant interface documentation and permitted test access through the agreed secure channel. Rene records the assumptions the prototype replaces and the ones it cannot test.

OWASP distinguishes signing in from permission to access a resource. Its authorization guidance recommends denying access by default and checking permission on every request. For this brief, that supports inspecting both the report list and retrieval boundary. It does not establish that the proposed identity service or document store enforces either rule.

The rejected alternative is building polished portal screens against assumed access data. Those screens could be completed while the necessary relationship is absent from the source system. I recommend resolving that uncertainty first because it can change the data model and the release scope. The cost is delaying production UI work, and discovery can conclude that the portal should not proceed.

The next review happens when Lee has supplied the access evidence and Rene can demonstrate the proposed cases with synthetic records. Mia checks whether the permitted result matches the business rule. If the evidence is missing or a forbidden request exposes report contents, the decision is revise or stop, not “ready for production.” Passing this milestone would support estimating the next stage, not certify a deployed system.

Make the review understandable to the buyer

Mia needs to see which report a permitted contact receives and what an unrelated contact can observe. An empty list alone is inadequate evidence if the document URL remains accessible. Rene should explain failures in terms of the rule they violate and retain the reproduction steps. The demonstration must distinguish a proposed case from an executed result.

W3C’s accessibility planning guidance includes assigned responsibilities and evaluation throughout delivery. I recommend agreeing the relevant devices and assistive-technology review before production acceptance, with an owner for the resulting fixes. A security prototype cannot stand in for a complete accessibility evaluation.

W3C’s form guidance calls for clear submission results and errors that explain how to recover. If the portal includes a request form, its message must match what is known about that request. Recording a request does not establish that a coordinator has read it. This brief does not add a form silently; Mia must decide whether the existing request channel is sufficient.

Close the discussion with a decision record

The completed planning decision is to proceed with synthetic discovery, defer the production portal commitment, and retain the existing authorised report-request process. Mia owns business acceptance, Lee owns the source evidence, and Rene owns the prototype findings. Customer uploads and billing remain excluded. The access map and demonstration are the next review milestone.

I recommend attaching a short decision record to the brief after that review: what changed, which evidence justified it and who approved the next commitment. If the source system cannot express current permissions, compare changing that source with retaining a manual service. Do not promise a launch date on the assumption that either alternative is already approved.

Before production launch, a separate agreement must name the operating owner, incident contact and recovery procedure, including restoration of the previous authorised channel if the portal is withdrawn. Support hours and retention rules need actual business decisions. This example supplies no uptime, security, response-time or cost guarantee. Bring the unresolved items to the discussion explicitly rather than treating a finished-looking brief as a finished project.