Skip to main content

saas-workspace-design

Use when the task is to design a SaaS product UI, B2B web app, 工作台, product workspace, settings-heavy application, or multi-pane web tool. Focus on workflow clarity, navigation depth, density balance, state design, and operational efficiency.

Jump to install

Source facts

Repository
Mr-Q526/TeamCC-Platform
Last source activity
April 15, 2026 at 03:16
Detected SKILL.md language
English
Stars
8
Forks
1

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
4 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
schemaVersion
2026-04-11T00:00:00.000Z
skillId
frontend/saas-workspace-design
name
saas-workspace-design
displayName
SaaS Workspace Design
description
Use when the task is to design a SaaS product UI, B2B web app, 工作台, product workspace, settings-heavy application, or multi-pane web tool. Focus on workflow clarity, navigation depth, density balance, state design, and operational efficiency.
aliases
["saas-workspace-design","SaaS Workspace Design","saasworkspacedesign","SaaS","工作台","B2B 产品","workspace","Saa"]
version
0.1.0
sourceHash
sha256:fe3a4f785faa1a51d2bcbb6802ac01374ab57229cf151cfa111e8bff2f855775
domain
frontend
departmentTags
["frontend-platform"]
sceneTags
["design"]
# SaaS Workspace Design Use this skill for productized web applications where users spend time doing work, not just reading marketing content. Goal: reduce chrome, clarify workflow, and make high-frequency actions feel fast. Optimize for repeat use, navigation memory, and state predictability. ## Workspace model Design around these layers: 1. Navigation: workspace switcher, section nav, contextual tabs 2. Primary surface: the object, canvas, table, timeline, or editor 3. Secondary context: inspector, activity, comments, details, or docs 4. Action layer: create, save, publish, assign, or share ## Core rules - Start from the main job to be done, not from a dashboard card grid. - Use persistent navigation for repeated workflows. - Distinguish global navigation from page-level tabs and from inline controls. - Prefer layout-based grouping over nested cards. - Use one accent color for key actions and states; let typography and spacing do the rest. - Dense is acceptable when scan order stays obvious. ## State design - Show draft, saved, syncing, error, and published states clearly. - If collaboration exists, expose presence, ownership, and recent change context. - Empty states should suggest the first meaningful action, not generic welcome copy. - Long-running actions need progress, cancel, or background execution cues. ## Settings and forms - Group settings by mental model, not backend schema. - Keep destructive or billing-sensitive controls separated from routine toggles. - Use inline helper text when the consequence is not obvious. - For advanced settings, default to progressive disclosure. ## Interaction - Keyboard shortcuts, quick search, and command surfaces matter for expert workflows. - Drawers and panels should preserve context rather than force hard page switches. - Use motion to reinforce structure: panel reveal, tab transition, save feedback. ## Reject these failures - Marketing copy pasted into product headers - Equal visual weight for every module - Sidebars full of unclear icons - Multiple sticky bars fighting for attention - Settings pages that mirror raw JSON or API names ## Final checks - Can a repeat user build navigation memory after one session? - Is the main work surface obviously more important than chrome? - Are key system states visible without requiring refresh or guesswork?
View on GitHub