Context
At Plane, I worked across the product and the public website from September 2023 to May 2025, designing for everyday teams, technical administrators, and people evaluating the product for the first time.
My contribution
Designed Active Cycles, webhooks, onboarding, notifications, admin controls, board interactions, and the marketing-site revamp. Partnered with product and engineering to align the interface with technical constraints.
The work crossed feature design, developer setup, self-hosted administration, and marketing. That range meant finding a coherent interaction language while respecting very different user goals.
The design choices
- 01
Make cycle health visible without making the dashboard dense or hard to scan
- 02
Use progressive disclosure and clear fallbacks for technical setup
- 03
Treat empty states, signup, and notifications as part of the product experience
- 04
Build a more coherent marketing path between open-source interest and product evaluation
Work across the product
The original Plane case study documents these feature areas. The problems, design responses, and impact descriptions below preserve its substance while identifying where results were not quantified.
Active Cycles
Problem
A workspace could run several cycles across projects. Teams needed to spot progress, bottlenecks, and overdue work in one place without a dashboard that demanded interpretation.
Design response
- Brought completed and pending issues, burndown, and status distribution into a scannable view.
- Made blocked or overdue work easier to notice and gave missing data a useful empty state.
Outcome
A single view for cycle health and more proactive issue resolution; it does not give a feature-specific measured result.
Webhooks
Problem
Event-driven automation required technical configuration, but setup had to remain understandable to teams with different levels of API experience.
Design response
- Organized event selection, callback URLs, authentication, and configuration management into a guided setup.
Outcome
The design aimed to make integrations more self-serve and support developer and enterprise adoption. No support-volume metric is published for this feature.
Empty states and upgrades
Problem
A blank product surface gave new users little sense of what a feature was for or what to do first. Free-plan limits also needed an honest path to understanding paid value.
Design response
- I used empty states to explain features and guide new users to their first action and framed upgrade moments around the capabilities gained, with a clear next step.
Outcome
Clearer first-use moments and a better free-to-paid experience, without publishing conversion figures.
Signup for cloud and self-hosted teams
Problem
Casual cloud users needed a quick path in, while self-hosted teams needed domain and authentication controls. One journey to serve both
Design response
- Designed email changes, optional product tours, and workspace creation as part of the end-to-end flow.
Outcome
Reduced friction and a more consistent onboarding foundation. It does not publish signup-completion data.
Email notifications
Problem
Teams needed important updates without notification fatigue or a maze of settings.
Design response
- Grouped preferences by event and offered instant, digest, and off states.
Outcome
Fewer complaints about overload and more meaningful engagement; counts were not published.
Instance administration
Problem
IT and operations teams needed to configure a self-hosted Plane instance without depending on documentation or developer support for every setting.
Design response
- Grouped authentication, sign-up rules, integrations, library management, and workspace controls.
- Used progressive disclosure, validation, and fail-safe states for advanced or consequential settings.
Outcome
The design supported a more self-serve admin experience and enterprise readiness. The original case study does not quantify support reduction.
Swimlanes and drag-and-drop
Problem
Large Kanban boards needed ways to group work and reprioritize it without losing orientation or dropping an issue in the wrong place.
Design response
- Explored modular swimlanes by assignee, priority, and module.
- Refined drop zones and feedback when moving issues between lanes or modules with engineering.
Outcome
The original case study describes more navigable boards and clearer drag feedback. It does not provide a measured error rate.
Cross-project linking
Problem
Related work can live in different projects, but a reference is only useful when the other issue's status and access permissions remain clear.
Design response
- Prototyped issue search, linked status and owner context, and a visual distinction between local and external issues.
- Included a fallback for issues a person could not access.
Outcome
This was an early concept in the original case study, not a shipped feature or product outcome.
Website revamp
Problem
The previous public site did not clearly express the product's maturity, open-source position, or route different visitors toward evaluation.
Design response
- Redesigned the homepage, pricing, feature overview, and navigation system.
- I revised the visual hierarchy and worked on responsive layouts and performance.
Outcome
The current portfolio reports a 10× increase in marketing traffic and engagement after the redesign; this case study does not present the underlying analytics.
Beyond these screens
- A global Sprint Information System for cross-functional planning.
- OIDC and SAML enterprise authentication flows.
- Information-architecture work informed by card sorting and heatmaps.
- A scalable design system and accessibility-focused delivery.
- Transactional emails, issue grouping, and batch actions.
Evidence and limits
- The screens above come from Akhil's original public Plane case study.
- 64%, 27%, and 10× are portfolio-reported figures; raw study data is not shown here.
- Cross-project linking is labeled as an unshipped concept.
Reflection
Plane sharpened my product-management instincts. Designing the feature, the setup journey, and the public story together taught me how closely product, business, marketing, and engineering shape one another.