SRS - Dashboard UX

For juniors especially, the dashboard must:

• Reduce cognitive overload
• Show structure immediately
• Encourage correct behavior
• Not look like a document editor

Let’s design it intentionally.

Dashboard Goals (v0.1)

When a user lands on a workspace dashboard, they should instantly understand:

1. What this workspace is
2. Where they are in the SRS
3. What to work on next
4. That this is structured engineering, not free writing

Mental Model

Think of it as:

“Project Control Panel for Requirements”

Not:

• Notion clone
• Google Docs
• Confluence

Layout Structure

Use a 3-column layout (desktop)

---------------------------------------------------------
Top Bar
---------------------------------------------------------
Left Sidebar | Main Content | Right Context Panel
---------------------------------------------------------

Responsive collapse on mobile.

Top Bar

Minimal but powerful.

Left

• Workspace name
• Small tag: [ISO 29148]

Center

• Global search (requirements, sections)

Right

• Create Requirement (Primary CTA)
• Export
• User avatar

Keep this very clean.

Left Sidebar — SRS Structure Navigator

This is your most important element.

Show:

1 Introduction
   1.1 Purpose
   1.2 Scope

2 Overall Description
   2.1 Product Perspective
   2.2 Product Functions

3 Specific Requirements
   3.1 Functional Requirements
   3.2 Non-Functional Requirements

Features:

• Indented based on code depth
• Active section highlighted
• Small badge: requirement count
• Drag to reorder (optional v0.1+)

This replaces scrolling in a giant doc.

Main Content Area

This changes depending on selection.

Default View (Workspace Overview)

When nothing selected:

A. Workspace Summary Card

Workspace Name
Description
Created date
Members

B. SRS Progress Overview

Show simple metrics:

Sections: 10
Requirements: 0
Approved: 0
Draft: 0

Even if empty — it signals structure.

C. Quick Actions

Cards:

• Add Requirement
• Edit Sections
• Add Diagram

Section View

When a section is clicked.

Header

3.1 Functional Requirements
[Add Requirement]

Optional small hint:

“Functional requirements describe system behaviors.”

Requirements List (Card-based, not table)

Each requirement:

REQ-001
User can reset password
[MUST] [DRAFT]

Below:

2 acceptance criteria

Clickable.

Why cards?

• Feels intentional
• Easier to scan
• Less spreadsheet-y

Requirement Detail View

When a requirement is clicked.

Layout:

Header:
REQ-001 | FUNCTIONAL | MUST | DRAFT

Statement
Rationale
Acceptance Criteria

Edit Button

This must feel structured, not like a paragraph editor.

Right Context Panel (Subtle but Powerful)

Dynamic content:

If section selected:

• Section description
• Requirement count
• ISO badge

If requirement selected:

• Metadata
• Created date
• Section link

If dashboard:

• Activity summary (future)

Visual Language (Important for Juniors)

Use visual cues:

Avoid:

• Big walls of text
• Too many buttons
• Modal overload

Optional Smart Addition (Low Effort)

Add a tiny progress bar:

Completion
[██████░░░░] 40%

Calculated as:

approved requirements / total requirements

Simple, motivating.

Navigation Flow

Dashboard
  → Click Section
      → Click Requirement
          → Edit

No deep nesting. No hidden screens.

Component Architecture (React/Next)

Clean separation:

<WorkspaceLayout>
  <Sidebar />
  <MainPanel />
  <ContextPanel />
</WorkspaceLayout>

Avoid monolithic page components.

State Strategy

Use:

• Server Components for data loading
• Client Components for interactive editing
• Avoid global state early
• Keep section ID in route:

/workspace/[id]?section=3.1

Subtle UX That Feels Professional

• When workspace created → auto-open “1.1 Purpose”
• Empty section shows:

No requirements yet.
Add your first requirement.

• Add Requirement button auto-generates next ID:

REQ-001
REQ-002

What NOT To Do

• Don’t start with a document editor
• Don’t show raw Mermaid blocks on dashboard
• Don’t overwhelm with metrics
• Don’t show versioning yet

Why This Layout Works

For juniors:

• Structure is visible
• Requirements are atomic
• Hierarchy is obvious
• No ambiguity about where to write

For seniors:

• Scannable
• Controlled
• Extendable
• Not toy-like