Work / Selected systems

Different environments. Same underlying work.

Systems change. The recurring work is to understand the goal, see where reality diverges from the intended experience, and change the appropriate part of the system.

Professional work

The environment changes.
The work transfers.

01 / Litigation Technology & Information Architecture

The capability existed. The usable information system didn’t.

Patterson Buchanan Fobes & Leitch

View case study

Use existing capability

Situation
A litigation technology platform held the needed capability, but legacy records remained difficult to recognize, compare, and retrieve.
Friction
Source identifiers and incomplete contextual metadata preserved provenance, but did not tell people what a record was without opening it.
What changed
Debra developed a repeatable information-architecture method using metadata, retrieval structure, naming, and documentation. Records became more recognizable and findable while source identity remained intact within the existing platform.
What this demonstrates
A new tool is not always the answer. Sometimes the work is building the system that lets people use existing capability effectively.

Completely fictional illustrative example

Before / opaque identifiers

  • ABCXYZ_1234
  • ABCXYZ_4321
  • ABCXYZ_2413

After / recognizable information

  • 2010-01-24 - ABC v XYZ - Complaint
  • 2010-01-24 - ABC v XYZ - Amended Complaint
  • Letter - Smith - Doe - ABC v XYZ - Statement of Representation - 2010-01-24
All names, identifiers, dates, case information, and document examples are completely fictional and created solely to illustrate the information transformation. Any similarity to an actual person, matter, document, or record is purely coincidental. This does not reproduce confidential Patterson Buchanan or Everlaw data.

02 / Platform & Operations

Recurring support demand was a systems signal.

TheCrew Platform

View case study

Build organizational capability

Situation
People with varied technical experience had to move from approval through setup, connection, participation, and ongoing support.
Friction
Recurring setup and connection problems consumed support capacity and kept users dependent on other people to participate.
What changed
Debra combined observation, onboarding, self-service and recovery paths, knowledge, support operations, governance, and distributed leadership. The resulting launcher checked prerequisites, supported installation and recovery, and became a persistent information hub. Connection-related tickets disappeared.
What this demonstrates
Repeated questions and support demand can reveal a system problem, not a series of isolated user problems.
Historical TheCrew launcher home screen showing patch notes, server population and status, play access, community content, and supporting links.
Original historical evidence / launcher and information hub. A surviving launcher artifact brings connection access, service status, patch notes, community content, and supporting resources into one surface.

03 / Product & Systems Development

Build the complete workflow, not just the feature.

Broken Compass Platform

View case study

Build the capability itself

Situation
Broken Compass is a live multiplayer roleplay platform built in the FiveM environment. Features need to behave believably and remain maintainable within larger product and operational workflows.
Friction
A technically functional feature can still be wrong, confusing, brittle, or expensive to operate when dependencies and edge cases are left outside its scope.
What changed
Debra defines requirements and workflows, uses AI-assisted development alongside direct implementation, tests and refines behavior, and builds the administration, documentation, and governance needed around the capability.
What this demonstrates
Defining the experience and directly building it can remain one continuous act of systems work, including recovery paths, operators, and the people using it.
Broken Compass firefighter using a connected hose to suppress an interior fire, with water and air-supply states visible in the interface.
Current product evidence / implemented workflow. The fire and hose capability is shown in active use with connected water-supply state, resource feedback, and the surrounding multiplayer environment visible.

04 / Product Design & Workflow Design

Sometimes you just need a ride. Sometimes that's how a story starts.

Rydi / Broken Compass RP

View case study

Create an encounter without requiring one

Situation
Broken Compass benefits from spontaneous encounters between players. One person needing transportation could give another person a natural reason to show up.
Friction
The social opportunity couldn't make transportation depend on another player's availability. And ‘request a ride’ turned out to hide a lot of decisions about what happens between asking for one and actually getting somewhere.
What changed
Rydi connects riders with available player drivers first. If nobody accepts within 60 seconds, the existing city taxi takes over without asking the rider to understand the handoff.
What this demonstrates
Designing the workflow meant deciding what people needed at each moment, which signals the system could trust, and what should happen when reality didn't follow the happy path.
Rydi home screen inside the in-game phone, showing ride request and driver availability controls.
Rydi v1 · Home. Player drivers get the opportunity first. The city taxi remains the dependable fallback.

Knowledge management / Information architecture

Broken Compass Knowledge.

05 / Knowledge Management & Information Architecture

Authorization before retrieval.

Broken Compass Knowledge

View case study

Make knowledge trustworthy and maintainable

Situation
Documentation was scattered across player guides, architecture, operations, historical material, and several file formats.
Friction
Putting it into another wiki would have centralized the files without answering who could find them, trust them, or maintain them.
What changed
The system uses existing Discord roles to decide which knowledge a person can browse, search, and retrieve. A Document Manager lets authorized contributors maintain the canonical source.
What this demonstrates
Scattered documentation exposed a larger problem of identity, authorization, governance, and retrieval.
Public Broken Compass Knowledge home with only public categories visible.
Production system / Public view. The knowledge universe begins with what this visitor is authorized to see.

Product design / Systems thinking / Learning experience

Contextual Onboarding & First Arrival.

06 / Product Design & User Enablement

Teach the system through real actions.

Broken Compass RP · Shipped October 1, 2026

View case study

Build familiarity, then return agency

Situation
Early player questions showed that people needed to learn Broken Compass's interaction grammar while using it.
Friction
A controls manual required players to know what they didn't know before they could search for it.
What changed
I designed a guided first-player experience around real purchases, navigation, shopping, and garage storage. Runtime testing changed the routing architecture, removed unnecessary integration complexity, and surfaced a separate property lifecycle defect that was repaired at the source.
What this demonstrates
Follow user friction to the right layer, revise assumptions against actual behavior, and stop guiding when the player can choose their next action.
First Arrival's small apartment prompt and orange walking breadcrumbs alongside the normal Broken Compass streetscape.
Shipped experience / Direction within the world.By the walk home, guidance supports independent movement rather than replacing the environment with another interface.