Last updated 16 April 2026

Feature Request

Use this page when you are asking for a new capability, an enhancement to existing behaviour, or a meaningful change to a user journey or workflow.

Strong feature requests focus on the problem to solve and the outcome to achieve, not just the solution someone has in mind.

What to include

Start with the problem
  • What is not working well today?
  • Who is affected?
  • Why does this matter to the business, operations, or patient experience?
Describe the desired outcome
  • What should be possible after the change?
  • What would success look like for the requestor and end users?
  • Include acceptance criteria where possible.
Clarify scope and constraints
  • State what is in scope and what is not.
  • Call out deadlines, compliance needs, or operational constraints.
  • List dependencies on other teams, systems, or data.
Attach design or reference material
  • Link final Figma designs for UI work.
  • Include examples, mock-ups, existing workflows, or competitor references if useful.
  • Clarify states such as errors, validation, and empty states when relevant.

Suggested feature request format

Summary
Short description of the requested change.

Problem
What problem exists today and who it affects.

Outcome
What should improve after the change.

Scope
What is in scope, what is out, and any key rules.

Dependencies
Designs, data, approvals, cross-team inputs, or external systems.

Success criteria
How we will know the request has been met.

Supporting material
Figma, examples, links, screenshots, or notes.

Before submitting

  • Make sure the request describes the problem, not only a preferred solution
  • Attach final designs if the work changes UI
  • Flag unknowns early if stakeholder input is still needed
  • Split broad requests into smaller requests where possible

Related guidance: Request Readiness