Work Areas
A one-hour alignment meeting on how the product should organize engineering work, turned into a buildable v1 spec: five numbered flow steps, every state drawn in the full app shell, and every unresolved question drawn as a red bracket instead of a guess.
- User-flow format
- Jun 8 intake meeting
- PDF circulation copy
Origin
A work-areas sync on June 8, 2026 with the CEO, the Dev Lead, a Senior Engineer, and several other engineers locked a deliberately simplified v1: template-based work areas (Company / Project / Team), predefined and non-customizable for the first release; access gated at the work-area level rather than a granular permissions model; and a hard separation between reports (sent on an interval) and dashboards (live, in-app), two ideas the team had been conflating. A short high-level-takeaways digest came first (objectives and agreed decisions only, explicitly not detail), then the wireframe, as the thing the team could actually argue with.
Why this one has no review layer
Everywhere else in this practice, a wireframe is an artifact for critique: tag pills, a toggleable review layer, an audit trail. This stream had nothing built to review. It was the output of a decision meeting, drawn so the decisions could be checked. So the annotation layer was deliberately dropped, and its slot was taken by two things that do the same job for a spec: numbered callouts explaining why each element is shaped the way it is, and connectors between steps saying what was clicked to get from one state to the next. The honesty device survives: red brackets mark unknowns, each tracing to a numbered entry in an Open Decisions list.
Four decisions worth pointing at
The dashboard list is the permission model. Rather than per-widget or per-role permissions in v1, each template carries a fixed list of dashboards, and membership in a work area is the whole access story. Sensitive material stays away from the wrong audiences by putting the right dashboards in the right templates. The spec then immediately questions, in Open Decisions, whether that granularity is actually sufficient.
One nav section, not "Favorites + All." The left nav shows favorited work areas only. Everything you're granted is auto-favorited up to a cap, so a new user's nav is never empty and un-starring becomes the curation gesture. Browsing opens a finder that is for finding and favoriting, never for creating. Creation is a separate, admin-only entry, so discovery and creation never get confused.
Create empty, then hand off. The create flow picks a template and a name, with no scope-picking at creation. The area is created empty, and the work-area admin, the person who actually knows the team, adds people from inside it. The spec also separates two ideas most tools blur: access is who can look; scope is whose work is counted.
Honest empty states over silent fallbacks.An area with no scope or no data shows an explicit empty state with scope and coverage, never a quiet fallback to company-wide numbers. Onboarding ships as the default first dashboard, a live "data is flowing" view that is a normal, closable tab.
The template's dashboard list is the permission model: a new user's nav is never empty, and un-starring is the curation gesture.
The artifact
A single self-contained HTML document, exported to PDF for circulation: a scrolling spec that reads start-to-finish in a meeting or attaches to a thread, with no one needing to run anything.