User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Meaning that a usability test measures if an interface meets the goals it sets, but only test what is present. How do I know when an interface is complete? Meaning a test, or measure of completeness, fitness, etc.
NOTE: If you can't think of an answer, please at least post an answer of a complete interface component, and why it's complete based on your experience.
If you have questions, just ask -- thanks!
The minimalists would say "when there is nothing left to remove" :-)
Ok, Now seriously, an interface is complete when is satisfies all the goals you set for it - so if you don't have measurable goals you can't measure completeness - after all you can't measure fitness without knowing what you are supposed to fit to.
A good example of goals would be: "enable the user to do X, Y and Z in less than 1 minute with a 90% success rate", than all that's left is to get users to sit in front of the computer and ask them to do X, Y and Z if more than 90% are able to perform all tasks in less than a minute you are done.
Another good examples are "increase conversion rate by 50%" or "reduce customer abandonment by 10%" etc.
A bad example is "increase conversion rate", in this example you can never declare the interface complete - there will always be more options to test and tiny improvements to perform.
I think "complete" is a problematic definition, but I think I know what you're aiming for (see my definition on the bottom).
Let's open with an easy example - looking at cars, what's a complete user interface?
How about a radio/CD player? Is the car interface incomplete without it?
Strictly speaking - no! It's not a vital functionality for driving, but still most people would never consider having a car without a radio (unless it's a racing car, for example).
What about a cold drink fridge?
Most people would not think a car would normally have one... but what if the car is in fact a limo? Then without a fridge it wouldn't really be a limo now, would it?!
My point - "complete" refers to the needs and expectations of your target users.
So one of the key things you should do is approach your potential users and ask them:
"Hey, I've created a project-management/accounting/design/CRM/etc. application, what would you want it to enable you to do? What are the key features in your eyes? If it lacks ____ would you still consider it?"
One you have all the scenarios and features implemented, you do your regular usability testing to see if the users can accomplish all the things you've implemented for them (based on their requests and expectations).
An interface is a journey, not a destination ; )
Seriously though, is an interface every really finished? If you can make it better, without casusing the user to become disoriented, then make it better. Look at Google's home page, it has been undergoing constant minor tweaks since day one.
Sometimes improvements don't become obvious (to the user or designer) until the system has been in use for a while. Or users expectations and requirements may evolve over time.
So ever thinking that your interface is 'finished' is short-changing your users.
An interface is complete when the user says it is.
I believe that many of the answers where bouncing around this, but none hit it on the head. Yes, your goals are important, but more important is how the people actually using your program like it. You have to do consistent usability testing in order to produce a complete interface. Period. If you don't get user behavioral info, then you are designing a product based on your assumptions. Facts are always better. Don't listen to what they want; look at what they do in the environment they use your product. Only then will you see what needs improvement. Remember that your product has to conform to their expectations. People don't like to learn new processes, so don't try to force them.
I like the car example, but you also have to know your audience. Different people require different needs; elderly need more visual assistance, for instance. Basically, when your users say that everything works exactly as they would have expected, then you are done.
I agree with @David. Usability testing and design reviews are all nice. But you really have to "live with" a design for a while and see how it performs with real data. Long names, use cases that leave you wondering who would ever use it THAT WAY?
Improvement is continuous and on-going. Needs change. Features that seemed central and important fall by the wayside. Users fail (en masse) to pick up on what seem like the most obvious differences. Yes, you can (and should) ferret out some of these by testing. But not always.
