Case study 03 / Product & Systems Development

Broken Compass Platform

A feature is not finished when the code works. It is finished when the workflow works.

Broken Compass is active, pre-launch product and platform work in the FiveM multiplayer roleplay environment. The fire and hose system shows how Debra moves from intended behavior through requirements, implementation, testing, refinement, documentation, and operationalization without treating any one technical feature as the complete experience.

Environment
FiveM multiplayer roleplay platform
Status
Active / pre-launch
Contribution
Product and systems development leadership
Method
Workflow logic, AI-assisted implementation, testing, and refinement
Focus
Interconnected behavior, system state, feedback, and reasonable action
Evidence
Current product and Player Guide captures

Intended experience / 01

The intended outcome was not a hose animation. It was a workable response to an active incident.

Making firefighting work required treating the capability as an operational system. A person had to act through equipment, supply relationships, visible state, environmental conditions, and the incident itself.

  1. 01Person
  2. 02Equipment
  3. 03Apparatus
  4. 04Water source
  5. 05System state
  6. 06Environment
  7. 07Active incident

Requirements are relationships / 02

The requirement wasn’t “build a fire hose.” It was “make firefighting work.”

A hose spraying water could be technically functional while the surrounding workflow remained incomplete. The product requirement had to account for the relationships that make the capability understandable and usable.

Build the capability / 03

Product intent and technical behavior stay in the same loop.

Debra leads product and systems development across intended behavior, requirements, workflow logic, AI-assisted implementation, testing, refinement, documentation, and operationalization. Implementation is collaborative where appropriate.

  1. 01Define

    Describe what the person should be able to accomplish.

  2. 02Relate

    Identify the states, dependencies, and feedback the workflow needs.

  3. 03Implement

    Use direct and AI-assisted development within a collaborative implementation process.

  4. 04Exercise

    Test the behavior as part of the actual experience, then refine it.

Test against reality / 04

Technically functional is not the same as successful.

Isolated technical behavior does not establish that a complete workflow works. Testing has to include environmental conditions, system feedback, dependencies, and the reasonable actions a person needs to take while using the capability.

Technical check

Does the feature execute?

A necessary question, but not the final one.

Workflow check

Can the person accomplish the intended goal?

The system has to be judged through the behavior it makes possible in context.

Product judgment / 05

Preserve useful friction. Remove accidental friction.

Good systems do not remove every constraint. They preserve the friction that serves the experience and remove friction created accidentally by the implementation.

Useful friction

A constraint with a purpose.

Consequence, dependency, coordination, resource awareness, and operational decisions can make the experience more meaningful and understandable.

Accidental friction

An obstruction created by the implementation.

When system behavior prevents a reasonable action required by the intended workflow, the difficulty is not serving the experience. It is evidence that the system needs refinement.

Current product evidence / 06

The workflow becomes visible through its relationships.

These current product captures show different levels of the implemented fire and hose experience: the spatial arrangement of its parts, connected supply state, and active use during an interior incident.

Wide view of a Broken Compass fire scene showing a hydrant, fire engine, deployed hoses, and an active building fire.
Current product evidence / system relationship.A hydrant, apparatus, deployed hose runs, and an active fire scene are visible within the same operational context.
Broken Compass firefighter using a hose against a fire while the interface displays full water, connected supply, and air-supply state.
Current product evidence / connected state.Active hose use appears with visible water, connected-supply, and air-supply feedback.
Broken Compass firefighter suppressing an interior fire with water and air-supply states visible in the interface.
Current product evidence / active use.The implemented capability is shown operating during an interior fire with resource feedback visible in context.

Refine the requirements / 07

Reality makes the next requirement more precise.

Unexpected behavior is not merely a defect to dismiss. It is information about the gap between the intended experience and what the implementation currently makes possible.

  1. 01Intended behavior

    State what the workflow is supposed to enable.

  2. 02Observed behavior

    Exercise the capability in its actual context.

  3. 03Refined requirement

    Use the difference to clarify what the system must do next.

Operationalize / 08

Capability does not end with implementation.

People need enough structure, procedural guidance, constraints, and recovery information to use a capability successfully without unnecessary specialist dependency. The Player Guide demonstrates that broader Broken Compass product principle. The taxi guidance is a separate product example, not documentation for the fire workflow.

Capability beats dependency.

Broken Compass Player Guide home page showing primary categories, persistent sidebar navigation, and routes into detailed guidance.
Current product evidence / information architecture.The guide organizes foundational information, jobs, activities, and known issues into a persistent structure with routes into detailed guidance.
Broken Compass Player Guide taxi page showing normal-use instructions, a usage constraint, section navigation, and recovery guidance for a missed step.
Current product evidence / procedural and recovery guidance.A separate taxi example documents normal use, a contextual constraint, and the recovery path when a required step is missed.

What this demonstrates / 09

Build for the outcome, then keep testing the system around it.

The fire and hose system is the intervention. The underlying product problem is creating a complete workflow from interconnected technical behavior, system state, environmental conditions, and reasonable human action.

The transferable capability is defining the intended experience, translating it into requirements and implementation, testing what happens in reality, preserving purposeful constraints, refining accidental friction, and making the result usable beyond the person who built it.

All Work