Skip to main content

Org Workspace Collection UX

Why This Exists​

The current org pages prove the product model, but they do not yet express the intended day-to-day agency operating experience.

The main issue is not one page. It is the collection pattern across the org surface.

Today, projects, time, and billing mostly render as vertically stacked cards. That was acceptable for proving the schema and workflow spine, but it will break down once an agency has real volume.

Examples of the current gap:

  • project collections are too tall and do not support board-style planning
  • time entries behave like manual notes, not like a true running timer workflow
  • billing and other record-heavy pages do not yet share a stronger dense collection shell
  • quick actions are buried inside page-local buttons instead of staying available as workspace controls

This doc is the product-direction source of truth for the next org-surface UX step.

Non-Negotiable Outcome​

The org workspace must feel like a real operations product, not a stack of admin cards.

That means:

  • dense enough to handle dozens of records without becoming visually tall and exhausting
  • consistent between customers, projects, time, billing, and the global drive finder
  • flexible enough to support different collection modes per domain
  • fast to act from, with persistent creation and workflow shortcuts

Shared Collection System​

Every record-heavy org page should converge on the same collection shell.

Core parts:

  • page top bar for title and page-level actions
  • collection toolbar for search, segment filters, and view switching
  • density-aware record presentation instead of tall freeform cards
  • selection and bulk-action affordances where the workflow benefits from them
  • empty states that still preserve the surrounding shell
  • a persistent quick-action dock for high-frequency org actions

The styling should remain minimal and restrained, but it should look intentional and operational.

For now, the org sidebar should stay on this grouped structure:

  • Home: Overview, Analytics
  • Accounts: Clients, Portals
  • Work: Projects, Entries, Drive, Contracts
  • Revenue: Quotes, Invoices, Subscriptions

This keeps the primary navigation simple while still separating account management from delivery work.

A lighter alternative IA was explored and is intentionally parked for later evaluation:

  • Home: Overview, Analytics
  • Work: Clients, Portals, Projects, Entries, Drive, Contracts
  • Revenue: Quotes, Invoices, Subscriptions

That three-group version is still a valid future option if the org surface needs a lighter, flatter navigation again.

Explicit Collection Taxonomy​

Do not treat every org collection as the same kind of page.

The org workspace now has three collection types. New work should choose one of these deliberately instead of mixing patterns ad hoc.

1. Queue-switched record lists​

Use this when the page is still fundamentally a records table, but operators need a small number of durable workflow queues across the top.

Current examples:

  • time entries
  • billing/invoices
  • portals

Rules:

  • the secondary bar owns the fixed queue switch
  • the queue order is semantic and stable, not user-reorderable
  • search and heavier filters stay in the local collection toolbar
  • the content area is a dense list or table, not a board
  • drag-and-drop is not the interaction model

Examples:

  • entries: All approvals, Draft, Submitted, Approved
  • invoices: All invoices, Draft, Open, Past due, Paid
  • portals: All portals, Live, Unlinked, Disabled, Attention

2. Hybrid list/organize collections​

Use this when the same domain has two genuinely different jobs:

  • a dense review/browse job
  • an explicit move-between-states organizing job

Current example:

  • customers

Rules:

  • the secondary bar owns the mode switch, for example List and Organize
  • List is the default mode
  • List uses a dense table with scan-first columns and row actions
  • Organize uses visible state lanes and drag-and-drop
  • search may exist in both modes when it helps find records
  • filters that duplicate the board itself must not appear in organize mode

Example:

  • customers list: dense table with business name, primary contact, email, status, assigned summary, and actions
  • customers organize: Active, Paused, Inactive, Archived lanes with drag-and-drop

3. Pure record lists​

Use this when the page is a dense operational list without a meaningful board mode or queue switch.

Current examples:

  • billing/subscriptions
  • most detail-adjacent record collections

Rules:

  • the secondary bar is usually absent or reserved for page context, not list filtering
  • search, filters, sort, and bulk actions stay local to the collection toolbar
  • the content area uses dense rows, compact cards, or tables
  • drag-and-drop is not used

Drive-specific extension:

  • the org global drive route may add a client finder rail because retrieval across client workspaces is part of the job
  • that client rail does not make the page a hybrid list/organize collection
  • folder organization belongs primarily inside the client-specific drive tab, not the global finder

Guardrail:

  • do not add drag-and-drop just to make a page feel more interactive
  • only use drag-and-drop when moving items between visible states is itself the primary job

Collection Modes By Surface​

Projects​

Projects need multiple views, not one canonical tall list.

Required modes:

  • Board as the primary planning view
  • List as the dense operational view

