Progressive Complexity
“In the design of interfaces one must also consider carefully how one selectively informs a user about a particular system, providing well-chosen bits and pieces that can constitute a general understanding of a system.”
That was Kristina Hooper Woolsey in 1985, things may have moved on but the more that things change the more the fundamentals matter.
Whether practitioners prefer the term progressive disclosure or progressive complexity is not important; what matters is the underlying need. For this article I’ve opted for the term progressive complexity because it accurately portrays the approach as I see it: the gradual unveiling of complexity based on the desires and requirements of the user.
What is it?
Essentially, progressive complexity is a response to the inherent contradiction that users crave both power (often in the form of additional features) and simplicity. Jakob Nielsen wrote about this in 2006, Progressive Disclosure, where he said:
“Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.”
In its current iteration, progressive complexity has become more nuanced, no longer dependent on abrupt shifts like the introduction of a secondary screen. However, the fundamental principles remain unchanged: initially presenting a selection of crucial options and/or information, and providing additional details upon request.
It is important to note that there is no strict rule dictating that you can only have two levels of complexity — simple and complex. Many designs may benefit from incorporating multiple layers of complexity when appropriate and necessary.
What problem is it solving?
The inclusion of complexity in an application contributes to the cognitive load experienced by the user. A higher cognitive load increases the likelihood of errors in task performance and introduces interference that slows down task completion. Furthermore, various extraneous demographic factors can also influence cognitive load, but none of them are likely to have a positive impact.
Major factors in applications that contribute towards cognitive load include:
- Introducing too many choices.
- Requiring the user to think too much.
- Ambiguity.
The presence of these factors within an application heightens the probability of errors, diminishes the speed at which tasks are completed, and causes frustration for the user, resulting in reduced satisfaction with the overall experience.
Why does it help?
The essence of progressively disclosing additional complexity, whether in terms of functionality or information, is that it is an opt-in process. The user has the ultimate control in determining the amount of complexity they require and desire to accomplish their intended task or objective.
What we are observing in action here is The Law of Conservation of Complexity, also known as Tesler’s law. This principle acknowledges that every application inherently possesses a certain level of complexity that cannot be eliminated. However, more significantly, it emphasizes the following:
“Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it — the user, the application developer, or the platform developer?”
I would contend that this can be modified slightly to ask — who should be responsible for managing this complexity: the user, the developer, or the designer? In my view, the individuals who should bear this responsibility are the designer and the developer.
The rationale behind this is clear, but it is still worth stating. In any reasonably successful application, the number of users will far surpass the number of developers and designers. Moreover, these users are likely to engage with the application repeatedly. Therefore, the effort invested by designers and developers, no matter how substantial, will be overshadowed by the time saved by users who benefit from a simplified user experience, leading to quicker task completion. Additionally, there are intangible yet equally significant advantages of a more enjoyable user experience.
How to do it?
Let’s approach this with two examples.
Gmail
The Gmail designers have faced a challenging task due to its extensive features and configuration options.
A specific example of designed progress complexity is the settings functionality of the application. Initially, users are presented with a cog icon (1). If users choose to interact with this icon, they encounter a more complex interface, indicated by the appearance of a side panel (2) and a resizing of existing content. Furthermore, users are given the option to “See all settings”. If they decide to explore further, they are presented with a full pane of settings (3) that replaces the content but retains the navigation.
This design allows the majority of interactions with Gmail, where there is no need to change settings, to be simpler with the impact being no larger than the addition of an icon on the periphery of the interface (1).
When users decide to customize their settings, the design takes a “best guess” (2) at what they are most likely to want to do, offering relevant options. This “best guess” can be refined over time using aggregate usage statistics or tailored to individual usage patterns. Notably, this transition introduces a side panel and reduces space for the previous content space without causing a sudden shift in context.
If the initial “best guess” falls short, users can request more detailed options and gain access to the full range of application settings (3). At this point, the contextual shift becomes somewhat more abrupt, but the familiar elements of the application, such as navigation, maintain continuity. This approach is appropriate as the user’s primary task and focus have changed.
Medium
We can see Medium taking a very similar approach.
Additional functionality is initially hidden under the “…” icon (1), with the user being offered common tasks, additional complexity, and finally the full story settings are displayed (3). As with Google, the shift from 1 to 2 is not abrupt. In this case, a drop-down menu is presented. The shift from 2 to 3 is abrupt, arguably more so as it is a full-page shift and a reload to boot. An interesting note here is that the link presented for this is “More settings” but the user is presented with Story Settings after the transition — this could be viewed as suboptimal as it may be slightly misleading.
Conclusion
Using the concept of progressive complexity, or progressive disclosure, we can withhold a large amount of complexity within our application's user experience. By doing this we can reduce the cognitive load on the user and thus improve the user’s experience with the likelihood of reducing errors and improving satisfaction. The need for doing this is more pressing in complex applications and as applications become increasingly more complex this need will increase.
Authors note:
I am currently deeply interested in using AI to generate both visual and text-based content. I am actively collaborating with AI on multiple platforms to explore my thoughts on what creativity is and is not.
My current approach is to collaborate with AI by using the output as a foundation to build upon and modify.
Other than in the examples the images for this article are created using Midjourney. The approach used was to enter only the section title as a prompt, select one of the variants, and create variants of that, the exact text used is under the image. An image was selected from the second round of variants for upscaling and this was upscaled for inclusion.
