Aaron Benjamin

The Design Dash / Open-source planning method

From a fuzzy problem
to a plan people can use.

Evidence and object definitions need to survive the journey from problem framing to wireframes and technical requirements.

I designed an open process that connects the reasoning to the artifacts and keeps unanswered questions visible.

Illustrative tool library, a member borrowing a drill, and a borrowing interface.
AI-generated illustration · fictional tool-library example
My contribution
Process designer and author; method, Object Library, linked records, and environment adapters
Audience
Designers, builders, and facilitators planning product work
Current stage
Public method; SONAR solo run and Renaissance workshops; broader adoption unmeasured

A finished screen can hide
an unfinished idea.

When product reasoning stays in scattered notes and conversations, a polished screen can conceal unresolved assumptions. I designed The Design Dash to connect evidence, a shared product model, and interface decisions in a plan another person can inspect.

The evidence changed
what the product could promise.

I used Design Dash in a solo run for Aegis, the predictive attention tool that became SONAR. The planned product would analyze a screenshot or rendered page and help designers inspect where a model predicted attention would gather.

Evidence review challenged the original framing about predicting the opening seconds of viewing. I narrowed the sequence label to “predicted early viewing order” and replaced a center-bias toggle with a viewing-prior selector that exposed the model’s assumptions. Those became product constraints before implementation.

Target selection gave the visualization a concrete job: a designer could select the element they wanted people to notice and inspect its diagnostics in relation to the page. I compared a Lab Report, an Inspector Canvas, and a compact Verdict Card, then selected the Inspector Canvas to keep the screenshot, selectable elements, and diagnostics together. A verdict header and export path carried forward from the other concepts.

Aegis → SONAR · a traceable decision

  1. Evidence review

    Narrow the prediction language and expose the viewing prior.

  2. Concept decision

    Choose Inspector Canvas; retain a verdict header and export route.

  3. Dependency check

    Validate the engine before hardening more interface work.

  4. Later implementation

    Scoped language, viewing-prior controls, and target selection appear in the app.

Recorded SONAR project narrative · October 2026

The Dash produced the plan and wireframes. The scoped prediction language, viewing-prior controls, and target selection carried into the later app; designer and product-manager testing remained the next step.

Define the things.
Then design their behavior.

I used Object-Oriented UX and ORCA (Objects, Relationships, Calls-to-action, and Attributes) as the modeling foundation. Object Guides collect attributes, actions, relationships, lifecycle, and business rules in a shared Object Library.

In a fictional tool library, Tool identifies the item, Member the borrower, and Loan their connection. A Tool’s availability follows its Loan state. Defining that relationship first gives navigation, interface controls, and technical requirements one rule to reference.

Inspect the example Object Guides
Illustrative Object Guides for Tool, Member, and Loan, including attributes, actions, relationships, and loan lifecycle.
AI-generated Object Guides · fictional tool-library example

Reuse without silently rewriting the past

A Dash references a shared guide until it needs a different definition, then forks it locally. Reviewed learning can return to the library. That adds record-keeping, but avoids making a local product decision silently change earlier work.

Carry one decision
through the whole plan.

I connected the artifacts through an editable Dash Model rather than treating the final presentation as the source. Linked Markdown records keep the work portable. The Design Plan and release Story are views of those records.

A richer document or database could centralize editing, but would make that environment a requirement. Markdown reduces that dependency; the cost is that links and required information need validation to prevent drift.

One availability rule, four connected artifacts

  1. Requirement

    Show whether a tool can be borrowed.

  2. Object Guide

    One checked-out Loan per Tool, linked to its Member.

  3. Wireframe

    Offer the action appropriate to the Loan state.

  4. Technical check

    Recheck availability when checkout is confirmed.

Fictional Tool/Loan example
Inspect the two interface states

Same Tool, different state

Available · Cordless drill

No checked-out Loan exists. Offer “Request to borrow.”

On loan · due Friday

A checked-out Loan links Tool and Member. Offer “View loan details.”

Fictional interface states

The handoff records assumptions, alternatives, edge states, requirements, accessibility considerations, and a validation plan alongside the artifact links.

Explore phases, environments, and review tiers

Nine phases connect opportunity framing and object modeling to flows, alternatives, wireframes, and validation planning. I separated environment adapters from the method so the same review gates work in a general AI chat, a file-capable agent, or a facilitated workshop. A coded prototype is optional.

Review effort follows risk, reversibility, and reach. Express work keeps the ethics floor; consequential workflows require deeper evidence and accountable review.

Review follows the consequences

Express

Small and reversible. Keep the ethics floor and record deferred evidence work.

Standard

Review evidence, alternatives, user understanding, ethics, and learning.

High-stakes

Retain required gates, with privacy and compliance review where applicable.

The process records unresolved questions instead of treating a completed checklist as validation.

Current status

A public method.
Applied to real product work.

The published method connects evidence, object definitions, interface states, requirements, and validation planning. I used it in the SONAR solo run and facilitated Renaissance product and engineering workshops that produced shared assignment notes, diagrams, wireframes, and a low-fidelity prototype the team tested.

Explore the method on GitHub.

Next, I’ll ask someone other than the author to run a Dash and have a collaborator use the resulting plan. Can they trace a decision, identify uncertainty, and determine what to build without reconstructing the conversations?

What I took forward

Make the reasoning accessible alongside the artifacts. A complete plan is a better starting point for learning, not a substitute for it.