Desk is a standalone, enterprise grade product inside Plane that centralizes incoming requests from multiple sources. It works as a single tray for all intakes like email, forms, in-app, and external tools, allowing teams to triage, route, and resolve requests with clarity and accountability. Desk is not a feature added to projects. It will be a separate, paid product with its own workflow, roles, analytics, and pricing, built for organizations handling high volume, multi team support.
Industry
Project management
Client
Plane
My role
Product designer
Timeline
Apr - Aug'25
Problem & Context
As Plane’s customer base grew, especially with enterprise teams, requests started coming in from multiple channels including email, forms, in-app messages, and external tools like github, discord and even slack. Each channel created work in isolation.
Before Desk, things regularly broke.
Constant context switching across tools and projects
Missed tickets or requests stuck in the same state for days
No clear ownership once a request entered the system
Little visibility into where a request was or who was responsible
Project level Intake helped teams manage work inside individual projects, but it did not scale for organizations handling hundreds of requests across customers and teams. Enterprises needed a layer above projects, a place to see demand clearly before execution.
Desk was designed to be that layer.
Goals
Provide a single, reliable entry point for all incoming requests
Enable fast triage without forcing early commitment to a project
Make ownership, status, and next steps visible at all times
Scale to hundreds of tickets per day without chaos
Stay people‑driven first, automation‑ready later
Users & Roles
Primary users
Triage and support teams handling incoming requests daily
Secondary users
Desk admins managing routing and escalation
Project admins resolving routed work
Buyer persona
Founder or Operations Lead
Target audience
Enterprise teams with large customer bases and multiple internal projects
My Role
I was the first designer on Desk, partnering briefly with a lead designer before owning the product end to end.
Owned UX, interaction, and visual design
Translated PM PRD into clear workflows
Led rapid iterations with internal teams
Designed Desk as a standalone product
The first usable version shipped in one week, with the design evolving over six weeks of iteration.
Research & References
Research inputs came from multiple sources.
Internal support and ops workflows
Feedback from enterprise customers
Existing Plane Intake patterns
Competitive analysis of tools like Pylon, Zendesk, Zoho, Jira service management
The key insight was that enterprises do not think in projects when a request arrives. They think in requests, urgency, and accountability. Project assignment comes later.
Core Mental Model
Every request starts the same way.
New → Triage → Resolve or Execute
Desk treats all incoming items as requests first, not tasks. A request earns structure and ownership before it earns a place inside a project.
This mental model guided all interaction decisions.
Key Product Decisions
Board over inbox
Requests are shown on a state based board to make flow, aging, and bottlenecks visible at a glance. Lists tend to hide issues, while boards surface them clearly. Since most teams are already familiar with Kanban, a left to right board makes it easier to understand how a ticket progresses compared to an inbox or list view.Single entry state
All requests enter Desk in the same New state, regardless of source. This removes ambiguity and gives triagers a predictable starting point.Explicit project assignment
Routing to a project is always a deliberate action. This prevents silent misrouting and makes accountability clear.Global identity preserved
Desk items keep their identity even after being assigned to a project, ensuring traceability without forcing teams to change how they work.Manual first by design
Phase 1 avoided automation intentionally. With high volume, correctness mattered more than speed. Automation was designed as a follow up layer.State driven interactions
Actions are tied to states instead of generic controls. Details are progressively revealed, and triage is clearly separated from execution. This keeps cognitive load low even at high ticket volume.
Key Features
Centralized Desk Board
Single view of all incoming requests across sources
Clear states showing current ownership and progress
Filters for priority, assignee, customer, and aging
Triage & Ownership
Desk admins can comment, resolve, or route requests
Ownership is always visible
Requests never disappear into projects without traceability
Project Routing
Requests are assigned to the right project when ready
Project teams keep their existing accept or decline workflows
Status updates reflect back into Desk
Source Context
Each request retains its original source
Content and attachments remain visible during triage
Constraints & Trade‑offs
No automation in Phase 1 despite high volume expectations
Manual routing to ensure correctness and trust
Separate permission models between Desk and Projects
Limited cross‑tool sync to avoid partial or misleading states
These constraints helped keep the system understandable while laying the foundation for future scale.
Outcome & Early Signals
Desk is currently under development and not yet fully shipped, but early internal usage and simulations indicate strong potential impact.
Anticipated reduction of 25–35% in missed or stale tickets
Estimated 2–3 hours saved per support agent per week through reduced context switching
Faster first response due to a single, visible queue
Clear accountability leading to fewer tickets stuck in one state for long periods
These numbers are directional and based on internal workflows, early testing, and enterprise usage patterns.
Learnings
Centralization only works when ownership is explicit, and when visibility is prioritised over predictability
Products become usable through continuous iteration with users and product owners, while keeping business goals in focus
Strong products require taking opinionated decisions and being able to justify them clearly to stakeholders
Even during development, data played a key role in guiding decisions, especially when designing for scale and a wide range of users
Designing on top of existing tools requires restraint and respect for established workflows
Desk reinforced the importance of designing for flow and accountability, not just capture.
What I’d Explore Next
Rule‑based automation for routing and prioritization
Role‑based and group‑based flows as RBAC and GAC mature
SLA views and aging analytics
Customer‑facing, member‑only portals to track request status
These would help Desk scale from a strong operational foundation into a system that actively manages demand.
