Editing tasks shouldn't require a detour

The smallest friction in a product is usually the one users complain about last — because they've already routed around it. For us, that was editing a task. You'd spot a typo, click into a detail view, edit, save, and navigate back, all to change three characters. Multiply that by a few dozen tasks a week and the cost adds up.

Why inline

We had a few options: a modal, a side panel, or true inline editing. Modals are familiar but heavy — they pull you out of context and force a save-or-cancel decision tree. Side panels are better but still shift the page underneath you, which is disorienting when you're scanning a long list. Inline editing keeps your eye exactly where it was. The task you're editing stays in the same row, in the same position, surrounded by the same context that made you want to edit it in the first place.

This matches how people actually use the Tasks page. Most edits aren't deep revisions — they're small corrections made while reviewing. The interaction should match the intent: light touch, low ceremony Edit a Task.

What this unlocks

The obvious win is speed. The less obvious win is willingness. When editing is cheap, people keep their task list accurate. They rename things as scope clarifies. They fix wording that bugged them but wasn't worth a full detour. The data gets better because the cost of maintaining it dropped.

It also sets up a pattern we want to extend. Inline editing is the kind of primitive that, once it exists in one surface, starts to feel obviously missing everywhere else. Expect to see it show up in more places.

What's next

We're watching how people use inline edits — which fields get touched most, where the form feels cramped, where keyboard shortcuts would help. If you want the click-by-click walkthrough, the help-center article has it. Otherwise: open the Tasks page, hit Edit, and tell us what still feels slow.