Managing Complexity

Get the software out the way of the user.

"...Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it... If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer's job easier."Larry Tesler
Complex apps are a personification of that quote. Complexity must be dealt with either by the user, or by the product. Here are the standard approaches for dealing with complexity within a product:
  1. Remove unnecessary complexity.
  2. Remove features.
  3. Restrict complexity.
  4. Redefine the workflow.
Number 1 can generally be achieved by never getting into a position where this needs doing, however, iterating on designs to simplify them without compromising on utility is certainly possible, and if you're drafted in to improve a design this is often the first thing that need doing; doing things like consolidating controls or concepts, or providing new ways of controlling things such as direct manipulation can all help here.Number 2 compromises on utility, which Barbara Mirel proved time and time again is a fool's errand, to do this is to live in denial; read about Apple's widely derided redesign of Final Cut Pro here and here for lessons on why simplicity at the expense of utility is a red flag in complex professional software.Number 3 is where we can make some day to day progress: progressive disclosure (see below), and better organisation of data are the most common ways of dealing with complexity at the surface level. This also eases the learning curve for beginners as the more complex controls are confined, but hopefully still reachable and obvious when needed. This is also the most misused way of making interfaces simple where something that should be three buttons next to each other is turned into a one button menu with three options. I like to call these telegraph errors. See below for more on this.Number 4 is where you can jump usability curves. This is about rethinking the problem to achieve the same outcome with a simpler workflow, this tends to happen when the product deals with the complexity, instead of the user. This is where you can create daylight between your product and its competition. In my opinion, number 4 wins, and when you can't do 4, do 3. I'm a firm believer in pulling complexity downward, away from the user and into the architecture of an app (be that the engineering architecture, the information architecture, or the general design and layout), that way users don't have to deal with it; how to go about this is will be a topic later in this section. A benefit of this approach relates to an observation by Bruce Tognazzini, which is that people want a certain level of complexity in their lives (Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi explains why this might be), therefore when you simplify an app, users will attempt more complex tasks. Thus by streamlining workflows, users will effectively push themselves to do more or better. This goal is what we should all be striving for in complex app design, getting the software out the way of the user and allowing them to get the job done, and perhaps even to do a better job of it.

Interaction Complexity vs Interface Complexity

