Bad design practices – Overdesigning

By Lynn Miller

This is the first in a series of blogs on bad design practices. I’m going to tackle overdesigning first since it very common, especially for new designers.

Overdesign is putting in too much functionality and too many options. This leads to the extra bits getting in the way of the most needed functionality, making it harder for the end users to learn and use the software.

Overdesign is sneaky in that it uses the designer’s enthusiasm for doing the right thing to weaken the overall design. In design, more is not always better.

vs

Overdesign not only complicates the user experience, but it also complicates the code, makes it harder for quality assurance testers (QA) to do their job and creates more documentation. Overdesign can also be a significant waste of a designer’s time if the design has to be cut back due to a lack of development time to complete the whole thing.

There are many contributors to overdesign. One common problem is when the designer does not understand the difference between something that could possibly be useful vs something that would probably be useful. If something is probably useful then it is almost certain that the majority of people want it and will use it. If something is possibly useful then you can think up a case where someone might need it. If you are adding possibly useful cases to your design then you are overdesigning.

A designer can think up a lot of cases that could possibly be useful. Other designers who review your design are also usually great at adding use cases and suggesting functionality. But smart designers make sure they only add in elements that are sure to be useful for most people. The only way to know the difference is to really understand your users and their workflows by doing research up front.

Another contribution to overdesign is pressure to support workflows that are common for in-house users on the development team. Developers, QA, and the designers themselves may have to frequently repeat certain actions that an end-user would not need. Or they may have a certain favorite workflow that they want supported that is not used in real production. Resist the temptation to expose these to the end-user.

The last contributor to overdesign that I want to talk about stems from Waterfall Development practices. If a designer has to completely finish the design before implementation has started and are not allowed to modify it after that point, then the tendency is to create designs that try to guess every possible usage situation. Once trained in this type of thinking, well-meaning designers can continue to overdesign even if they are moved onto Agile Development.

The solution to this, if you are on an Agile project, is to modify your design practices to fit with the agile iterations. Start with the most important user capabilities first and incrementally add complete but small piece of functionality until you pass the acceptance criteria. Then stop.

Are you guilty of overdesign?

Comments

[Pierre-Felix Breton]

somewhat in a different field, but i think its related to this article...

http://blog.buildllc.com/2012/05/the-secrets-of-modernism/

they basically say: keep things simple and aligned visually.... worth a read.

[Designing the User Experience at Autodesk team]

Great catch Tom. Thanks for the eagle-eye. The error has been corrected.

-DUX Editorial Board

[Tom Spine]

Hi, Lynn! Great post.

But shouldn't the sentence where you wrote "If you are adding probably useful cases to your design then you are overdesigning." really say "If you are adding *possibly* useful cases to your design then you are overdesigning."? Looks like you did a probably/possibly typo that slipped through editing and reviews!

[Pierre-Felix Breton]

“Perfection is achieved perfection not when there is nothing left to add, but when there is nothing left to take away”

– Antoine de Saint-Exupery