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.

  • 2
    @Nir: Really like the "when there is nothing left to remove" it's an important point, very Toyota'ish too, and further points to how complex the issue of completeness is. Agree about measurable goals, issue is how do you know your goal are complete... :-) – blunders Oct 25 '10 at 11:41
  • 3
    @blunders - it's easy to know if your goals are complete - they are not - "No battle plan survives contact with the enemy", you list your goals for version 1 (and change them as needed according to what you discover during development and testing), when actual users get to touch your lovely application you incorporate their input into the list of goals for the next version. – Nir Oct 25 '10 at 13:07
  • @Nir: Very nice, so in other words the focus should be on a series of quick and decisive short user engagements to deliver a evolving solution. Makes sense, and I guess I knew this. Interesting how much conflict has in common with harmony... :-) – blunders Oct 25 '10 at 16:14
  • User engagements are a tool to evaluate goals. The focus should still be on your goals, but analyzing or testing your system against those goals with tools like user engagements (some goals, like reducing number of server calls, aren't necessarily best tested by watching users click). I would focus on understandable, discrete goals, the kind, as Nir says in the original post, you can measure against. – Matt Oct 26 '10 at 17:38
  • I love this quote by the author of The Little Prince, Antoine de Saint-Exupery..."A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." This really speaks to @Nir's philosophy. – milesmeow Oct 28 '10 at 4:21

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?

  • A wheel for steering
  • Gas/break pedals (and hand break)
  • Gear transition (automatic or shift)
  • Lights, whippers, etc.

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).

  • 1
    @Dan: Like the vehicle examples, nice. How do you know when your scenarios address the majority of user requirements? – blunders Oct 25 '10 at 11:44
  • I think the "order of things" should be as follows: research or interview enough users until you feel the requirements repeat and you cease to be surprised. Now add your own vision, constraints, etc. and define which of the requirements you aim to fulfill. When you have a mockup/prototype start doing usability tests to determine if those requirements are met, i.e. that users that want to accomplish the relevant scenarios do so with ease. – Dan Barak Oct 26 '10 at 12:54

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.

  • Totally agree (see comment above). The ability to change in an instant is hugely powerful in the web market. – cottsak Oct 28 '10 at 7:00

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.

  • @Kevin G: +1 There's a reason user interfaces are not designed by users, and to that end, why I also believe that users are not in the position to know when a interface is done... :-) ...still, I do agree that it's very, very important to be focused on supporting the user, it's just that sometimes that means not listening to them. Guess you're saying that too, but your lead statement of "when the user says it is" may conflict with that. – blunders Nov 4 '10 at 3:09
  • 1
    @blunders Ha! I guess you are right. I just wanted to stress that user interaction should always be the driving force behind interface design. I suppose I could revise my statement to "a interface is complete when everything works exactly as a user would expect it would." – Kevin G Nov 4 '10 at 4:03
  • +1 Glad to hear I understood you, and thanks for replying! – blunders Nov 4 '10 at 11:00

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.

Your Answer

