Design deserves its own tool.
For fifteen years, design teams have been forced into tools built for engineers. The price has been creativity, autonomy, and trust. Lane is the correction.
This page is not a pitch. It is the line we drew before we wrote a single line of code, and the line we will keep drawing every time a feature request threatens to cross it. If you disagree with what follows, Lane is not the tool for you — and we would rather you know now.
1. The surveillance problem
Somewhere along the way, “visibility” stopped meaning “the team understands the work” and started meaning “the manager can watch the worker.” Last-active timestamps. Time per card. Individual velocity scores. Heatmaps of who opened Figma on a Sunday. These are not project-management features. They are productivity-tracking features wearing a project-management costume.
Design work is the part of the product process that most needs quiet, slack, and permission to be wrong in public. It is the work that happens in the shower, in the margin of a notebook, in the forty-fifth iteration of a frame nobody will ever see. Surveillance tooling does not make that work faster. It makes it hide. It teaches designers to optimize for the chart, not the user. It turns leads into supervisors and teammates into data points.
The honest answer is that most of these metrics exist because they are easy to collect, not because they are useful. A timestamp is cheap. Understanding what a designer actually did this week is expensive. So the industry settled for cheap, and called it rigor. Designers, reasonably, stopped trusting the dashboard. Leads, reasonably, stopped believing the numbers. Everyone kept the tool anyway because the alternative felt like flying blind.
Support produces truth. Surveillance produces performance. We picked a side.
2. The words matter
Every tool you use is a vocabulary. The vocabulary shapes the thinking. The thinking shapes the work. Ticket systems teach designers to call their craft a queue, their research a blocker, their exploration a delay. After a while, the team starts to believe it. Lane refuses that vocabulary and replaces it with one built around how design actually happens — the words below are not cosmetic, they change what the tool will let you do.
- Status update →
- Reflection
- Sprint →
- Cycle
- Velocity →
- Throughput
- Utilization →
- Capacity
- Ticket →
- Request
- Due date →
- Appetite
A reflection is written by the designer, for the designer. A status update is written for a manager.
Design is not a sprint. It is a cycle of sensing, framing, diverging, converging, and shipping — and then doing it again.
Velocity measures how fast you move. Throughput measures what actually left the building and changed something for users.
Utilization is a factory metric. Capacity is an honest conversation about what a person can hold this week.
A ticket implies a queue and a worker. A request implies a person asking another person for help solving a problem.
A due date pretends to know what the work will cost. An appetite says how much we are willing to spend before we re-check the problem.
3. The five no’s
Lane is defined as much by what it refuses as by what it ships. These are the lines we will not cross, even when a customer asks, even when a competitor does, even when it would close a deal.
- 01
No surveillance.
No last-active timestamps, no time-per-task, no screen-activity logs. Privacy is the default, not a toggle.
- 02
No tickets.
Design work is not a queue of identical cards. It is a living stream of problems with context, appetite, and consequence.
- 03
No tools borrowed from engineering.
Linear conventions, sprint rituals, and velocity charts were built for execution work. They punish the thinking work designers do.
- 04
No individual velocity scores.
Ranking designers by speed produces faster slop, not better outcomes. We measure shipped impact at the team level.
- 05
No forced status theatre.
Standups, check-ins, and weekly screenshots of in-progress Figma frames are performance, not progress. Reflections go to the designer first.
4. What Lane is for
Lane is for the designer who wants to think before they ship, and the lead who wants to protect that thinking. It is for teams that measure what changed for users, not what moved on a board. It is a workflow shaped to exploration, reframing, and craft — a tool that treats design as a discipline with its own rhythm, not a cheaper version of engineering.
Lane is for the PM who wants better problems framed, not faster tickets closed. It is for the engineer who is tired of receiving a final Figma frame without the reasoning behind it. It is for the founder who noticed their design team getting quieter the more dashboards they added, and did not want to pretend that was progress.
If any of that sounds like your team, join the waitlist. We are building Lane for you, and we would rather hear from you early than guess.