Are the test participants able to complete the task scenarios successfully? Do the test participants understand the various test scenarios ? If they are not able to understand or frequently ask for directions or seem confused, it implies that there are problems that need to be addressed.

Do participants perform well enough to meet the usability objectives? Supposing the participants are able to move ahead in the flow, the next question is about their performance in the study. Their level of completion, the amount of assistance they required, whether they moved in the workflow the same way that the designers intended, all these are queries that need to be assessed.

How satisfied are participants with the site or application? It is very important to gauge the level of satisfaction of the users with the site / application. Preparing a series of questions during and after the study will allow determination of the satisfaction levels of the users with the overall site / application, as well as individual elements.

What changes are needed to make sure that the site / application will enable more users to perform more successfully? A usability study is an excellent time to find out which is the more user-friendly route for users. In fact, it is very much possible that during the course of a usability study, designs could be reworked in an iterative way to find the one that seems to be the most user-friendly.

Verification of user analysis data: Designs in a lot of cases have been made on the basis of previous user analysis data. Typically, such analysis leads to a lot of data about the workflows that users seem to prefer; however, it is also known that in many cases, users state something based on questions – but these can get modified when they actually see this in operation (also known as ‘users finally get to know what they want when they see it’). Hence, usability studies are a good way of finally verifying the user analysis data.

Validate design guidelines: The usability testing also helps to confirm the various design guidelines that have been established for the project. These guidelines serve to set the basis of the user workflows. An example of some of these are:
* Make links predictable: Links should have the same type of UI and should work in the same way
* Make screens as simple as possible — first screen should have only the most frequently used functions and secondary screens should have optional interactions
* Use graphics minimally — only when necessary, and make graphics meaningful, to indicate where a link goes or what page it deals with; and
* Make the page easy to scan — most people scan the page, picking out individual words or sentences and do not read word-by-word
Now these are general guidelines and may not be applicable for all cases.

Testing allows designers to settle disagreements and differences: Different designers in a team could have multiple opinions and getting usability tests determines which is the one most likely to work. This happens without hurting egos if decisions are made on the basis of user study.

Usability tests can help you understand how real users will use your product, and how the interface could be improved accordingly: Teams developing the product / site can have blinkered visions; getting target segment users brings you close to reality.

Results of testing give the designer ammunition to use in responding to outside attempts to change design based on whims or personal bias: Higher management or experts can have their own opinions and may want a workflow to happen in a certain way, and getting usability results helps defeat such attempts if they are based on personal whims.

Testing saves time and money. Rubin notes that “doing usability testing through the development project allows you to make user-centered changes as you go, before you have so much time and money invested in the project that it makes it difficult to make changes.

Testing is good public relations: It sends a message that the team/company is interested in what the user thinks and needs and can be used very easily for good coverage and to show that the company has done a best effort.

Testing allows the designer to cast a broad net: It helps ensure that the design is good for all users, not just those users who think like you do. Getting a cross section that is diverse is much easier if you are doing a bigger usability study.

In summary, the process can work like this – With the iterative approach, a site prototype can be created, viewed, and evaluated by a small subset of users who identify problems and suggest changes. Once immediate problems are corrected and suggestions are implemented, the site is released to a larger audience, who become part of the design and quality control team by using and evaluating the resources and sharing their feedback with the developers. Usability testing methods, by their very nature, keep the user in the forefront. User testing helped us, the designers, distance ourselves from the product. Rather than focusing on what we thought/liked/needed, we could focus on what the user thinks/likes/needs. What users say they need and want is often substantially disconnected from what they actually need and want when faced with using a product to perform a task. It is for these reasons that the only way to effectively determine what is best for users is to observe users performing tasks with the product of interest.

1. A fundamental difference between the way interaction and information experts diverge instead of collaborating. In the case of the company, the interface designer worked in a silo, instead of spending a lot of time with the information workflow expert. While usability is obviously important, it’s far from the only consideration in designing a user experience. There are at least three aspects to sites: information, experience, and interaction – fact (or fiction), form, and function, if you will. User interface gurus tend to focus only on interaction, and the information architecture gurus tend to focus on information – and each tends to overlook the other two areas.

