There is a tendency during a design process to add more content, controls or features to a screen than are really necessary.
There is a simple test to determine whether a particular element is actually needed: All you have to do is ask yourself how the element will improve the users’ experience or behaviour.
The question is not if the experience will be improved, it is how. If you are not able to answer how it will make an improvement, then it simply isn’t needed.
How value is added by a feature is a very broad subject. However, it must directly and fundamentally satisfy a highly probable and specific step in a user’s task.
We take the time and trouble to conduct task analyses and create user personas; but, it doesn’t seem like too many designers truly know how they should be applied to a design process.
Every design decision should be guided by these artefacts and used for determining which elements actually are necessary as well as when. Each page ideally should focus on just one task.
If the proposed new feature does not immediately and directly support the task, it does not belong on the page. It might belong on some other page, just not the current one.
The relationship between the element and the user’s task should be included in the how answer. It needs to be very specific and it is a necessary step for the user in task analysis.
For example, “Element X will allow user Mike Manager to print a completed form. At this point in the task, this is the most probable and likely step.”
Adding something that will increase user enjoyment (or some other kind of user experience) usually is secondary. The main objective is to help a user solve his/her primary problem. However, it may still be considered. You just need to ensure that the task is supported well by it.
I’ve seen many “enjoyable” elements that had a good appearance. However, they actually hindered the task. Eventually users don’t find that enjoyable. The designer needs to describe how the element can help as well as delight the user.
Known design psychology should be used as a basis for the justifications. For example, “Colourful cartoon character depictions on a children’s website help to decrease performance anxiety with assessment tasks.”
When justifying a design element the worst question you can use begins with “what if…”
There have been numerous times during the middle of working on the UI when someone asked “what if a user wants to [low probability scenario].”
That would have been identified during task analysis if this was really a priority.
When an extra design element is introduced by someone with “what if”, there is a good chance the element doesn’t offer high value. However, it could fit in someplace else.
There is a simple way to reduce this sort of scope creep. Just ask the people contributing the ideas to take a walk through of the task analysis and see where and whether the idea is called for in the task flow diagram.
Usually this work is enough to slow people down. If the simple test is passed, it could be something actually worth taking a look at.
Here are some user interface design tests you can use.
There is a tendency for an unskilled designer to add in extra elements, falsely hoping that the user will be helped with having more choices. The extra elements, in fact, usually have the opposite effect.
Rather than help the user by providing all the features that might be needed, this type of approach just increases indecision. This is referred to as a paradox of choice.
When users only have two choices, they do fairly well at choosing the right one. As you provide them with more choices, the more mistakes users tend to make.
This is not a linear progression. It is exponential. The potential for making an error doubles with each new element that is introduced.
For example, you have probably seen UI’s that have OK, Save and Apply buttons. Most users are not able to distinguish between these subtle differences. (Part of this is due to the fact that developers also don’t seem to know the differences between them.)
A common behaviour that users do is to click all the buttons. Really, what should happen, is the “Save” and “Apply” buttons should be eliminated. The users’ entries should be automatically applied and saved by the system. The only choices needed by the user are Cancel and OK.
This common failure in design results from falsely assuming users really know what they’re doing.
I have conducted usability tests for more than 20 years. I can confidently say that a majority of users are not experts when it comes to using a specific UI. They frequently stumble across success through trial and error.
Have you ever thought to yourself, “I am not sure if I need to click this, but I am just going to try and see what happens?” Increased potential for errors is therefore a cost of adding on a new feature. Whenever a new feature is being considered, think about whether or not the feature is going to add enough value for it to justify the extra cost.
Another thing you need to consider is what features will have to be eliminated because the developers will need to burn extra cycles on this new feature you are wanting to add. For example, if there is only time for your team to add 10 features, if there is an 11th one you are considering, which of the first 10 will you have to sacrifice?
Many feature creep additions have been prevented over the years by this very question. This is not a flippant question. There could be situations when a new proposed feature might really be worth the expense of replacing one of the original prioritized ones.
There is a cost and benefit to every design element. Make sure you thoroughly understand both so that you can decide which are the best elements to go on the screen and which elements should be left off.
Use the task flow diagrams that were created during the phase of task analysis. Perform a walk-through of the screens to identify which elements do not directly apply to the specific task. Consider removing it, if it is not absolutely necessary.
Many designs commonly have more design elements than are required for users to complete tasks successfully.
The goal of your design should not be to create additional elements, rather it should be to eliminate those that are unnecessary.
Your design will be completed not when you have nothing further to add. Your design is completed when you have nothing left to eliminate.
For more information on data driven UI testing, check out this video: