I have seen a lot written on observation as a tool for Business Analysts to elicit business processes. These articles are based on the description in the BABOK. This description recommends determining ahead of time what data is needed, and then observe to get that data. In particular, observation is suggested to determine an as-is business process. But that is a very limited understanding of what observation is and how it can be used.
Observation as a tool is used to understand people and their environments. It is a tool best used not in situations where we are verifying fairly well-understood information, but rather in situations where we do not really know what we are looking for. Observation is not about validating assumptions, but rather is a tool to find out what we don’t know that we don’t know. Observation should bring out the surprising and the unexpected. Of course observation has a purpose. But the purpose can be fairly broad.
Observing the Environment or Culture
Sometimes it is important that we understand the environment and culture in which the people work.
- It is loud or quiet, hot or cold?
- Is there a lot of talk and interaction or are people sitting alone with headsets on?
- Are there personal pictures on the desks?
- Are there toys in the area or a snack table?
- Are there community spaces and casual meeting areas?
These kinds of things can give us clues when creating solutions for these users in this environment.
One team creating a print management system thought they would use a chime to indicate the end of the job. Until they visited the print shop. It was one big open room with machines running all the time and was very noisy. The print management system was going to be used in that same room, so it was now obvious to the team that a chime would not work. They had to find a different solution.
Another team was creating an app for Marines to use on field computers to communicate with base. A brief time out in the field showed that this app would be used in all weather conditions, in situations calm and tense. But the most important thing turned out to be upload speed because the Marines were constantly moving and could not stop for several minutes to wait to upload data. Also because they were constantly moving, if the upload took too long the signal dropped. And so the key requirements were not actually weather related but rather were the upload speed and the size of the data packets.
Observing Human Interactions Facilitated by the Software
Sometimes it is important that we understand the interactions between the users of our systems and people they are serving as they use our applications.
- Is the user under pressure from their customer to finish quickly or is the pace more leisurely?
- Should the customer be able to see the user’s screen or the device they are using or is it important that they do not?
- How can our solution help our user better interact with their customer?
One team working with a county records office found that the work environment was very stressful all day. So the solution itself could not add to that stress. It must also make it hard for the user to make mistakes, because user mistakes made their customers angry. The team worked hard to create something very intuitive that was also lovely to look at to help reduce the stress of interactions between the public and the county clerks.
Another team working with technicians creating ultrasounds for pregnant women discovered through observation that the women all wanted copies of the ultrasounds because they were pictures of the baby. And so the team built in a feature to print out a paper copy so the technician would not have to find a copy machine to make the copy.
Observing for Unexpressed Needs
Sometimes we are observing in a very open-minded way to get ideas for what might be useful for a population of people. Often this is done as a participant observer, where the observer is himself a member of the community being observed. So while he is working out at the gym, he might observe other people using gym equipment to see if there are problems that can be solved or needs that can be filled. Or perhaps the personal trainer mentions a wish for an app that will do X for her. Often people just accept what is and do not think about how their work, hobbies, or play could be better. In these more open-ended observations we are not observing what is there, but observing to find out what is missing.
One team went to observe some customer service representatives just to practice doing observations. They noticed many people had taped notes to the sides of their monitors. They asked what the notes were for and discovered that about 10% of the time the current system did not handle what the customer service representative needed to do to solve the problem. So as they discovered workarounds, they wrote up notes and shared them with each other. The customer service representatives did not think to ask for these features to be added to the system, and since things were basically working fine, no one thought to ask them how things could be better.
Observing for Causes of Error
My last example of the use of observation is to find out where the design of the software/application/website/product is itself causing people to make mistakes. Often relatively small changes can make the difference between a solution where people often make mistakes to one where the users seldom make mistakes.
A team I worked with watched users of a complex new software application to see how they used it. The users were given specific tasks to accomplish, but not told how to do them. The observers watched to see where the users experienced problems doing the tasks, then asked questions about what was confusing. They also asked the users how they thought the task should be done. With that information, the team was able to re-design the system to greatly reduce human error. They repeated the observations a number of times during this multi-year project, and the resulting software was quite superior to anything similar on the market.
Observations can be used for a number of purposes. We should not limit ourselves to just doing observation of business processes to verify information we have obtained elsewhere, but should use observation whenever we need more information about the physical environment, culture, unexpressed needs, or to reduce causes of error.
Author: Geri Schneider Winters discovered the power of Solution Anthropology seven years ago and has been a fervent devotee ever since. Frustrated with widespread poor user experience, winters is advocating for Business Analysts to bring users (not customers) to the forefront of product development. For more information:
http://www.solutionanthropology.org. Join our LinkedIn Group:
https://www.linkedin.com/groups/Solution-Anthropology-8240840