Once you know who you are building for, the next question is what they need to do. This post is about defining the behaviours, processes, and interactions that a user must perform inside the system.
The What anchors your feature set, drives acceptance criteria, and aligns everyone from business to backend on what success looks like. Get it wrong and you will get confusion, scope creep, and wasted engineering time. Get it right and you have a shared understanding of the system's purpose.
What you define here
- Functional requirements
- User actions and flows
- High-level system behaviours
- Business rules and constraints
Outcomes and actions, not features
A clear What is more than a feature list. It captures outcomes (what the user wants to achieve) and actions (what they must do to achieve it).
| Outcome | Action(s) |
|---|---|
| Submit timesheet | Log in, fill entries, submit |
| Approve timesheet | View timesheets, select, approve or reject |
| Request leave | Choose dates, add note, submit request |
Thinking in goals and behaviours keeps the team focused on usability and value, not system internals.
Benefits of a clear What
- A shared language between designers, developers, and stakeholders
- Less ambiguity in development and fewer rounds of back-and-forth
- A basis for test scenarios and acceptance criteria
- A way to prioritise based on user flow complexity and value
Techniques for capturing What
1. Use cases
Narrative descriptions of how users achieve goals with the system.
Use Case: Approve Timesheet
Actor: Project Manager
Trigger: Weekly timesheet review cycle
Steps:
1. Log in
2. View submitted timesheets
3. Open each timesheet
4. Review line items
5. Approve or reject
Outcome: Timesheet status updated
2. User stories
Short, structured statements that capture user intent.
As a [role], I want to [do something], so that [I achieve a goal].
Example:
As a consultant, I want to copy last week's timesheet so that I save time filling it in.
3. Behaviour-driven scenarios
Useful for aligning scenarios with tests.
Given a timesheet has been submitted,
When a manager clicks Approve,
Then the timesheet status should change to Approved and a notification is sent.
Visual tools
User flow diagrams show the paths users follow through the system. Hand-drawn, Mermaid, or any flowchart tool works. The point is visibility.
Submitting a timesheet:
Login -> Timesheets -> Select week -> Enter data -> Submit -> Confirmation
Worked example: leave request module
Who: employees and managers.
What:
- Submit a leave request
- Cancel a leave request
- View leave balance
- Approve or reject requests
- Download leave history
Mapped actions:
- Employee selects a date range
- Adds a note or category
- Presses submit
- System checks balance and conflicts
- Notification sent to manager
This clarity prevents the wrong thing being built. If you skip the What, you ship an "approve all" button when managers actually need to see the detail before approving.
The edge cases that matter most
A What that only describes the happy path is a What that will be rewritten in sprint three. Edge cases are where functional thinking earns its keep.
Three categories worth working through explicitly.
- State-based edges. What happens to a half-completed timesheet when the user is deactivated? Can a deleted project be referenced by a historical entry? Does a draft survive a browser refresh?
- Volume-based edges. What happens when a user has one leave request versus one hundred? The interaction model usually breaks long before the database does.
- Authority-based edges. Who can approve their own submission? What if the only available approver is the submitter? Can an acting manager approve retroactively?
Work these into acceptance criteria, not into a separate document. A story that says "employee can cancel a leave request" needs to include what happens if the request has already been approved, already been partially taken, or was submitted by a user who has since left.
Linking outcomes to measurable signals
A What worth its salt is testable. Each outcome should hint at how you will know it works in production, not just in QA.
| Outcome | Acceptance signal | Production signal |
|---|---|---|
| Submit timesheet | Form accepts valid entries | Weekly submission rate above 95% of active consultants |
| Approve timesheet | Approval status persists | Average time from submission to approval under 48 hours |
| Request leave | Request shows in manager queue | Rejection rate stays below historical baseline |
Those production signals are the bridge from the What to the Why. A feature can meet every acceptance criterion in staging and still fail in the wild. Writing the signal down early makes that failure visible before it becomes normal.
A longer worked example: the expense claim flow
It helps to take one flow and work through the What in full, including the ugly bits.
Outcome: a consultant submits an expense claim and is reimbursed without chasing anyone.
Actions:
- Open a new claim and select a project code.
- Add one or more line items, each with a category, amount, date, and optional note.
- Attach a receipt image or PDF per line item.
- Preview the claim with any policy flags applied (over limit, missing receipt, outside claim window).
- Submit for approval.
- Receive confirmation and a tracking reference.
- Get notified of approval, rejection, or a request for more information.
- See the claim appear in the next payroll export if approved in time.
Business rules:
- Claims older than ninety days are rejected automatically.
- Claims over a category-specific threshold require a second-level approver.
- A line item missing a receipt can be submitted but is auto-flagged.
- Currency conversion uses the rate on the receipt date, not the submission date.
Edges:
- Consultant attaches an unreadable receipt. System accepts the upload but flags it for approver review rather than blocking submission.
- Approver is on leave. A delegate is automatically nominated based on project hierarchy.
- Claim is submitted against a closed project. System rejects with a clear message and suggests the live replacement project.
Writing the What at this level of detail before any UI is sketched saves weeks of back-and-forth later. It is also the version of the spec that non-engineers can read and challenge, which is usually when the best revisions happen.
Common mistakes
- Writing solutions as requirements. Bad: "The system shall use a table view." Good: "The user must be able to view all leave requests for a given period."
- Skipping edge cases. What happens when the user has no balance? What if their manager is on leave too?
- Focusing on UI. Think actions and outcomes first. Screens come later.
- Mixing the What with the How. If your requirements document contains the word "Kafka", you have wandered into the wrong post.
- Writing the What once. Outcomes and actions evolve as the team learns. A static What is a stale What.
Summary
What is the user's experience translated into system behaviour. Done well, it gives teams confidence to move quickly without guessing. It is where ideas become stories, stories become tasks, and tasks become value.
