---
title: What Linear Figured Out
slug: exemplar-linear
kind: exemplar
summary: That software used all day is a keyboard instrument, and that speed comes from removing round trips rather than from optimising them.
problem: >-
  Tools for daily operational work are usually designed for the first-time user
  — mouse-driven, dialog-heavy, waiting on the server before showing anything.
  The people who use them for six hours a day pay that tax on every action.
family: [act, edit, find]
principles: [friction, orientation]
status: stable
visibility: public
related:
  - title: Command Palette
    url: /patterns/command-palette
    summary: The pattern their whole interaction model is built around.
  - title: Optimistic Update
    url: /patterns/optimistic-update
    summary: Why their interface feels instant — no round trip is ever waited on.
  - title: Master–Detail Drawer
    url: /patterns/master-detail-drawer
    summary: Their issue inspector, and its keyboard-driven ceiling.
---

## The insight

**For daily software, the bottleneck is not the server, it is the round trip
through the interface.** Click a row, wait, open a menu, find the option, click,
wait, go back. Each step is fast and the sequence is slow, and it repeats
hundreds of times a day.

Their answer is to remove the sequence rather than speed up its parts: the
keyboard reaches everything, the interface commits before the server replies,
and the list never has to be re-found because it never went away.

## What is worth stealing

**The palette is the primary interface, not an accelerator bolted on.** Records
and actions are in one ranked list, ordered by recency, so "get to the thing"
and "do the thing" are a single gesture. The product is genuinely faster to
drive from the palette than from its own sidebar.

**Optimistic by default, with a loud failure path.** Nothing waits for
confirmation of a change the user already decided. That is only acceptable
because the failure case is visible and local — the aggressiveness and the
honesty are one design, not two.

**The drawer keeps the queue.** Issues open beside the list, and the keyboard
moves between them, so reviewing twelve issues costs twelve keystrokes rather
than twenty-four navigations. Crucially the issue also has a real URL and a real
page, so the drawer never traps anything.

**Selective inline editing.** Title and properties edit in place; anything that
notifies people stays an explicit action. That line — composition is inline,
consequences are deliberate — is the judgment most products get wrong in one
direction or the other.

**Views are views.** Board and list are two renderings of one dataset, switchable,
with the grouping attribute chosen by the reader. The board is never the model.

## Where it does not transfer

Linear is used by people who will invest in learning it. A palette-first,
keyboard-first product punishes occasional users, and much internal software is
used monthly by people who will never learn a shortcut. There, the visible
affordance matters more than the accelerator.

Their density and restraint with colour also assume a homogeneous, technical
audience working in a quiet, dark interface. That is a style, not a rule.

## The extraction

> **Design daily software for the second hour, not the first minute.**

The first-run experience matters, but it happens once. If people will use this
every day, count the round trips in the loop they repeat most, and remove them —
by keyboard, by staying put, and by not waiting for the server to confirm what
the person already decided.