Consult with users on everything!

 Introduction

Those intermediaries who plan the functionality of a site or application - systems analysts, consultants & specialists, managers, etc. - indirectly represent the user. However, they are not the user.

The user needs to be the final judge of what is understandable and easy to use.

 Things that must be checked with user

Structure & navigation: How users find things is one of the most critical areas of the design, affecting productivity and usability. Navigation and the grouping of topics, tasks, etc. need to relate in the same way as the user views those relationships.

Terminology: What we call things, including navigation hyperlinks, can be a source of confusion. All departmental, jargonistic and specialist terms need to be checked with users, to verify their understanding of the terminology is as intended.

Process flows: No matter how thorough requirements gathering is, in establishing what a process needs to achieve, a separate effort is required to validate exactly how the user wants to execute that process.

Brief users early in the project on how processes will be executed, using simple diagrams or storyboards, to check the process matches, for example, the order in which the user gets the information for that process. Use the output of these briefings to iterate the design before it is coded by programmers.

Icons and graphics: Clever though the use of graphics may be, the visual design must be checked with users. Key here is to not simply ask users 'what they think' of the design, but to test that the functionality of the site is not compromised by a cluttered or overly graphical design.

In particular, the meaning of icons must to be checked with users, particularly where they are to be relied upon in the navigation structure.

When & how to consult: Decisions that have some impact on the user are made at every stage of the project; during requirements gathering, design, and development phases. We therefore need to consult with users at every stage.

During requirements gathering, we can brief user groups on functionality.

During design & interface design we can brief users with presentations or a prototype.

During development we user-test using the live site or application.

Users don't have the time: Bottom line: Users need to make the time.

During the planning phase, brief stakeholders that access to users is required.

If they want a usable solution, they need to give the time.