How to design around advanced options and complicated fields
Three design patterns for organizing complexity in your form fields
“It’s not negotiable, we need to include that field.” Unfortunately, I’ve heard that sentiment more than a few times when attempting to streamline complex interfaces.
As designers, we know that users often perform actions by mistake, and it’s best to eliminate error-prone conditions to help them avoid making mistakes. Those are two of Jakob Nielsen’s Ten Usability Heuristics: User Control/Freedom and Error Prevention.
But sometimes, you can’t get rid of specific input fields. Whether for a technical reason or something the organization requires, you’re forced to include several fields that 95% of users will not need to see or mess around with.
Once you’re done trying to argue against it, what should you do in these cases? Depending on the user journey and use case, you can consider three potential design solutions. Here’s when to use each one.
Defaults are helpful for quick (and standard) interactions
Defaults are when fields come pre-populated with common values that most users will select. Considering that most users will not change away from the default, it’s a way to ensure that users will likely select a particular option.
While defaults are sometimes limited to a single field, it’s become increasingly common to have ‘selectable’ defaults, where a single choice (like selecting a saved credit card) results in fields being filled. As a result, users may be used to working with defaults in many interfaces through their e-commerce purchases.
One of the advantages of this approach is it leads to lower interaction costs for most users, as they don’t have to think about these fields and can skip to the following field. However, defaults can also make it more likely for the users to make a mistake.
For example, I’ve accidentally shipped packages to an old address (in another state) because I quickly used auto-complete for both my credit card information and address. Not only that: defaults can sometimes cause problems due to context, such as when the default value ‘999’ is applied to the ‘Patient Age’ field.
This is why you should be cautious when applying defaults. If you’re going to try and use defaults, ask yourself two critical questions:
How sure am I that the user will answer in a particular way? The wrong defaults tend to add extra work to a user’s process (and are more likely to become an error if left unchanged).
How do I prevent errors that might occur with defaults? For example, ‘smart’ credit card defaults still prompt the user to enter their security code to verify the credit card often. In addition, failure to provide a secondary check can sometimes lead to defaults as a dark pattern.
If it seems like defaults might not work for you, you might want to consider the next option.
Nerd Curtains and Toggling an Advanced Options menu
The “Nerd Curtain,” as I’ve heard developers call it many times, is slang for putting things under a button like “Advanced Options.”
This is a common option for these fields (because it’s easy), but it has two primary problems. First and foremost is how this is similar to hamburger menus on mobile devices, which act as a junk drawer.
This is a matter of organization: if options are haphazardly thrown into an “advanced options” menu, it’s tough for users to find what they want.
The Second problem is the matter of visibility: when you shove everything into an “Advanced Options” menu, there’s no indication that users will find what they are looking for.
The phrase “out of sight, out of mind” doesn’t just apply to you, trying to simplify the design: it applies to your users when they are trying to understand what your application does.
So the “Nerd Curtain” needs to act like a toggle: when users click on it, they can see a well-structured and thought-out set of additional options.
So there are two critical questions to address if you’re planning to use a ‘nerd curtain’:
Can you break down the options into specific categories/organizations and properly sort them? This could be as simple as labels that say “Advanced Networking Options” or Grouping items by proximity.
Are you sure that each of these advanced options should be hidden? Hiding these options means that the users are less likely to interact with them, which may not be ideal in certain circumstances.
If you answered no to the second question, perhaps the third option might be for you.
Infinite scrolling + Hierarchy allows for prioritized options
You can also leave all the options on the page but follow Steve Krug’s advice when stakeholders want their low-priority project on a crowded home page: smile, nod, and then put the low-priority project at the bottom of the home page.
In this method, you’re organizing your options based on user priority from top to bottom and arranging the options so that advanced options require the user to scroll.
Designing the page this way usually requires the use of anchored buttons so that the user can take action at any time during the page (such as “Save Changes” or “Cancel”). You also probably need to do a card-sorting exercise with users to understand how they’d prioritize these options (as understanding priority is crucial to this approach).
This way, the user is likely to change the most visible options at the top of the screen while mostly ignoring the bottom ones. It is often less aesthetically pleasing than the previous two designs, but sometimes this pattern is necessary, depending on the options involved.
These three approaches often directly help a group of expert users you might not otherwise think about.
Don’t forget that well-designed complexity helps expert users
For many designs, we tend to focus on the new user experience. This is because most of the time, our users will be new or intermediate. However, oversimplifying fields and haphazardly hiding fields for new users can hurt the experience for expert users.
This is because expert users often use these advanced options and aim to complete these tasks as efficiently as possible (since they may be doing it hundreds of times a day).
New users are also often likely to seek recommendations and reviews from expert users. If they hear your product sucks and it’s super frustrating to use (from a group of experts), new users might not want to line up and try it.
So if you’re asked to add complexity or additional fields to a process, think of it as an opportunity to cater directly to your expert users. With these three options, you might find that there might be clever solutions that meet the news of both new and expert users.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.