Work Areas — User Flow Wireframe

v1: template-based work areas, predefined and non-customizable for first release. Read top to bottom as one continuous walkthrough — every state is shown in the full app shell, and the yellow connectors tell you what was clicked to get there. [Red brackets] = unknown / decision pending; see Open decisions at the bottom. Nothing fabricated.

0The model in one picture

3–4 predefined templates · admin picks one

Company

everybody
no picker

Project

repos only
≤ [N]

Team

people only
≤ [N]

each template = icon + title + list of dashboards it exposes + scope rules

➞becomes a
work area

A work area

the Dev Lead’s Team

Scope — repos or people or everything, never mixed

Access — you’re a member or an admin, nothing finer

Dashboards — on/off from the template’s list, shared by all members

➞members see
only its tabs

What a member sees

Tokens

[Sprint]

dashboards

the template’s dashboard list is the permission model — costs/ROI stay in templates given to the right people

1Land & navigate

You sign in → you land in your last work area, on its first enabled dashboard

Work areas 1

⊕ New work area ADMIN 2

All Company ★

the Dev Lead’s Team ★

atlas ☆

☰ Browse all · [12] 8

the Dev Lead’s Team TEAM · [n] people 5

Onboarding ✕

Token Spend

[Sprint view]

+ Add ▾ 4

KPI

dashboard content — out of scope here 7

4 "+ Add" menu · opens from the tab bar

6 User menu · opens from the avatar, top right

7 Empty work area · replaces the dashboard body

No data in this work area yet.
Scope: [0 people] · coverage: none
Add people → (admin only)

1Left nav = your favorited work areas only — one section, not Favorites + All. First-run rule: everything you’re granted is auto-favorited up to [N], so a new user’s nav is never empty and un-starring is the curation gesture. No dashboards or reports ever appear in the nav.

2"New work area" — system admins only, starts the create flow (step 3). Creating is deliberately separate from browsing.

3Dashboards switch as tabs inside the work area (HubSpot / Jira pattern) — scales to ~25 per area.

4"+ Add" opens the menu at right: toggle dashboards from the template’s list; the tab set is shared by everyone in the area.

5 opens this work area’s settings over the page (step 4). Admins only; members don’t see it.

6The global header owns scope-independent chrome only: search, Ask AI, and the avatar (menu at right — profile, org and system-admin settings). The page title does not live here; identity belongs to the work-area band below, so the current scope is always unambiguous.

7If the area has no scope or no data yet, the dashboard body is replaced by the explicit empty state at right — never a silent fallback to company-wide numbers.

8"Browse all · [12]" opens the finder (step 2) — for finding and favoriting, never creating. The count signals there’s more than what’s pinned, giving discoverability without a second nav section.

clicks ☰ Browse all… in the nav↓

2Find & favorite — the finder opens over wherever you are

Work areas

⊕ New work area ADMIN

All Company ★

the Dev Lead’s Team ★

atlas ☆

☰ Browse all…

the Dev Lead’s TeamTEAM

Onboarding

Token Spend

[Sprint view]

+ Add ▾

All work areas ✕

Find a work area…

All Company Project Team

1	Work area	Scope	Your role
★	All Company	everything	member	Open
★	the Dev Lead’s Team	[n] people	admin	Open
☆	atlas	[n] repos	member	Open 2

1Stars toggle favorites in place — this dialog is favorites management; starring puts the area in your left nav.

2"Open" switches you into that work area. The list shows only areas you’ve been granted. Finding only — creating lives in the nav as its own admin-only entry.

system admin clicks ⊕ New work area in the nav↓

3Create — admin picks a template, names it, hands it off

3a · Choose a template

Work areas

⊕ New work area ADMIN

All Company

the Dev Lead’s Team

atlas

☰ Browse all…

T Trent

3b · Name it & assign an admin — that’s all

Work areas

⊕ New work area ADMIN

All Company

the Dev Lead’s Team

atlas

☰ Browse all…

T Trent

1No scope picking here — the work area is created empty. The assigned admin, who actually knows the team, adds people from inside it (step 4).

2The template chosen in 3a already fixed everything else: which dashboards exist, what kind of scope, and the size limit.

Create → the new area opens, empty — admin clicks to add scope↓

4Configure — settings take over the page, X drops you back

Settings takeover · Scope tab — the new empty area being filled in

Work areas

⊕ New work area ADMIN

All Company ★

the Dev Lead’s Team ★

atlas ☆

Platform Team ★

☰ Browse all…

Platform Team — settings✕ 1

Scope 2

Access

Dashboards

Add a person or user group…

[user group] ✕ [person] ✕ [person] ✕

[n] of [N — template limit] people · "add" disables at the cap 3

Same takeover · Access tab

Scope

Access

Dashboards

Who	Role
Harper	Admin ▾
[person / user group]	Member ▾

two roles, nothing finer 4

Same takeover · Dashboards tab

Scope

Access

Dashboards

same list as the "+ Add" tab menu — two doors, one setting 5

1Full takeover with a big X — you configure the area without leaving it, then X drops you back on the tab you were on.

2The picker matches the template: Team = people / user groups, Project = repos, Company = no Scope tab at all.

3Template size limit is enforced live in the picker, not as an error after saving. Scope edits re-scope all history instantly.

4Access = who can look; Scope = whose work is counted. Different lists — a team’s data can be visible to people outside it.

5Dashboards toggle whole-on / whole-off from the template’s list, shared by every member of the area.

separately: what a brand-new deployment sees on day one↓

5Day one — default company area, onboarding is the first dashboard

Work areas

⊕ New work area ADMIN

All Company ★ 1

☰ Browse all…

All CompanyCOMPANY

Onboarding ✕ 2

Engineering Health 4

+ Add ▾

Getting set up — live view

✓ Repository connected · [repo]

✓ First tracker installed · live activity seen [t] ago

◯ Invite your team · [n] of [n] developers reporting

◯ [remaining steps — onboarding scope owned separately]

Onboarding complete — hide this dashboard? Hide · Keep 3

1The first user (SaaS or on-prem) lands in a ready-made All Company area covering everything — it grows automatically as repos are added.

2Onboarding is the default first dashboard: a live "data is flowing" view. It’s a standard tab with an ✕ — nothing special to learn.

3When onboarding completes, the app offers to hide it; it can be re-added any time from "+ Add."

4Other tabs on day one show an honest "no data yet + coverage" state — never fabricated numbers, never a silent fallback.

Not in v1

Custom / editable templates · composite work areas (areas built from other areas) · widget-level dashboard granularity · scheduled reports (interval sends) · public/private custom dashboards · per-user tab sets · nuanced creation permissions · data-readiness gating. All explicitly deferred at the 6/8 sync.

Open decisions — every red bracket traces to one of these

Default template set. "Team / Project / Company" vs "+ Department" — 3 or 4 templates. Blocks screen 3a and the seed data. Owner: the CEO/a Senior Engineer.
Who creates work areas in v1 SaaS. "Anyone with portal access" vs "system admin creates empty areas and hands them off." Wireframe draws the stricter model; confirm before build.
Numeric scope limits per template. "10 repos / 25 developers" were illustrative only; real numbers needed per template.
Which dashboards each template exposes. Depends on the report-publishing work item from release week.
Onboarding dashboard contents. Owned by a Senior Engineer + another engineer; the checklist in step 5 is placeholder.
Sensitive-data granularity. Is "the right dashboards in the right templates" enough to keep developer names out of org-level views, or does v1 need a fixed granularity per template?
Data readiness. When do non-onboarding dashboards become worth showing? Deferred at the sync; honest-empty states are the stopgap.