Critical Path Newsletter

How to stop an endless debate about a UI design

We’ve all been there – what starts as a UI review meeting becomes an endless argument about where a button should be positioned, or whether the text should be two sizes larger or smaller. Everyone has an opinion, based on past experience, a book they’ve read, or simply personal preference.

How do you get past the arguing, make a decision, and get on with the project? We find that the following three simple rules will help you get past 90% of the design review roadblocks and get back to work. 

1. Be clear about the product’s value

First, ask yourself the following questions:

• "why would a user want to use this?"  
• "what would be their most common/value tasks"?  
• "under what conditions/context would the product be used?" 
• "who is it that would primarily use this product?"

If you don't have at least the beginnings of answers to these questions up front, before you start to design, then what is it that is directing the design of the product?  Reflect on these questions for a moment. They are much more than just a list of functionality.  In fact, one of the things they will help the design and development team do is prioritize functionality.

Taking just a bit of time to answer these questions up front, and to make sure everyone on the team knows the answers to these questions, will really speed things up. If you don't have these questions answered they will inevitably come up again and again in the design and development process.  Often we see teams debating whether to include a certain feature. What you’re really debating in this case is "who is our primary user and what would they value?".  If you considered this question earlier, the answer would be clear, and you’ll breeze through those discussions. 

2. Get User Feedback… Now

Clients new to user-centered design are often concerned that user feedback will slow down the development of a product.  The vast majority of the time, it saves a significant amount of time, because it allows teams to focus their efforts on creating or implementing the UI design rather than debating whether or not it is right.

While the process of getting feedback doesn’t slow down design, occasionally you will discover something is significantly, or fundamentally, wrong with the UI design, and this takes time to fix. But, it’s always better to discover a fundamental design flaw early, rather then after releasing the product when it hits the real world. 

I’ve been involved in UI design for almost 20 years, and one thing I see time and again is - no matter how smart or talented the people involved in the design and development of the product (and I've met a lot of smart and talented people) they inevitably miss something about how a user will behave with a certain part of the product design, and sometimes it’s a critical aspect of the design.

A common mistake is to iterate, and iterate, and iterate again using internal feedback to try and get it right. There is no substitute for feedback from real users. There are a number of techniques, from testing lo-fi paper protoypes to full usability tests, and any one of them will help you improve a design far more quickly and effectively than internal debate.

3. Attain Excellence not Perfection

We all know from school that attaining perfection, as opposed to attaining excellence, might not be worth the effort.  If getting from 98% to 100% takes twice as long, most of us will be happy with 98%.  In user experience design there's another reason beyond this to not try for perfection. 

Once you've hit the targets you set for the user experience design, and the overall UI design has been demonstrably shown to be excellent, trying to "fix up" small aspects of the UI design can actually undermine the whole design. One of the reasons we keep our UI designers involved all through development and right up to release if possible, is to ensure that the development team follows the overall direction set for the UI.  For instance, a developer may have an idea that makes a single screen better by changing a control, in search of the "perfect" screen. However, it may be inconsistent with the rest of the UI design and therefore it may actually set the design backwards.  We will talk about methods for managing this phenomena what we call "Design Drift" in upcoming critical path.

As you read the above you might have said to yourself "tell me something I don’t know".  However, we find most experienced product teams know these techniques in principle, but find its tough to put into practice with dicipline. We’re all human, and when it comes to design we love to debate and put in our two cents. This takes time - time that could be spent creating and delivering great design instead of debating it.