2. No single magic bullet to interface design. Expert literature offers many principles of good interface design, providing helpful guidelines for designers. However, even if every designer in a software development organization was well versed in these design principles, this would not be enough to ensure good interface design. Many of the available design principles are based on experts’ intuitions, rather than on hard data. What may work in one situation would not work in another, and it is for the interface designer to try out the ones that seem most suitable, and then test them out as to their individual benefits. Usually for any given design problem, they will come in direct conflict with each other, and there are no algorithms for making the trade-offs.

3. User interface design is a matter of compromise and tradeoff, for example, there i the need for powerful functionality, but within a simple, clear interface (seems a paradox in most cases). We want ease of use but also ease of learning. We want a system that is flexible but also one that provides good error handling. We strive for consistency across all aspects of the interface, but also to optimize individual operations. The interface designer finds him or herself constantly confronted with these kinds of conflicting goals, and with the expectation that the designer will be able to resolve all of them brilliantly. Well, sometimes these are not resolved.

4. Design by committee: In many cases, maybe to speed things up, or because influential stakeholders feel that they have the pulse of the customer, they get involved in the interface design process. Or many representatives from the team join in. In such cases, the interface designer has to take along all these people, and compromise; sometimes weakening the design.

5. In many many cases, designers operate in a vacuum, with little prior experience and no interaction with potential users to guide them. At best the interface designers are experienced and have learned from feedback from users of earlier systems. Even so, the technology changes so quickly that even experienced designers constantly confront new design possibilities they have no prior experience with, or have to work with changes technical possibilities that they are really not aware about.

6. Taking the interface designer’s work as gospel: The interface designer is not god. Even though the work looks good, it is always good to get the work evaluated by users in the form of usability testing.

7. Inexperienced designers: Just because a person is an interface designer does not automatically mean a high degree of skill in all areas. For example, if a web designer skilled in commercial web sites was asked to develop the interface for a web applet version of a media player, one can be sure that it will take some time to develop the necessary domain experience to be able to judge customer flows.

Poor user interface design can hide even the most powerful and useful Web sites or well engineered products from all but the most advanced and patient users. Developers have to consider seriously the issues of user interface implementation. A poor user interface will mean low usage of the site and its ultimate failure.

An Overview of the Design Process
All application design methodologies break the development process down into discrete phases. Below are some typical phases.

Requirements Phase: Determine the requirements for the application by interacting with users. Can be further divided into funtionality requirements gathering and user analysis:
* Functionality requirements gathering – assembling a list of the functionality required of the system to accomplish the goals of the project and the potential needs of the users.
* User analysis – analysis of the potential users of the system either through discussion with people who work with the users and/or the potential users themselves. This phase can take some good amount of time to achieve, but is very important for later success of the User Interface. Typical questions involve:
o What would the user want the system to do?
o How would the system fit in with the user’s normal workflow or daily activities?
o How technically savvy is the user and what similar systems does the user already use?
o What interface look & feel styles appeal to the user?

Conceptual Design Phase: Model the underlying business that the application will support. The objective is to model the business irrespective of any implementation issues. This phase also involves working on the information architecture – development of the process and/or information flow of the system (i.e. for web sites this would be a site flow that shows the hierarchy of the pages).

Logical Design: Design in general terms how the application will operate. This includes the prototyping of the interface. Prototyping means the development of wireframes, either in the form of paper prototypes or simple interactive screens. These prototypes are stripped of all look & feel elements and most content in order to concentrate on the interface.

Physical Design: Design in specific terms how the application will be constructed, and this includes incorporating the platform on which the application is supposed to work. From this stage, it is possible to figure out whether some aspects of the logical design are actually possible or not.

Construction: Construct the application. It is during this phase that users actually get their hands on what the application would actually work like, and it is quite possible that at this point, they would prefer certain changes.

Usability Testing: Test the usability of the user interface; or in more detail, testing of the prototypes on an actual user — often using a technique called talk aloud protocol where you ask the user to talk about their thoughts during the experience of using the application.

Graphic Interface design – actual look & feel design of the final graphical user interface (GUI.) It may be based on the findings developed during the usability testing if usability is unpredictable, or based on communication objectives and styles that would appeal to the user. In rare cases, the graphics may drive the prototyping, depending on the importance of visual form versus function. If the interface requires multiple skins, there may be multiple interface designs for one control panel, functional feature or widget. This phase is often a collaborative effort between a graphic designer and a user interface designer, or handled by one who is proficient in both disciplines.