A common mistake designers make is to not account for interaction complexity when designing interfaces. Interface complexity is often the only kind of complexity considered, and this missing perspective is responsible for bottlenecks and much unnecessary friction in products.Imagine that you want to send a message, let's take a look at two possible ways of doing this. First we'll consider the telegraph key, it has an irreducibly simple interface consisting of just one button, it literally could not be more simple, however the interaction complexity is exceptionally high, the user is required to tap out messages in Morse code, an outcome which cannot be inferred from its interface.Next let's look at a keyboard, a device where the interface complexity is extreme; on most keyboards there are 104 keys. So, let's say it's 104x more complex than the telegraph key interface. However, the interaction complexity is far simpler than the telegraph key. To type an 8 on a telegraph key, that's dash, dash, dash, dot, dot (and don't make a mistake!), to do the same on a keyboard requires you to simply locate the number and tap it. If you get it wrong, there's the backspace key; finally, the task of typing on a keyboard can also be mostly inferred from the interface, which is not true of the telegraph key. Which one would you rather write a book with? The simple interface? Or the complex one? Achieving both is possible of course; Apple opted for a single button mouse on the original Macintosh (most mice at the time had 3 buttons) and a huge engineering and design effort was required to support this simple interface/ interaction in the system and apps, this included the invention of the double-click, a thing that some people could not get over even decades later.
All in all, reducing interface complexity can cause interaction complexity, and interaction complexity is what costs users the most time. Bare this in mind when looking over the section on progressive disclosure below and make sure this is not a mistake that you're making. If you go from having one button to two buttons, sometimes you should just show them both, rather than putting them under a three dots menu. There's an example of this kind of mistake toward the bottom of this page.
For the rest of this article, we'll look at concrete interface elements and asses when they are useful, and how to make them appear more simple; then in the next part of the guide we'll look at managing complexity in workflows feel free to skip ahead if that's of more interest.

Information Overload

Reducing information overload is not necessarily about reducing the amount of things on a screen, it’s about organising things in the optimum way so that they can be easily processed by the brain. The brain can process different visual aspects in parallel, like colour, position, shape, texture and movement. Using more signifiers doesn’t slow things down for the brain, in fact it’s the opposite, the more of these you use, the faster something will be recognised. If all this is new to you, it's time to brush up on your Gestalt Principles.The fashion these days is to have a single key colour in an application, any complex app without multiple key colours is missing a very simple trick.Using shape/ colour/ size/ grouping is the most pure example of synergy in product design, the resulting whole being so much greater than the sum of its parts. 

Progressive disclosure

Progressive disclosure is one of the most useful tools in CxUX, the idea is that you should initially only show the user a few options, allowing them to see a larger set upon request, thus reducing interface complexity. The initial options should be the minimal core/ essential set (if there are any), or a logical sub-set of all available options if that split is not easy to make. The worst thing you can do with progressive disclosure though, and this is important so pay attention now, is to remove the user from their current context; controls or workflows that require a context change (like a new window, or full screen modal) should be designed out and changes should be made inline (or as inline as possible via PopOvers for example) where possible.
Obviously, the advantages complex artifacts and systems can bring are often so great that they overshadow the inconveniences and accidents their complexity may give rise to in our interactions with them. Complex interaction has thus typically been presented as a problem, an undesirable side effect of a superior technical solution, to be solved by interaction designers. Consequently, designers have been hard at work trying to make complexity disappear from the user’s view, sometimes perhaps too hard.- Janlert, L. E. and Stolterman, E.

In Brief

Good ways of adding progressive disclosure:
  • Tabs.
  • PopOvers and Pseudo-Modals (with a strong context).
  • Presentation sheets.
  • Sidebars (including slide-overs and pop-outs as long as they're obvious).
  • Menus, sub-menus, contextual menus, and, *sigh*, hamburger menus.
  • Inline Controls / Direct Manipulation. This excludes 'modal tools' (see below).

Neutral ways of adding progressive disclosure, use with caution as they can go wrong:
  • Modals - for critical/ destructive actions.
  • Rollover Areas - e.g controls get hidden when the mouse is outside of a given area.
  • Rolldowns - these constantly fail user testing in our experience, but I personally don't mind them.
  • Workflow Wizzards - these remove the user from their current context, which is very bad, however for some uses like setting up complex projects (in an IDE for example) and such they can be amazing. Setup/ Onboarding wizzards are also great of course.
  • Modal Tools - specific modes for editing certain aspects of given data. Beware of mode slips!

Bad ways of adding progressive disclosure:
  • QuickTime's content blocking playback controls in the content area. 
  • Swapping widgets on rollover - Music on macOS used to be guilty of this but it's now thankfully fixed. Airtable however...

In Depth

Tabs

Tabs are an excellent way to progressivly disclose controls as they have a helpful built in title, I love self documenting controls.
  • Remember to make it clear which tab is active.
  • You can place additional information (e.g icons/ feedback) in the tab item if you need to, see the below example.
  • Consider adding the ability to re-arrange and close tabs, and the ability to close everything except the open tab (Apple's Safari is the gold standard for tab behaviour if you need inspiration).
  • Consider drag and drop actions that go between tabs, or that require tab switching, again, see the example below.
Tabs in Cavalry contain additional information in the tab item (fill and stroke colour). You can also drag between tabs, and note that the active tab is very clearly obvious. The controls are split into catagory tabs, with rarely used advanced controls relegated to the far right tab.

PopOvers and Pseudo-Modals

Invented by the Apple iCal team in 2009, PopOvers were quickly adopted as a near perfect way to reveal complexity. PopOvers are quasi-modal, that is to say they appear like they're modal, but they aren't, giving them all the advantages of modality (like focus), without any of the drawbacks (like a requirement to interact with them). To dismiss a PopOver you click outside it, you can also drag them around to move them out the way of any important contextual information (Cavalry does this in a slightly different way, see below). PopOvers appear in different locations depending on what screen space is available, so they may appear above/below or to the left/right of their calling point.Finally, PopOvers have a neat little arrow that tells you where they came from adding extra contextual information. They're such a great idea, 10 points to whomever came up with them.
In Cavalry our PopOvers have an extra trick up their sleeve, it's entirely possible you want to manipulate the settings they contain for an extended period of time, or reference them against those contained in another, to facilitate this, PopOvers in Cavalry can be converted into 'float on top' windows by moving them (note these are distinct from modal dialogues in that you can interact with the rest of the app when they are open).
Pseudo-Modals are like the PopOver's sickly twin. They're generally pretty good, but without some sort of selection indication, the lack of context can be confusing. In this (edge case) example, I've asked Airtable to edit the description of a field - but which field is this the description for? With a true PopOver, an arrow head would indicate the field in question.

Sidebars and Presentation Sheets

On desktop and mobile it's very common to see sidebars - these can be hidden and shown at will and contain related functionality to the window that houses them. When used well they don't remove or cover too much useful contextual information, and they are always non-modal. The activation button should also be obvious, the above example could of course do with it's button labelling.
As for modal presentation sheets (the thinking person's modal dialogue), these have pretty much dissapeared on the desktop, Apple used to use them for their Print/ Page Setup and toolbar customisation dialogues, and they were all the better for it. A big advantage of presentation sheets is that they are attached to the window that calls them, giving them a strong context in multi-window applications. Thankfully they are still going strong on mobile.

Menus

There isn't a huge amount to be said about menus given that we've all probably had tens of thousands of interactions with them, thus demonstrating their importance, and simplicity. I'll try to share a few tips non the less.Contextual menus are a great way to 'bury' complexity, but be warned, they're not very discoverable, and if a user doesn't know that a feature or option is there, they can't use it, so as a rule of thumb, we try to make sure that contextual menus are never the only way to do something, instead we place accelerator workflows and frequently used utilities in them. One more thing to note about menus is this great gem from NNg on Designing Long Menu Lists.On ordering menus, (when you're not listing things in alphabetical order), there are a few things you can do to keep things clear:
  • The first things you do go at the top (e.g New and Open).
  • Order everything else by frequency of use.
  • Put keyboard shortcuts in menus for learnability.
  • Group similar actions with separators, there are usually any number of ways to group menu items, just pick a route and stick to it.
  • If you have lots of menu items, let your menu be tall! Don't artificially crop the menu box to a fixed height, this slows down users, the brain is very good at scanning long lists, making people scroll is slow!
Search in menus is exceptionally useful, on macOS apps get this for free, but on the web, mobile and Windows, you'll need a custom solution for this exceptionally useful functionality.
Here's an example of stretching the menu pattern (hopefully in a good way), on the right we have a drop-down menu (sometimes called a combobox), in Cavalry this sometimes gets used as a way to edit the controls available on a layer. The reason I'm showing this is because there are a few neat things on offer here:
  • The drop-down menu is searchable
  • Focus is put into the search field when you open the menu (so you can just start typing).
  • The top search result is automatically selected.
  • Hitting return will switch modes to the selected row.
  • Pressing escape will close the menu.
  • Using arrow keys will navigate the menu.
  • Beginners can just use the mouse 😁
As a final word on drop-down menus, I often hear UI designers say you should never have a drop-down with only two options and that in that situation a checkbox should be used, this is unmitigated nonsence. If it's helpful to users to have mode titles (i.e self documenting controls) then by all means have a drop-down with two entries; clarity is paramount in CxUX.

Inline Controls / Direct Manipulation

Inline controls are not just useful, they're often fundamental to the frictionless operation of software, as not everything can or should be done in property panels and menus. However, as with all things, there's a good way to do it, and a bad way. As a rule of thumb:
  • If a control manipulates something inside the content area, there is no problem.
  • If a control manipulates the content area itself, having it inside the content area is usually a bad idea.
Done well, it creates a seamless and clear way to operate software, providing context (showing current state) and providing a route forward for the user. Take this simple example from the wonderfully designed Craft. It's worth noting that even though you could call this a pseudo-modal (generally not as good as a PopOver), it still has strong context due to the selection of the text.
Let's take a look at where this can go wrong. Here we have a movie in Quicktime, and I'd like to scrub it, backward and forward to examine the video. Notice anything irritating? It's not possible to interact with the controls without blocking content you need to not be blocked. While this UI is very tidy, I'd personally file it under elegant failures. It could easily be fixed by, for example allowing the control panel to be moved out of the window at the bottom (and pinning it to the bottom edge so it can't be fully detached). Putting centralised immovable controls under the window would also work if there was no requirement to also be fancy as well as functional (I am not convinced the ability to move the controls adds anything). For an example of how this should work, see the exceptional Screen app.

Modals

Modals have so few good use cases that I'm just going to list them, because they are an absolute last resort UX pattern due to their blocking nature and flow/context disruption because of the fact they must be dealt with, here's where they're okay:
  • Destructive actions that require confirmation. For example, overwriting some data the user might care about.
  • Critical workflow junctions where the user must make a choice that cannot be otherwise inferred or chosen ahead of time, like Open, Save, Import and so forth.
  • Blocking wizzards, such as one for setting up a new project in a content creator or IDE, or a wizzard for setting up an OS on a shiny new computer.
  • As a feedback mechanism for blocking actions (like a progress bar modal when doing a huge data import) that cannot be done asynchronously (progress bars for asynchronous actions should be psudo-modal or non-blocking elsewhere in the UI).
That's it, we're done.A word of advice, if you find yourself with a modal in your workflow, consider designing it out. In Figma for example, modals are thrown up in the middle of the screen (e.g by the requirement to name a new Grid Style) when simplifying the workflow would mean they could be avoided completely (just create the style, and let me edit the name inline - bonus points for putting me into the renaming state automatically). Naming a Grid Style is not a destructive or critical action, thus a modal is not warranted and simply causes needless friction.

Rollover Areas

Having controls dissapear when the mouse isn't near them is a completely logical thing to want to do, it keeps screens clean and visual designers happy. There is a downside though, hidden things are quite obviously not discoverable, a user scanning a screen for a feature will not see it if it's hidden, therefore, mission critical features should never behave like this. The last thing you want is a user minesweeping your app for the thing they need to click.
The other downside is that they are a higher friction interaction, take the following:
  1. Scan for a button.
  2. Move the mouse to the button and click.
Compared to:
  1. Scan for the rollover area.
  2. Move the mouse to the rollover area.
  3. Scan for the button.
  4. Move the mouse to the button and click.
So while an excellent way to make a UI minimal and probably more likeable, if it's important, don't hide it. 
Figma use rollover controls, mostly quite sucsesfully, however this example baffles somewhat (though it's a harmless error really). As you can see there is a jarring movement of information without any justification (that I can think of). Irksome is the word that springs to mind.

Rolldowns

Rolldowns are essentially unavoidable in some types of interface (like a hierarchy), but they also get used to progressivly disclose additional controls. With hierarchies rolldowns have never been, to my knowledge, controversial, however with controls they have been known to cause confusion, the most common source being that a user rolls up some controls, then does another task, switches back to the previous task forgetting they have rolled up the controls, which they now can't find. You may think this daft but I've been on the receiving end of more "Where have my controls gone?", or "I don't have that control." support requests than I'd like to admit. There are more elements at play here (for example a clearer visual design would help I'm sure) and lists of rolldowns compound the problems, but hyper-flat UIs have made this a very difficult method of progressive disclosure to use sucsessfully.As an aside, Motion also uses the same affordance for it's rolldowns as it does for it's disclosure arrow, this is generally not a great idea as it can confuse users when the same symbol is used to mean different things. It would be much safer to use the standard right angle bracket style chevron here: >This disclosure control confused me when I first saw it (which was a bit embarassing) - though I understood what it was after clicking it. I'm not sure embarrsing users (even idiots like me) is the desired UX here.

Wizzards

Don’t use wizzards (or modals or separate contexts) for adding or editing information, they pull users out of the main working context - this is known to be very bad. On the face of it, wizzards sound like some kind of clever progressive disclosure - however research has found that maintaining context is far more important than trying to keep the UI simple. For example, if you need to be aware of the current state of anything, it forces you to remember this, rather than just seeing it, users then need to re-contextualise when they are done with the current task. In short, discount the tools we know work (like psudo-modals) before going context destroying multi-step modal. This point is made (ad-nausium) in the Interaction Design for Complex Problem Solving book. Instead you should design a way of working that does not require such context destroying interuptions.

Object / Verb vs Verb / Object

When editing a document do you select the text and then hit the delete key, or do you hit the delete key then select the text?This may sound redundant to anyone who has never used VIM, but some software is based on this kind of backwards workflow. I.e, you go into a delete mode by pressing the delete key, then you select the thing you want to delete, then terminate the mode to commit your action. This is how word processors used to work in the late 1960’s and early 70’s until the late great Larry Tesler got ahold of them. Why do I bring this up? Well, beware of wizards, they often work in a similar backwards fashion, you open a wizard (that is to say, you choose the verb) then you select the object the wizard is operate on, then once you've completed the Wizard's setup, you commit the action. Spreadsheets also often have these modal / back-to-front workflows. These can confuse users as the normal pattern of use is reversed, this is something that can cause stop and think moments, or simply general confusion when done badly. Wizards that will perform an action on something you define AFTER opening the wizard are modal, and modes are generally bad, though of course there are exceptions (tool modes for example bring clarity to workflows, at the expense of occasional mode slips). As ever, use your judgement.

Widget Replacement

The idea here is that because screen space is so short on a 32" 5k monitor (this is sarcasm people), a clever thing to do is to have a peice of information on screen only when the mouse isn't nearby, but when the mouse approaches, you hide that information and replace it with a mysterious control of some sort. 
The problem with this, is that the user has just declared an interest in that information by moving the mouse to it, and then you've gone and removed it. It's staggeringly bad design and I'm yet to see a valid use of it. Apple used to be very guilty of this in iTunes and then Music (where this was finally fixed in a recent version). However, I just happen to have a shaming screen capture which you can see on the right. The idea here is that I want to see how long a TV show is, so I scan down the rows to identify the show, then move the mouse over to the right to make sure I'm reading the correct number - only the number has dissapeared and has been replaced — as if to specifically anger me —  with a hamburger menu. It's not like there's not enough room for both! 
Airtable, the worlds biggest fans of the modal dialogue (though I note that they are fixing this, so credit is due for that), also appear to like this bizarre patten. Here the crime isn't as bad, but once again, it's just unnecessary.Show both you cowards!
It's now time to see some examples of how workflows can be short-circuited.