Pro Notion Workspace

A comprehensive skill for designing and organizing Notion workspaces — covering workspace architecture, team space structure, permission models, dashboard design, and workspace templates for personal productivity and team collaboration.

When to Use This Skill

Choose Pro Notion Workspace when you need to:

• Design a Notion workspace structure from scratch
• Organize a cluttered workspace into logical areas
• Set up team spaces with appropriate permissions
• Create dashboards that aggregate data across databases
• Build workspace templates for repeatable setups

Consider alternatives when:

• You need Notion database design specifically (use a Notion database skill)
• You need Notion API integration (use a Notion API skill)
• You need a different tool setup (use a tool-specific skill)

Quick Start

Copy
# Design a workspace structure
claude "Design a Notion workspace for a 15-person startup with engineering, product, and design teams. Include areas for projects, documentation, meetings, and team knowledge."

Copy
# Workspace Architecture: Startup (15 people)

## Top-Level Structure

### 🏠 Home
- Company dashboard (linked databases)
- Quick links to frequently used pages
- Team announcements

### 📋 Projects
- Active Projects (database, board view)
- Project templates (kickoff doc, retro, RFC)
- Archive (completed projects)

### 📝 Documentation
- Engineering Wiki
- Product Specs
- Design System
- Onboarding Guides
- API Reference

### 📅 Meetings
- Meeting Notes (database)
- 1:1 Notes (filtered by participants)
- Team Standup Archive
- Decision Log (database)

### 👥 Teams
- Engineering Space
  - Sprint board, tech debt tracker, on-call schedule
- Product Space
  - Roadmap, feature requests, user research
- Design Space
  - Design reviews, component library, assets

### 📊 Operations
- OKRs / Goals (database)
- Hiring Pipeline (database)
- Vendor Management
- Company Policies

## Database Connections
Projects ↔ Tasks (relation)
Projects ↔ Meeting Notes (relation)
Tasks ↔ Team Members (people property)
Meeting Notes ↔ Decision Log (relation)
OKRs ↔ Projects (relation)

Core Concepts

Workspace Architecture Patterns

Pattern	Structure	Best For
Functional	Organized by department	Large teams (20+)
Project-Based	Organized by project/product	Cross-functional teams
Hybrid	Top-level function + project sub-pages	Most startups
PARA	Projects, Areas, Resources, Archive	Personal productivity

Dashboard Design

Copy
## Company Dashboard Components

### Status Overview (Linked Database Views)
- Active Projects: Board view, grouped by status
- My Tasks: Table view, filtered to @me, sorted by due date
- Recent Decisions: Gallery view, last 30 days

### Key Metrics (Embedded)
- Sprint velocity chart
- OKR progress bars
- Open bugs count
- Hiring pipeline summary

### Quick Actions
- Create new project (template button)
- Start meeting notes (template button)
- Submit feature request (linked to form)

### Recent Activity
- Latest documentation updates
- Recent meeting decisions
- New team announcements

Permission Model

Copy
## Workspace Permissions

### Levels
| Level          | Can Do                        | Typical Role           |
|---------------|-------------------------------|------------------------|
| Full Access   | Edit everything               | Team leads, admins     |
| Can Edit      | Edit pages in their spaces    | Team members           |
| Can Comment   | View + comment only           | Stakeholders           |
| Can View      | Read-only access              | External partners      |

### Team Space Permissions
- Engineering: Full access to Engineering, view Product
- Product: Full access to Product, comment on Engineering
- Design: Full access to Design, edit in Product
- All: View access to Operations, edit Meetings

Configuration

Parameter	Description	Example
team_size	Number of workspace users	15
teams	Team names and sizes	["engineering", "product"]
architecture	Workspace organization pattern	"hybrid"
include_templates	Add page templates	true
include_dashboard	Create a central dashboard	true

Best Practices

1. Design the workspace top-down before creating pages — Map out the top-level structure on paper: what are the 5-7 main areas? What databases connect them? Creating pages ad hoc produces a workspace that mirrors your creation order, not your team's mental model.

2. Limit top-level sidebar items to 7 — More than 7 top-level items creates cognitive overload. Use nested pages for sub-areas. If your sidebar has 20 items, users waste time scanning for the right one.

3. Use one database with multiple views, not multiple databases — If you need to see tasks by status, by assignee, and by project, create three views of the same database. Three separate databases with overlapping data create sync nightmares.

4. Create an explicit onboarding page — New team members shouldn't need to figure out the workspace structure by exploration. Create a "Start Here" page that explains where things are, what databases are used for, and how to navigate the workspace.

5. Archive aggressively — Completed projects, old meeting notes, and expired policies clutter the workspace. Move them to dedicated archive sections monthly. Archived content is still searchable but doesn't pollute active navigation.

Common Issues

Workspace becomes a dumping ground for random pages — Without structure, team members create pages wherever is convenient. Establish a clear rule: every page must belong to a specific area. Orphan pages (not linked from anywhere) should be triaged weekly.

Multiple databases track the same thing — Two teams create separate task databases, leading to duplicate tracking. Centralize databases and use filtered views per team. One task database with team-specific views scales better than team-specific databases.

Permissions are too restrictive or too open — Over-restricting makes teams request access constantly (friction). Over-opening exposes sensitive data. Start with view-access for all shared spaces and full-access within team spaces. Adjust based on actual issues, not hypothetical concerns.