It can be argued that a throrough understanding of programming is needed to produce a good web application, and yet, from the point of view of the ultimate critics, the users of the
software themselves, one point remains vital: Does the application perform as I expect it too?
User Interface design concerns itself with the experience and the way in which a user interacts with a product - in this case with the software which may reside within a web page. UI
design works when the software produces the expected results, and does so in an intuitive manner. One of the reasons that so many UI devices look similar, or adopt the same user control
and layout, is because people have become used to interacting with software via a common mode of operation, or through the same mental model.
When a program does something unexpected as a result of human interaction, it can leave the user feeling uncomfortable and helpless if they cannot immediately rectify the situation.
A good example of this would be when a user enters credit card details to purchase something online, only to find that the form has failed to submit properly to the web server without
displaying any meaningful error messages. Will the user receive the product? Has money been subtracted from their account? How do they go back and find out what went wrong?
Just as a good website design will not draw attention to the way in which it directs a user through the various pages of a website, a well-designed UI will not draw attention to itself.
When the UI design is modelled to match the user's expectation, the user will probably not notice the ease with which they were able to engage with the system. A number of different
steps are needed to achieve this effect.
Understanding exactly what is expected of the system is one of the most obvious requirements. Specifics and clear distinctions are very important. It takes a lot longer to change
software than it does in seeking clarification of the functionality in the first place. Having said that, user requirements often change during the development process. The more clarifications
that can be made during the stage of gathering user requirements, the easier it will be in understanding what is required for development, as well as potentially avoiding some re-working
during the development phase.
It is often necessary for the developer, or BI consultant, to pinpoint user requirements from a client who is not as interested in outlining the system, as much as they are interested in
settling on a cost and a completion date. In these instances it is crucial to draw out the requirements carefully. It may be that the client does not really know exactly what they want. Some
clients will only show interest in the work at, or after, prototyping has occurred where they suddenly explain that what they required of the software is something quite different from what
has been prototyped!
It is really important that the development team come to grips with how the client business operates, the goals of the business, and the way the system will integrate within the business
workflow. The use of questionnaires and direct interviewing techniques are not uncommon when gathering user requirements. If no users are available, it may be necessary to imagine what
they would be like, and to build the prototype with their imaginary characteristics in mind. The ability to clarify precise user requirements cannot be overlooked and will save development
time and also show the client that the project is regarded as important enough to invest time gathering requirements in order to produce a quality product.
Once a clear conception of the requirements have been agreed upon, the look and feel of the UI can be addressed. Things to consider at this phase are the level of techincal ability of the
users, as well as the software they may already be using. To reiterate; it is crucial to try to match the model of system behaviour to the user's mental model of how they expect to interact
with the software. It is worthwhile avoiding unnecessarily stylish UI design that may confuse users who are used to a different pattern of behaviour from their current software.
Consider the fact that every time a program presents a set of options to the user, it is asking the user to make another decision. If the user is not interested in the choice presented to
them, or if the choice really has no essential bearing upon the process, it would be a lot wiser to eradicate it from the program.
Presenting the user with a wealth of advice or help options at each step of the process will not justify a cluttered UI design. Users are not interested in reading manuals or help pages, as
much as they are concerned with stepping through the program as quickly as possible. Their interest is not with the system itself, but rather the result of using the system. If they hardly
noticed that they have used the program, it will probably be a sign of a good UI design.
Elaborate or confusing confirmation popups should be avoided. When user confirmation or instructions are required, they should be succint so that the user need only scan the UI
quickly to understand what is required from them before proceeding. Improrper grammar is quite acceptable if it naturally infers a clear meaning and saves the user some reading time.
The user will certainly appreciate the program respecting their time in making it easier for them to operate the system. Presenting the user with two options labelled
"Exit program" or "Continue", is a lot better than developing a popup window that says "You have opted to exit the program even though you have not completed the current form.
Are you sure you don't want to continue and would rather exit the program?" If the two buttons below are marked "Yes" and "No", which one should be clicked on to leave? Not only
is the long-winded explanation of the user's action unnecessary, it can often leave the user baffled and frustrated as to what is required of them to complete the operation.
A prototype design is useful for user feedback and also gives the client a sense of progress. It can be quite exciting for both developers as well as the client to see their ideas and work
start to materialise in the form of a simple prototype. A prototype need not be complete in either its look and feel nor its functionality. It should aim to mimic the interface of the
primary process, or processes of the system so that users can try it out and offer their feedback. The first prototype is rarely going to turn into the finished product.
Once a prototype has been accepted, the system must be developed with a consistent UI. Icons and imagery apparent in the interface should instil an intuitive approach to the use of
the system. Refining the UI design and testing will follow and make up the bulk of work until the system is finally approved.
The time spent in developing a user-friendly UI that meets the requirements of the client holds an important role in web application development. A poorly developed UI will only
frustrate and scare off the user, whilst a well-developed UI will encourage the use of the web application and will be reflected in the acceptance and satisfaction in the software by the client.