Welcome back. A good place to start with design research is information that it's easier to access, and that is secondary research. This might mimic some research you've done in the past, but it can go deeper than that. Many designers like to call this the deep dive. To begin, start with gathering historical information about the problem you're addressing, play detective, and see what's happened in the past. What have your users done to solve the problem in the past? When or how did their needs come to be? What is the history of the organization that you're solving the problem for? When dealing with a digital health product, you will also want to look at domain-specific information. For example, if you're creating an application for clinical management of cancer patients, you may want to look into what are their critical action values that are measured, how treatments are delivered, and what are the potential outcomes. Look at the current specialty that you are designing for and understand the background behind it. There is also contextual research. This includes things like, who are your stakeholders? It also looks at how people might interact with other technologies that are similar to yours or that interact with yours. I encourage everyone doing secondary research to do personas as part of their contextual research, which I will go over in the next slide. Additionally, there is your typical academic research. This is something that you might be a little bit more used to looking at what's been published before. But it's great to have an understanding of what the research interests are and how they connect with your clinical delivery. In health care, there's always some study that's been published about your technology or something similar to your technology. Make sure you've done your reading. An overlooked source of secondary information is achieved through tracking digital social footprints online. By that, I mean looking at social media forums, any other things that could be posted online that may come directly from clinicians and patients that might be impacted by your application, see what they're saying about the problems that you're trying to address through your technology. Going back to one contextual source of secondary research, I'm showing you an example of a persona. This is not a real person. The image you see is a stock image. This person actually represents a combination of people that we've spoken with. We created this persona as part of a design project that we completed with the Johns Hopkins Technology Innovation Center. When designing a technology for CRISP, which stands for the Chesapeake Regional Information System for our Patients, this is the health information exchange that we use in Maryland. We were helping to create a new application to be included in the medical record. We included categories in the persona like specialty, goals, workflow, pain points. Are there any other problems that this person is encountering? Then we also included in this persona, top data requests. Because in this case, that was something we were really trying to root out as part of our research. But we also included software points about the individual. We defined items like their age, their location, their hobbies, and what their values are. These are important things to understand as you consider the perspective of the persona and try to establish empathy with that archetype. You can even include things like technology literacy, quotes from the person, and aspirations. It's important to note again that you should not make a persona based on one person. That you should make this based on a collection of people that you've talked with that may have similar perspectives. In this case, we use an obstetrics and gynecology provider because we were looking at different types of providers. Most software designers use personas often and create at least a few to remind them of the different needs of their users. Finally, there is analogous and competitive research. This is another step in the secondary research process and this is my favorite part because it's what you naturally want to go do when you're creating a new product, you want to look at your competitive and analogous people that are out there. Competitive products are probably where you jump first. You're looking at all of those products that are anywhere similar to your software application. Competitive means they're solving something that's similar to the problem that you're trying to solve. This could be directly or indirectly. Don't ever say there are no competitive products out there to what you're trying to do, there's always something in place that is a band-aid that's trying to solve the problem. In healthcare, there are Low-Fi products or processes that are there to compete with what you're doing. An example of a Low-Fi competitive product would be something as simple as using a whiteboard to display a chemical process or a binder to gather information. Even very simple solutions are competitive products to what you're developing. For analogous products, these are perhaps the most essential to consider in the art of what's possible out there when you're designing. Look at how other industries outside of healthcare are solving similar problems with technology. How can you learn from their successes and how can you learn from their failures? Some common examples of healthcare technology analogous industries that you can look at, one is aviation. It's another high risk industry and has tackled some major problems with a lot of success. Education, which is a very complex industry, is also similar to health care and you can learn from it. You can even look at technology products and something very far from healthcare, which is agriculture. Again, we're dealing with massive scale taking care of something. In this case, crops instead of people. But you can see how you can learn from the technology that they've delivered and apply various success to healthcare. Secondary research is your chance to really go deep into the content and get to know it well. It will help you in talking to users, which you will do later, and it will help you in understanding more about your design. Above all, it's enjoyable, so go ahead, get to work.
