the reach-exceeds-grasp problem
a new way to think about digital clutter, overload, and cognitive cost
Foreword
This essay introduces concepts that Finn and I kindled while we were prototyping a web browser in July 2024. The key idea was that the browser played an active role in modeling your intent as you used it; making sense of your browsing activity and history, the browser would guess the tasks you were trying to complete, the intentions you had during a session of browsing, and the long-term goals that these intentions may have fed into (more here). With this intent model, the browser would then,
infer the task behind a tab (for example, the “Book a ticket for Mickey17” task could be assigned to an open tab of AMC showtimes), making it easier for you to find and retrieve the tab because we remember the context of use better than the site of use,
mark a task as being complete or incomplete,
complete an incomplete task on its own (with your permission!),
passively organize tabs into “paths” that lead to a long-term goal (eg situating research rabbit-holes within a broader context of “niche HCI Research”)
assist in planning a new browsing session, where it might nudge you to “pick up where you left off” based on the tasks it knows you didn’t complete (without judgment!)
Using tab groups, profiles and bookmarks, you can create an intentional browsing experience. But you also need to practice immense patience and restraint to do so, because you have to do this all on your own.
In addition to doing what you want to be doing - completing tasks and realizing your goals - you have to manage the system to act in alignment with your intention - grouping, regrouping and ungrouping tabs, moving tabs to the right order, closing tabs, bookmarking. All of this is manageable if you’re willing to do the work, but at some point, it becomes too difficult to manage, and you’re doing this all on your own.
To address the problems described above, we needed new conceptual language to reason more consistently. Using the lens of complexity science, we formed the concepts of meta-task, reasoning cost, interface system dynamics, complex data objects, which are introduced below. We hope you find them useful.
An Interface’s System Dynamics
We first characterized interfaces along two dimensions:
Agency over the System, which measures the degree to which we can enact our intentions upon/within a system,
System Complexity, indicating both the number of possible actions and the volume of objects to act upon within the system.
When we mapped this space, we identified three interface usage regimes:
Human-Scale regime (high agency, low complexity)
We also called this the “designer’s ideal” regime, as it reflects the conditions designers likely envisioned when creating the system.
Reach-Exceeds-Grasp regime (low agency, high complexity)
Here, system complexity surpasses our cognitive capacity and the available tools to manage it. This regime is synonymous with experiencing "information overload" and is common across browsers, home screens, email inboxes, issue boards, and messaging apps, the digital spaces we seem to find ourselves in.
Tamed-Complexity regime (high agency despite high complexity)
A theorized optimal state, which tools like the intent-model aim to help users achieve.
The diagram also claims a spiral dynamic. We begin in the human-scale regime, but slip into the reach-exceeds-grasp regime as the system complexity increases, and then spiral deeper into it, experiencing less and less agency and more and more complexity.
The transition between these regimes follows a spiral dynamic. Users typically start in the human-scale regime but slip into the reach-exceeds-grasp regime as complexity increases. Without corrective measures, they spiral deeper into complexity, losing agency. Our objective with the tools described is to reverse this spiral, moving users from reach-exceeds-grasp into the tamed-complexity regime. We call this restorative spiral "curl”.
But what is responsible for making things more complex? We call them, “complex data objects”.
Complex Data Objects
A data object is complex in that it grows unbounded in size unless regulated by explicit user action. Common examples of these actions are naming data, deleting data, sorting data into categories, and managing the categories themselves, common language for these actions is “busywork” or “checking off boxes”, but we will call them “meta-tasks” as they are in the way of but still required to perform activities with a system.
Performing each of these meta-tasks is marginally inexpensive in reasoning cost. For example, the decision to delete a “LinkedIn: Update from your network” email object happens once per email object. From this, we say that decision is marginally O(1) in reasoning cost. But since we do this N times over the course of processing the complex data object of the inbox, we can say that the management of a complex data object (an overloaded inbox) is O(N), where N is the number of data objects contained within it.
Processing a large data object, as you can imagine, amounts to a dull and fatigue-inducing user experience because there are so many objects to work with, and the actions aren’t especially interesting (16,789 unread emails means you decide to perform the delete decision 16,789 times). The prospect of doing dull, repetitive and fatigue-inducing work, for users who aren’t “the Organizing type”, isn’t the most enticing thing.
The user then postpones performing these meta tasks to a later date, more objects accumulate in the time between now and the later date, and when, on that later date, the user is greeted with even more things to do ... they postpones it again, and we spiral deeper into the reach-exceeds grasp regime.
This spiral into the reach-exceeds-grasp regime can be observed in many of the interfaces where we spend most of our time - file systems, email, issue boards, message channels, follow lists, browser tabs / history - and each interface names the problem in their own way: file clutter, flooded inboxes, stale tickets, unread messages, and tab overload, respectively.
Shared Data Objects Tame Complexity
In another post, we’ll show you how we used the concepts above to conjure the Complex Data Object’s antidote, the Shared Data Object. This is first example of an interface pattern that suggests how, by sharing data objects between user and System, meta-tasks on the object can be offloaded to the System through input and instruction from the User.
Sneak Preview: your Following list as a Shared Data Object