Typically, a user experience architect will be involved throughout the life of a project to ensure that the deliverables meet user needs within the constraints of the available technology, the brand, and any overarching business objectives.
Among the various artefacts that may be produced are:
Journey and navigation maps
User stories
Personas
Site maps and content audits
Wireframes and storyboards
Prototypes
Written specifications
Graphic mockups
However, the user experience architect’s watchword is ‘testing’, and above all, testing with real users. There is no substitute for testing with real users and the earlier the better - negative feedback received during the first phases of a project will only cost the price of the testing, whereas negative feedback on the live service will impact revenue, customer loyalty, and reputation. Thus, designing an exceptional user experience that properly balances the needs of the customer and the needs of the business requires thorough user research and constant testing and refining throughout the entire delivery process.
What makes a good user experience?
Apart from the general requirements for online products to exhibit a high level of technical availability, to be easily found on the web, and to be readily accessible to everyone, including people with disabilities, there are certain key principles involved in making sure that the goals, mental models, and requirements of users are met and that the product is efficient and easy to use.
The most important of these principles relate to clarity, simplicity of purpose, and speed of operation. The best online products are visually appealing, but at the same time download quickly and are easy to navigate and understand. Users will approach a product with certain goals in mind and if the design allows them to achieve these goals quickly and easily they will form a positive opinion of the product and of the people behind it. In particular, all online products should:
Focus on the core purpose and not distract users with unnecessary additional information.
Offer good information architecture that uses titles, headings, navigation trails and other signage to clearly signal to the users where they are, what they have done, and what they can do next.
Reduce the users ‘mental load’ (the mental effort the user must make to understand, and interact with a product) by showing important objects, items, and actions clearly and simply and using vocabulary and terms familiar to the user.
Use standard controls and established patterns to promote familiarity in the context of users’ expectations of how the Web works.
Ensure predictability by establishing visual cues and signals that alert users about what has happened, what they can do next, and what will happen when they do it.
Provide a consistent experience across the whole piece by always ensuring that like elements behave the same way and by displaying like elements and groups in the same place or zone on the screens.
Provide effective guidance to users to help them better understand the offering and the actions they need to take.
How is it done?
It is generally accepted that the UXD process has three phases – discovery, strategy, and design.
The aim of the discovery phase is to carry out detailed research up front to determine the key information that will drive the design strategy. Stakeholder interviews are conducted to crystallise the product vision and refine the core value proposition – asking such questions as: What defines success? What are the potential problems? Who are the users? What are their goals? What competition will the product face? At the same time, interview based usability tests and field studies are held to get an insight into how real people would interact with the product in their own environment.
The outputs from all this research are used to create personas and journey maps to illustrate the users’ path(s) through the product. If differences between the stakeholder vision and the users’ needs are identified, an alignment meeting is called to gain consensus on who and what the product is for. Ideally, this meeting should result in agreement on project objectives, design principles, and appropriate personas.
The strategy phase considers the big picture by means of ‘blue sky sessions’ and brainstorming, based on the (prioritised) personas and journey maps. It is important to stress that the object of these exercises is to generate a number of possible solutions - not to create concrete user interface designs. Once some possible solutions have been identified, these are storyboarded and validated with real users with the successful storyboards (which provide the ‘mental model’ for the interface) being used to create conceptual prototypes. At this stage the conceptual prototypes will simply take the form of drawings and mockups rather than working HTML. When a solid conceptual model is in place a high-level sitemap can be produced highlighting the screens that relate to the most important journeys.
As the term implies, the design phase involves prototyping, testing and refining designs. This is inevitably the most time consuming part of the process. Initially, wireframes and process flow diagrams are used to lay out the detail of individual pages and interactions before moving on to more collaborative design and development involving the development team. Bringing in the development team in this way both enables technical constraints to be identified early and provides additional capability for the production of more sophisticated HTML prototypes. And, once again, the wireframes and prototypes produced at this stage are tested with real users.
How many users are needed?
Testing with real users is vitally important to the success of any UXD project, but there is no doubt that testing with real users can be expensive and complex. Consequently, this cost is often cited in support of the argument that user tests are only viable on projects with a huge budget and generous time schedule. However, it has been shown that large scale usability tests can actually be a waste of resources with the best results coming from testing no more than five users and running as many small, reiterative tests as the budget will bear.
User-testing studies show that the first five testers will generally identify the majority of problems with any online product, and testing with additional users will not necessarily add more value to the results. Where several different target audiences are involved and representatives of each group are needed, additional testing with representatives of these groups may be necessary but it should still be possible to keep the overall numbers of participants down.
There are some other exceptions. Quantitative studies that are aimed at statistics rather than insights require at least 20 users, card sorting works best with at least 15 users, and eyetracking will require around 40 users to produce meaningful results. But, wherever the majority of user research is qualitative and aimed at collecting insights to drive the design, negative arguments based around cost and complexity should never be allowed to outweigh the considerable benefits of carrying out effective testing with real people.