Trying to design an interface is nothing short of agonizing at times when we are dealing with users and their needs (or more to the point, requests). Most of us can relate to how hard it can be to get coherent requirements for an application.

It is often equally challenging to solidify the design of a user interface and get buy-in from all stakeholders. There is usually someone who is responsible for seeing that business objectives are met. Then there is someone responsible for deciding technical feasibility and another that is responsible for scheduling and budgeting. And of course there should be someone representing the users. If software is being developed for internal use, then a representative from the users’ area or department will fill that role. If the software is being developed for outside customers a representative from marketing or sales is often appointed to act on the users’ behalf.

In either case this often presents problems that give most developers nausea. Unfortunately, anyone responsible for the design of an interface must deal with this directly because this person is likely the most important person with which to have a good rapport. These user representatives tend to get heavily involved with the user interface design. If you do not make friends with this person you will dread every meeting with this person - and there are plenty of meetings in this process. User reps can be a great source of information and input on design considerations. Depending on a designer’s level of understanding of the business domain, a user rep will often know of previous failed design attempts and of successful scenarios. Listen to them and learn from them. We should never assume we know more than these valuable resources.

An understanding of good user interface design eludes most people. And most couldn’t tell a good design if it hit them. The one true test, however, of quality is in the users’ feedback. It is important that we designers use this to our advantage. Using the iterative design and testing techniques that we talk about later will allow us to quickly prevent bad designs being realized late in the development and also help provide fuel for your design goals even when strong opinions would like to maintain otherwise. A word of caution that we all want to remember is that it will happen more than once when user feedback proves the user rep correct and the designer wrong. It is ok to be wrong but I hear crow is rather distasteful.

Tags: agile, design, feedback, ui, usability