📅January 15, 2024
⏱️4 min read
👤Rhys Morgan

6Ws: What – The Outcomes and Actions

Define the behaviors, processes, and interactions that users need to perform within your system. Learn how to create clear functional requirements and user flows that align your entire team.

🏷️Requirements🏷️User Flows🏷️Functional Design🏷️Planning
6Ws: What – The Outcomes and Actions

What – The Outcomes and Actions

Why “What” Comes Second

Once we know who we’re building for, the next logical question is: what do they need to do? This chapter focuses on defining the behaviours, processes, and interactions that a user must perform within your system. This “What” anchors your feature set, forms the basis for acceptance criteria, and aligns everyone from business to backend on what success looks like.

Getting this wrong leads to confusion, scope creep, and wasted engineering time. Getting it right creates a clear, 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


The Role of Outcomes and Actions

Defining “What” is more than listing features. It is about capturing 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 terms of goals and behaviours keeps the focus on usability and business value rather than system internals.


Benefits of a Clear “What”

  • Shared language between designers, developers, and stakeholders

  • Prevents ambiguity in development, reducing back-and-forth

  • Drives test scenarios and acceptance criteria

  • Enables prioritisation through understanding user flow complexity and value


Techniques for Capturing “What”

1. Use Cases

Narrative descriptions of how users achieve goals with the system.

Template:

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.

Template:

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 Development (BDD)

Useful for aligning scenarios with tests.

Template:

Given [a context],
When [an action occurs],
Then [the system should do X].

Example:

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 to complete tasks. Can be hand-drawn, built with flowchart tools, or created using Mermaid.js.

Example Flow (Submitting a Timesheet):

User logs in → Navigates to Timesheets → Selects Week → Enters Data → Submits → Confirmation Page

Real-World Example: Leave Request System

Let’s say we are building a simple leave request module.

Who: Employees and Managers

What:

  • Submit Leave Request

  • Cancel Leave Request

  • View Leave Balance

  • Approve/Reject Requests

  • Download Leave History

Mapped Actions:

  • Employee selects date range

  • Adds note or category

  • Presses submit

  • System checks for conflicts and balance

  • Notification sent to manager

This clarity prevents misalignment like building an “approve all” button when managers actually need to see detailed logs first.


Common Mistakes

  • Writing solutions as requirements

    • ❌ “The system shall use a table view.”

    • ✅ “The user must be able to view all leave requests for a given period.”

  • Skipping edge cases

    • What happens if the user has no balance?

    • What if their manager is on leave too?

  • Focusing only on the UI

    • Think in actions and outcomes, not just screens.

Summary

“What” is the user’s experience translated into system behaviour. When well-documented, it gives teams the confidence to move quickly without guessing at intent. It's where ideas become stories, stories become tasks, and tasks become value. Never skip the “What”, it's the working engine of the 6W model.

  • Clarifies scope early

  • Supports user story creation

  • Foundation for test plans

EAS

Rhys Morgan

Enterprise Automation Services specializes in AI, automation, SaaS development, and digital transformation. We help businesses across the UK leverage technology to drive growth and efficiency.

Related Articles

Continue exploring our insights and expertise

6Ws: When – The Timeline and Delivery
📅February 12, 2024
⏱️4 min read

6Ws: When – The Timeline and Delivery

Create realistic timelines and delivery schedules for your software project. Learn how to balance scope, resources, and deadlines to ensure successful project delivery.

Read More

Ready to Transform Your Business?

Let's discuss how our expertise in AI, automation, and digital transformation can help your business grow.