I’m here to talk about two related topics!:
- Tools teams should prioritize their users’ ability to maintain focus while working.
- Not every second saved is equal, even for the same person within the same workflow.
There is a tendency for tools teams to use the metric “time saved” to help prioritize their work. For example:
- “This change will shave 5s off of an operation that is used 1000 times a day across the studio.”
- “This change will save 2 hours on a task that 10 people do once a month.”
It’s a seemingly objective measure, which makes it easier to quantify and compare. But this metric can mislead tools teams into doing less impactful work.
Most users can endure a certain amount of workflow pain, distraction, and delay before their concentration is disrupted. The work velocity of someone who can stay focused for hours is far greater than the velocity of someone whose concentration is interrupted throughout their work. When fighting these disruptions, there are important thresholds at different scales. For example, if clicking a button causes the tool to react in <0.25s, that button feels responsive. If it takes over 0.5s, it feels laggy. If waiting for a load takes less than 30s, then most users will maintain focus while they wait. If it takes longer than ~45s, many users will swap to reading emails or IMs, which incurs switching costs and creates further delays.
Instead of prioritizing raw time saved, we should try to prioritize work that would bring delays under these thresholds. Fixing a point in a workflow where users lose focus is very valuable. Making a commonly used button feel responsive is very valuable because it removes a recurring pain point that can aggregate into concentration-disrupting frustration.
In practical terms we can’t know exactly where these thresholds are, because they vary user-to-user and by factors like time of day, fatigue, emotional state, availability of alternate tasks, and task urgency. We can’t turn it into an objective measure. But what we can do when we’re working on workflows is keep rough ranges in mind. Instead of asking ourselves “which change saves the most time”, we should wonder “which change allows our users to stay focused and avoid switching costs”.