During the design process, the tendency is to add more features, controls, or content than a screen really needs.
There’s a simple test to determine if you actually need one of these elements. Just ask yourself how will that element improve the users’ behavior or experience.
It isn’t a question of if it will improve the experience, but how. If you can’t answer how, then it doesn’t belong.
How a feature adds value is a broad subject, but fundamentally it must directly satisfy a specific and highly probable step in the user’s task. We go to all the trouble to create user personas and conduct task analyses, but it seems few designers really know how to apply those to the design process.
These artifacts should guide every design decision and be used to determine which elements are actually needed, and when they are needed. Ideally, each page should focus on one single task.
If a new feature doesn’t directly and immediately support that task, then it doesn’t belong on that page. It may belong on a different page, but not on the current one.
Part of the how answer should include the relationship between the user’s task and the element. It should be very specific and identified as a necessary step in the task analysis for the specified user.
For instance, “Element X allows user Manager Mike to print the completed form, which is the most likely and probable step of this task at this point.”
Adding something that increases user delight (or other user experience objective) is usually secondary to helping the user solve their primary problem, but is still a worthy consideration. Just make sure that it supports the task, well.
I’ve seen numerous “delight” elements that looked good, but actually got in the way of the task, which eventually doesn’t delight users. Again, a designer should be able to describe how that element will delight the user.
The basis for these justifications should be based on known design psychology. For instance, “Colorful depictions of cartoon characters in a children’s education website decreases performance anxiety of assessment tasks.”
What If a Frog Had Wings…
The worst question used to justify a design element starts with “what if…”
There have been hundreds of times when I’ve been working on a UI and someone asks “what if the user wants to [insert low probability scenario here].” If it was an actual priority, it would have already been identified in the task analysis.
When someone introduces an additional design element with “what if…,” chances are it’s not a high value element. That doesn’t mean that it wouldn’t fit somewhere else, though, just not where I’m working.
Reducing this kind of scope creep is as simple as asking those who contribute these ideas to walk through the task analysis to see if and where the task flow diagram calls for that idea. This is usually enough work to slow folks down. If it passes that simple test, then it might actually be worth looking at.
If Less is More, is More Less?
The unskilled designer tends to add more elements in the false hope that more choices help the user. In fact, these additional elements actually have the obverse effect.
Instead of helping the user by providing any feature they might ever need at any time, this approach only increases indecision. It’s called the paradox of choice.
With only two choices, users are pretty good at picking the right one. The more choices you provide, the more mistakes they can make.
It isn’t a linear progression, either. It’s exponential. Every new element doubles the potential for error.
For example, I’m sure you’ve seen UI’s with Apply, Save, and OK buttons on them. Most users don’t know the subtle differences between them (partly because some developers don’t seem to know the difference, either, but that’s another blog post), so the common user behavior is to click all of the buttons. In reality, you should eliminate the Apply and Save buttons and the system should automatically apply and save the users’ entries. The only choice the user really needs, then, are OK and Cancel.
This common design failure is borne from the false assumption that users know what they are doing. I’ve been conducting usability tests for over 20 years and can say, with a high degree of certainty, that most users are not experts at using a specific UI. They often stumble onto success by applying a “trial and error” usage paradigm.
How many times have you thought, “I’m not sure if this is what I need to click on, but I’ll try it and see what happens.” Thus, one of the “costs” of adding a new feature is the increased potential for error. When considering a new feature, think about how that new feature will add enough value to overcome that cost.
Sorry, You Can’t Have it All
Something else to consider is what other feature you won’t be able to include because your developers will have to burn additional cycles on the new feature you want to add. In other words, if your team only has time for 10 features and you want to add an 11th one, which of the other 10 do you want to sacrifice?
This question has prevented numerous feature creep additions over the years. But the question isn’t really intended to be flippant, either. There are cases where a proposed new feature really was worth the cost of replacing a previously prioritized one.
Every design element has a cost and a benefit. Be sure you understand both well enough to determine which elements belong on a screen and which ones don’t.
Using the task flow diagrams created in your task analysis phase, walk through your screens and identify which elements were not directly applicable to the given task. If it isn’t completely necessary, consider removing it.
Most designs typically have more elements than they really need for the users to successfully complete their task. Your job isn’t to add elements, but to eliminate the unnecessary ones.
To paraphrase Antoine de Saint-Exupery, your design is done, not when there is nothing left to add, but when there is nothing left to remove.