Planning your digital project with Ulties
Prepare a brief that defines the first useful release, tests uncertain integrations, and assigns ownership for launch, recovery, and maintenance.
Bring a decision, not just a feature list
A useful starting brief explains who needs help, what they are trying to do, and what currently prevents it. For an enquiry website, that might mean helping a buyer select the right service and giving the sales team enough context to respond. For a portal, it might mean letting an existing customer retrieve a document without contacting support.
When preparing a project with Ulties, use the following structure to make those decisions reviewable. It is a proposed planning method, not a claim about a past engagement or a promise of a fixed delivery process. The purpose is to agree on a useful first release and expose the assumptions that could change its scope.
Define the first complete journey
A first release should complete an end-to-end task even if it serves a narrow audience. A finished homepage with a nonfunctional form is not a complete enquiry journey. Trace the path from entry to confirmed outcome, including what the operator does after the visitor leaves.
Separate essential behavior from later improvements. Search, account creation, multiple languages, and CRM automation may each be valuable, but they need a reason to be in the first release. Record exclusions explicitly so a design review does not quietly reintroduce deferred scope.
The sample below describes a fictional enquiry workflow. It is a brief to discuss, not executable configuration or a statement of current Ulties service terms.
outcome: visitor-can-request-a-relevant-scope-discussion
primary_user: buyer-comparing-technical-services
first_release:
- clear-service-scope
- accessible-enquiry-form
- durable-server-side-acceptance
- operator-visible-delivery-status
excluded:
- customer-accounts
- automated-price-quotes
unknowns:
- crm-test-environment-availability
- approved-content-owner
acceptance:
- valid-request-is-stored-once
- invalid-request-shows-correctable-errors
- delivery-failure-is-visible-to-operator
- confirmation-matches-actual-acceptance
owners:
business_acceptance: to-be-assigned
technical_release: to-be-assigned
ongoing_support: to-be-assigned
Investigate the uncertainty that can change the plan
Rank unknowns by the cost of being wrong. If the CRM cannot accept the required fields or has no safe test environment, discover that before building a polished integration screen. Request documentation, a synthetic example payload, and a named integration owner. Do not put credentials or customer records in the brief.
A technical spike should answer one question and leave evidence: whether a test record can be accepted, how failures are reported, and what retry behavior is safe. Time-box it and record what remains unknown. A successful happy-path request is not a complete integration assessment.
Map data across the boundary. Identify where a submission is stored, what identifier prevents duplicates, who can view it, and when it is removed. Choose a minimal payload for each recipient. These decisions affect both implementation and operating procedures, so they belong before the final estimate.
Turn quality into acceptance criteria
Replace “fast,” “accessible,” and “easy to use” with named journeys and checks. Specify the devices and network conditions used for review, the input and error cases, and the person who accepts the result. Agree measurable performance targets after inspecting the expected content and infrastructure rather than inventing them in a proposal.
Include accessibility throughout the work. W3C’s planning guidance treats it as an ongoing responsibility, with assigned tasks and repeated evaluation. Review content, interaction, and implementation together; an automated scan alone cannot demonstrate that someone can complete the intended task.
Plan the day after launch
Name the release owner, the recovery procedure, and the person who monitors failed enquiries or unavailable pages. Define what support covers and how future dependency updates are handled. If the original developer is unavailable, another maintainer should be able to find the source, build instructions, configuration requirements, and operational contacts without searching a chat history.
Finish planning with an agreed scope, open questions, decision owners, and the next demonstrable milestone. When new information arrives, update that agreement and explain the effect on cost or schedule. A useful plan remains short enough to consult while being specific enough to prevent different people from building different projects.