By Aaron Heskes
Secondary research is good. In fact, published research is scientific, comprehensive and reliable. However, the value of the design process is in its application to unique environments and unusual situations. Almost anyone might be willing to give their opinion on a product or service, but a designer can’t operate on opinions of what “should” be changed. User opinions are valuable if only as an indicator of the general proximity of a pain-point.
Within any product system, there are always weaker areas where an unusual burden is put on a group of users. This could be a passive end user such as a doctor who enters data into a health record, or non-user participants, like her patients, who must wait longer because she has difficulty entering the data efficiently.
In a case like this, our survey of the patients in the waiting room would probably return complaints of long wait times. The challenge at this point is to look for the causes of those wait times. Discovering the root problems by mapping out what each person is responsible for and who they interact with is the primary goal. I’ve already identified the root problem in this hypothetical situation, but if we were to attack a problem like this in reality, it would take much longer to even discover the data entry problem.
It’s important to emphasize the value in viewing a product system as an interconnected entity. Picture a dreamcatcher; It has a circular perimeter to hold its shape, and a web on the inside linking all areas of the perimeter. The circular perimeter is representative of a user’s workflow, broken down into each step which is necessary to use a system or product. We can arrange the user’s steps in a circle because the they always repeat themselves in the same order; they are cyclical. However, each step has a direct effect on the next consecutive step in the system and an indirect effect on the other steps.
With this picture in mind, we can take survey responses and connect surface level pain-points (or complaints) to deeper causes of dysfunction. This is in the service of avoiding premature solution generation. For instance, you may conclude from your patient surveys that the wait times are abnormally long. This is important information though it is not enough to start the solution generation phase with. If you were to try to solve the surface problem with such little information, the best solutions you could come up with would be limited to occupying the patients in the waiting room instead of shortening wait times or making appointment arrival times more accurate.
Let’s look at this dreamcatcher diagram. Again, its purpose is to help us visually lay out a complex system.
The first step in creating a dreamcatcher diagram is identifying the primary task. What is the main goal here? Within a doctor’s office, it might be to perform a complete physical on a patient.
Next, identify the primary user. From her point of view, list out all the steps she must go through to accomplish this primary task in a circle, from start to finish to start again.
Within each step, answer the following questions:
What is this user expected to do?
What does she need to know to complete this step?
Who else is involved?
Answering those questions will give you a good idea of how effective the current process is, and which steps present problems.
At all steps where the primary user interfaces with a machine or secondary person, the primary and secondary user share a step. These points of interaction in the process allow us to branch out to elaborate on the responsibilities of secondary users in accomplishing the primary user’s main goal.
To elaborate on a secondary user’s process, simply repeat the dreamcatcher diagram and fill in the steps.