Why you should convince users that « less is more »

« Less is more »

Adopted by the architect Ludwig Mies van der Rohe as a precept for minimalist design

1. Reality: Cluttered software are underused. Complex pieces of software do not help anyone and tend to be ditched faster than any others. Clients want powerful but easy-to-use tools, they want stuff that just works and make their life easier. They don’t have time (or don’t want) to learn therefore you should ensure they don’t need to be educated.
2. Focus: We use software to edit text, keep track of inventory, or manage group calendar, no matter what the reason is system should always let you accomplish your task quickly and efficiently. No more, no less.
3. Clarity: We all expect tools to provide the right information for a given situation. No need to fill up screen with information or details user might eventually need. Go easy on the eyes, the more information the more you solicit eyes. It causes distraction and slows down the user. Think about process, in & out in a logical sequence of events, then off to the next action. It is also proven that users feel more « secure » or at least in their comfort zone when design is spaced out, they feel relaxed. This might not be important for you but think about the support team who will need to answer the same question over & over.
4. Cost: Each feature has a cost; development, testing, documentation, support, marketing, sales… When feature evolves, then its associated cost goes up and and you better make sure you stay consistent.
5. Interaction: Users expect steps to flow in a certain way, they need to know where to start and when it ends. Thus, you should limit the number of steps to reduce abandonment but keep reassuring users along the way (you’re almost there). Needless to say, when interaction involves too many thinking for the user or too much time, there is likely a better/simpler/faster approach to solve problem.
6. Finally, the less code you have to maintain the better it is so we strongly recommend you question yourself about the impact before starting implementing: Is this required? Is this vital for users? What is the value? Is this the best way to accomplish that action (as opposed to refactoring)?

That being said, there is time where you don’t have any other options, and that’s perfectly fine but at least you made sure to define what it takes first to avoid complications down the road.