Sonarist / Design system

Documentation v1.0.0 · Work in progress · UI prototype with separate server foundations

Design system contents

Overview

Sonarist design system

A practical reference for a multi-product helpdesk: reusable interfaces, conversation workflows, native themes, implementation contracts, and source-based examples.

On this page

Foundations10 entries Components36 entries Patterns17 entries Applied screens13 entries Accessibility4 entries Implementation7 entries

Product and audience

Sonarist gives a small team one place to handle support, sales, and general conversations across several companies and products. Its central decision is not simply which message arrived last, but which conversation needs attention, who owns it, and what should happen next.

This reference is for designers defining behavior, engineers composing the existing React components, and teams evaluating the product work. It documents the current app retrospectively; it is not a claim that an organization previously adopted a published component library.

System scope

System scope
Area	Included	Boundary
Foundations	Source typography, Tailwind palette, geometry, responsive layout and theme behavior	Semantic role names here are documentation mappings, not a pre-existing source token API.
Components	Primitives, menus, recipient fields, messages, people, team and settings families	Internal helpers are documented as parts of their exported parent.
Patterns	Sender triage, reply, assignment, follow-up, reference, recovery and configuration	UI state is not authenticated server persistence.
Evidence	Actual source components with fictional data in light/dark desktop/phone captures	Provider setup, delivery, billing and authorization are not certified by screenshots.

Design principles

Make the reason for opening a queue visible through labels, counts, and waiting age.
Keep customer identity, ownership, work type, and product scope separate.
Keep the latest message readable while retaining earlier thread context.
Let people prepare and review a reply before an explicit send action.
Use the same visual families across inbox work and account configuration.

Current implementation

HelpdeskApp imports mock-data and holds conversations and people in React state. Several settings editors close with a local toast without updating the source array. A separate server foundation includes database, email, domain, storage and billing modules; the infrastructure notes explicitly defer tenant-facing persistence until trusted authentication exists.

All capture records are fictional. The source owner name is substituted with Morgan Ellis and addresses are changed to example.com inside a disposable copy. AI, draft status, attachments, domain verification and billing indicators remain prototype demonstrations.

Start here

Start here
Need	Topic
Compose an interface	Components: actions, fields, recipient controls and dialogs
Understand the inbox	Foundations: conversation model; Patterns: triage and reply
Assess real delivery	Implementation: readiness and integration boundaries
Inspect exact visuals	Applied screens and full-resolution example viewer
Reproduce evidence	Implementation: screenshot capture and fixtures

Source references

Source references
File	Responsibility
components/helpdesk-app.tsx	State and route orchestration
lib/types.ts	Product records and state unions
helpdesk-notes/Infrastructure Architecture.md	Explicit frontend and backend boundaries

Examples from the app

Actual Sonarist components with fictional conversations, people, example.com addresses and simulated operational states. Captured at 2× resolution or higher. Select an image to inspect it full size.