Board expectations:

  • status columns such as planned, active, blocked, complete, archived
  • drag-and-drop between columns
  • compact project cards with only the fields needed for scanning
  • visible tags such as client, priority, target date, owner, visibility, and at-risk signals
  • archived work should not dominate the active board

List expectations:

  • dense row height
  • sortable columns
  • quick filters for active, blocked, complete, archived
  • visible tags instead of verbose body copy
  • rows should open detail quickly without needing tall card bodies

Time​

Time should stop behaving like a note-taking list and start behaving like time tracking software.

Time is not a hybrid list/organize collection. It is a queue-switched record list plus a timer utility route.

Timer expectations:

  • start, pause, resume, stop
  • active timer visible globally while working in the org surface
  • quick project and client assignment
  • running note field that does not require opening a full page dialog
  • timer state should be obvious, persistent, and hard to lose

Entries expectations:

  • secondary bar queue switch for All approvals, Draft, Submitted, Approved
  • dense list or table for review and correction
  • approval state, billable state, project, client, duration, and user shown clearly
  • manual entry still supported, but secondary to live timing
  • easy correction of recent entries without expanding large cards
  • approval changes should use fast inline controls, not drag-and-drop lanes

Timer route expectations:

  • lives as a utility route and shell-level utility affordance, not as a peer collection mode inside the entries workspace

Billing, Drive, Customers, Portals​

These should share the same collection shell, but not the same collection type.

Expected behavior:

  • dense rows or compact cards depending on the record type
  • active filters and status segments at the top
  • minimal repeated copy
  • important flags and next actions visible at scan speed

Specific direction:

  • invoices are queue-switched record lists
  • portals are queue-switched record lists for agency-side client portal operations
  • subscriptions are pure record lists
  • the org global drive route is a client-first finder with a client rail plus a dense recent-items table
  • customers are hybrid list/organize collections

These pages do not all need kanban, but they should still feel like they belong to the same workspace system.

Customers And Portals Ownership Rule​

The customer and portal surfaces must not drift into parallel identity models.

Canonical ownership is:

  • clientAccount is the company-level client record
  • clientContact is a person inside that company
  • portal access is state on that person

Surface responsibilities:

  • Customers/[clientId]/people is the canonical company people directory and access-management surface
  • Portals is the cross-client operations workspace that summarizes and filters the same underlying person-level portal access state
  • the portals workspace must not infer readiness from only the client-account toggle or only the primary contact email when person-level access data exists

Quick Action Dock​

The org surface should have a persistent quick-action dock in the bottom-right corner.

This is not decorative. It is a workspace control surface.

Initial actions should include:

  • new project
  • track time
  • new client
  • upload file
  • create invoice or open billing action when that workflow exists

Design rules:

  • desktop: floating vertical dock in the lower-right corner
  • mobile: convert to a more compact sticky action surface instead of covering content
  • keep labels concise and action-first
  • avoid turning this into a noisy speed-dial full of rarely used actions

Density Rules​

The current tall-card pattern should not remain the default for record-heavy pages.

Collection density rules:

  • prefer rows, tables, board cards, or compact tiles over full-height narrative cards
  • summary text should be optional metadata, not the main layout driver
  • archived or inactive records should move behind a segment, filter, or collapsed group
  • pages with dozens of records must still be scannable without feeling vertically punishing
  • if a page is a record list, default to a dense table first and require a workflow reason before introducing board mechanics

Package Direction​

If packages make this materially better, use them.

The likely direction is:

  • @dnd-kit/core and @dnd-kit/sortable for board and drag interactions
  • @tanstack/react-table if the current table primitives are too thin for dense collection views

The current internal DataTable wrapper is too primitive on its own for the intended end state. It can either be evolved around a stronger table engine or replaced by a better internal abstraction.

Implementation Order​

Do not redesign every list independently.

Implementation order:

  1. build the shared org collection shell
  2. build the org quick-action dock
  3. migrate projects first with board plus dense list
  4. migrate time second with real timer workflow plus dense entries view
  5. move billing, the global drive finder, and customers onto the same collection language

Guardrail​

Do not keep adding more route-specific list UIs on top of the current stacked-card pattern.

Do not blur collection types once chosen.

  • if a page is a queue-switched record list, do not smuggle organize-board behavior into the table
  • if a page is a hybrid list/organize collection, keep the two modes distinct instead of letting list filters fight the board
  • if a page is a pure record list, do not add a secondary bar queue switch unless there is a durable workflow slice that truly deserves it

Before further heavy org workspace expansion, collection UX needs to become a deliberate system.