Site visits are a valuable method for creating user-friendly interfaces. Misconceptions and prejudices, however, can prevent the approach from being used, which ultimately leads to solutions that don’t offer a great user experience. This article aims at eliminating a central misconception and at providing an overview of site visits and their goals.
A Central Misconception
One central misconceptions regarding site visits can be summarized with the statement: “We can simply ask users what they think about the current system”. Behind this statement there is the idea that
- a current system is the main interest of inquiry
- site visits are mainly about interviewing users
Neither point need be the case for site visits.
Focus of Site Visits
Site visits do not have the main purpose of learning about a current system. Their purpose is rather getting to know the context in which a to-be-designed system shall be used. “Context” in this case refers to, amongst other things, users and the goals they try to achieve as well as the physical environment in which the system is going to be used. This is very important because system development usually just can control the system itself while the context of use has to be taken more or less as it is. If one regards UX Design as a “jigsaw puzzle”, the interactive system is the last “missing piece” that can only be properly chosen when the rest of the puzzle is known in detail so that it fits right in.It is therefore important to learn about that context in detail. In order to choose user-friendly screen colors and system sounds one has to learn about lighting and noise conditions in the context of use. If such decisions are based on mere assumptions, there’s a risk of ending up with a user interface that seems to be user-friendly, but that does in fact fail to meet users’ actual requirements. A particular – and common – challenge arises when there is already an existing system in place during a site visit. (Often in projects that aim at optimizing said system.) In these cases, it can be hard distinguishing “pure” contextual factors from those that are heavily influenced or “skewed” by the existing implementation of the system. It’s not unusual for users to quietly “surrender” to a system and adapt their workflows to the given constraints when in fact they could work much more efficiently and satisfyingly with a better solution. The fact that there are (almost) no complaints about a system does therefore not guarantee that the system is perfect. In the worst case, a system is “optimized” over and over again for the seemingly “ideal workflow”, when in fact that workflow is simply forced upon users by the implementation. In that case, every system update can further force users to adapt to a suboptimal workflow.
Users’ actual goals and workflows must therefore be known as well in order to create a tool (the future system) that supports users as well as possible without forcing users to adapt to the system. In the end, any productive interactive system is merely a means for reaching user goals and never and end in itself. Therefore, the system should match the existing context as closely as possible.
This means in particular that site visits can also be conducted when there is no current system to be investigated. This can, e.g., be the case in innovation projects. Only when the project team has detailed knowledge about the context of the future system can the “missing piece” – the system – be created in order to provide users with a solution that suits their (work) context with an optimal user experience.
One aspect that can be surprising during site visits is the extent to which users rely on paper to get their work done, e.g. quick notes that are jotted down on a writing pad to temporarily decrease memory load or sticky notes on the edge of the screen for accessing information of long-term relevance. When such aspects are unknown and the focus lies only on workflows in an “ideal world” (with perfect user memory) that don’t rely on external tools and helpers, potential for creating a truly innovative system that truly support a wide variety of actual user workflows can largely go unused.
More Than Interviews
Interviews are a part of site visits, but usually not the major part. At their core, site visits are observations in the real context, e.g. in an open-plan office in which a future system is to be used. In these open-plan offices, users sometimes wear headphones to listen to music or to have noise cancellation in order to limit distractions. In those cases, acoustic feedback is largely useless, which is highly relevant information for user interface design projects.
Through observations, the project team can gain detailed knowledge about the real world, which could not be achieved with interviews alone. Only by “diving into” the actual context do details about users, goals, tasks, surroundings etc. and their interdependencies become clear. – Information which users would not simply and to the same extent communicate in interviews. This does not mean that users are mean-spirited. It’s because users are not consciously aware (anymore) of certain relevant aspects, e.g. when it comes to workflows that are highly trained and more or less “automatic” or “routine” without any need to allocate a lot of attention to them. In addition, there are certain factors that are judged as irrelevant by users and therefore not communicated during interviews. For the design team on the other hand, seemingly “unimportant” details can be highly relevant when it comes to creating innovative and user-friendly solutions. Therefore, the design team should maximize their knowledge about context to create a knowledge base that is appropriate for designing an optimal user experience. To that end, no method can replace “diving into” the actual context of the (future) interactive system with site visits. Only then do the manifold and partly subtle facets of the usage context become clear and provide starting points for creating solutions that surprise and delight users.
Often, users are not consciously aware of how frequently they stop working on a given task, e.g, when they are interrupted by colleagues, when the phone rings or when they quickly have to work on a short task of high importance. This, of course, affects concentration and memory, but in interviews these aspects are often simply not mentioned by users because they, unconsciously, regard them as exception from the rule when in fact they are the rule that governs the workflow. Therefore, a lot of potential can be lost when the system in question is not optimized for users suspending and resuming workflows at will, e.g. via “bookmarks”, automatic saving of work states etc.
Conclusion
Site visits are one of the most valuable user research tools when it comes to gaining detailed knowledge about the context in which a future system is to be used. Sometimes, however, there are misconceptions that keep a team from doing site visits. It is therefore important to understand that site visits are not mainly interviews and that they can also – and in particular – be used when there is no existing interactive system. Especially when there is a desire for innovative solutions with an optimal fit for the world of users, there is no way around doing solidly planned site visits.