AIME (Cornell Tech Product Challenge)

This project was part of Cornell Tech's Product Studio. Masters students at Cornell Tech team with designers from Parsons' MFA Design and Technology program to create products based on challenges submitted by top tech companies. The curriculum adapts the Google Ventures' 5-Day Sprint. Students are randomly teamed and work on the challenge throughout the course of the semester. Our team worked with Hale Health to answer the question:

SUMMARY

The Team

Our five member team was assembled based on our interests and skill sets by the studio instructors. We all shared an interest in health tech and a background in healthcare. Over the course of the five month semester I witnessed all of my teammates bring multi-disciplinary skills to the table and grow in their expertise.

Dani Beecham, MFA Candidate: Design, Research, Product Management

Seye Bankole, MS Health Tech Candidate: Engineering, Development

Phase 1: UNPACKING

Our first sit down as a team was challenging. We had an extremely broad "how might we" to consider. We were instructed to unpack our challenge during our first session. We were asked to identify our system diagram and come up with user stories. It occurred to us that with such a broad topic, we needed to define just what type of chronic disease we wanted to focus our solution finding on. I led the team in a mind mapping exercise and we dumped a lot of ideas and possible pain points out on the whiteboard. I was accustomed to doing this type of exercise with fellow designers so it was valuable to experience leading the exercise with technical colleagues because there can sometimes be a disconnect in recognizing the value of abstracting thought and rapid brainstorming.

At the end of our session we decided to focus our initial user stories on cancer and some of the pain points we had identified. You can read the user stories here. And we created the system diagram below. 

PHASE 2: IDEATION

Our idea was taking shape but we still had not identified a valuable place to intervene within the system to give our product shape. We needed to ideate. Following "Sprint's" advice, we did some rapid sketching as individuals and came together as a group to vote on the best sketches. We each produced two storyboards and voted on the storyboards that we thought had the most potential. We selected my chatbot storyboard as the idea we wanted to pursue and highlighted elements from Nick's and Spark's sketches as our Maybe Later's with features and ideas to save and possibly incorporate in new iterations. 

With the winning sketch, we had a focus and a form for our product but we still did not have a complete narrative. We had an overview of how a chatbot tool could help but we still needed to specify the impact and develop a user persona. As a team we also still had a knowledge gap that we were uncomfortable with. In "Sprint" the model succeeds because it brings together stakeholders that are all experts in their area of the business so they bring valuable insights. None of us were healthcare experts so we needed to learn as much as we could about the chronic disease. 

PHASE 3: NARRATIVE

Our company advisor was Doug Jamison- founder and CEO of Hale.life. We shared our early ideation with Doug and he agreed with our direction. We were encouraged to stay on the track of gathering data. He introduced us to the concept of functional medicine which leverages big data to craft better diagnoses and treatment plans. 

We continued to iterate and refine our original user stories into a narrative that incorporated the functionality of a chatbot. In our first iteration we envisioned the chatbot performing the following tasks:

1. Educating users about their health risks

2. Providing scientific resources

3. Managing patient referrals and appointments

4. Providing treatment reminders

5. Communication with caregivers about treatment progress

6. Tracking patient recovery and providing update

Read the full narrative here. 

PHASE 4: FOCUS

We had a more refined narrative and a lot of ideas but we still needed to refine our focus. We sat down with other teams for a SCRUM session to preview our idea and gather feedback. We also received feedback from our studio advisor. Then we took to the whiteboard again to give shape to our user persona and a focus for our product. 

Results

• Disease Area: We initially selected Cardiac disease, but later decided on Diabetes because it has a well-defined treatment plan.

• Age Group: 55 and over

• Socio-Economic Status: Low-Middle

• Phase of Illness: Treatment

• Care: Has a caregiver in the home

With a more defined focus, our team entered our first sprint. Sprints are two day work sessions where teams are challenged to complete different stages of the product development. For Sprint 1 we were challenged to develop and present a functional minimum viable product (MVP). 

Sprint 1 produced the following:

1. Voice chatbot with limited response capability

2. Hard-coded physician dashboard

3. Product loop

4. Pitch presentation

Halfway through our day we realized that we still needed a name for our chatbot. We brainstormed and ultimately decided on the name AIME (pronounced Amy). Though patients would only know AIME as the voice and text personality there was also another crucial component to the AIME service. Below are some of the mock-ups of AIME's physician dashboard for doctors to access their patients' treatment plan and progress via data visualizations.

Feedback

We presented our progress to a group of our peers and industry professionals including Greg Pass. Overall, our feedback was positive and we were ranked amongst the top 2 presentations of the day. We successfully generated enough interest in our problem space and the audience found our solution interesting and impactful. We still needed some fine tuning of our narrative and how we demonstrated the product so we took that with us to the next sprint. Below are some of the feedback cards that the audience filled out.

PHASE 5: RESEARCH AND DEVELOPMENT

After Sprint 1 we felt confident that we were on the right track with our solution but we needed to validate our point of view. Here are a few key questions we needed to answer:

1. Will physicians be interested in our solution?

2. What methods do physicians find useful when treating chronic disease patients?

3. How can we use AIME to motivate patients to improve their behavior?

I took the lead on developing a research strategy. We interviewed four MD's to gain their insights based on an interview guide I developed that focused on the following:

1. Overall feedback on our chatbot solution

2. Their approach to encouraging behavior change in patients

3. Insight on the tools and technology that is useful in their practice

4. What approaches they use with chronic disease patients

Findings

1. Overall feedback: Overall feedback was positive. The doctors were very interested in the idea of being able to leverage real data to track a patient's progress and saw it as an opportunity to better customize their approaches to treatment. 

Key Finding: AI could be a more advantageous form for patients to report back accurately because it may be perceived as non-judgmental. 

2. Behavior change: All of the physicians found that empowering the patient to be engaged in their own health was the most impactful method to motivate patients. 

Key Finding: It's important to make the patient feel invested in their care. AIME could empower patients by giving them a better understanding of their own progress and set-backs. 

3. Tools and technology: They currently use Electronic Health Records (EHR's) but have found that some create more work than they save.

Key Finding: The physician dashboard has to be easily integrated into the physician's work flow otherwise it will be viewed as burdensome and that would hinder adoption. 

4. Patient approaches: The physicians advocated for empathetic approaches that included practices like being non-judgmental, applauding patients for their progress, and positive reinforcement.

Key Finding: Peer-peer care teams are more successful models than family care teams because they are more neutral in their power structures (example: parents and children).

PHASE 6: TESTING

We began by familiarizing ourselves with diabetes treatment by reviewing the Diabetes Prevention Program (DPP). The DPP was a valuable resource because it gave us insight into diabetes care and the types of data points it would be advantageous for AIME to collect from users. 

Once we had a stronger understanding of how AIME could help patients, Nick and I started having conversations with two diabetic patients in our lives- my father and his mother. Our conversations with them grounded our process in empathy. Here are some of our key takeaways.

1. Being able to see the consequences of their actions in advance would be useful

2. Would like suggestions on what to do to improve your progress when you're not doing well

3. One of their biggest challenges is picking and choosing what to eat

4. Overall, very enthusiastic in the possibilities of a tool like AIME

Recruitment Challenge

Once we had validation from physicians and diabetics, I pressed for testing on a larger scale with actual diabetic patients. AIME didn't have enough capability to deploy with patients but I devised a prototyping test that would allow us to simulate AIME in what I call a mechanical turk test. Each team member would be assigned to a patient and we would act as AIME by contacting the patient with AIME's set responses and manually record their feedback. 

User Testing Script Samples

I developed a conversation tree script to onboard the user and collect a limited amount of data. My team members and one of the physicians we initially interviewed gave their feedback and refined it. I also developed a testing proposal to provide an overview for the physicians we planned to approach.

Link to full script

Our professor, Deborah Estrin, connected us with physicians at Weill Cornell Medical Center and we began the authorization process to recruit diabetic patients for testing. Unfortunately, we were unable to successfully recruit patients before our final sprint. It took time to get buy-in from the team on the testing methodology and I underestimated the amount of time it would take to find the right recruitment setting.

PHASE 7: Conclusion

Our development team overcame some very impressive hurtles and were able to execute AIME's voice encoding. They initially struggled with connecting the Twilio voice service with Amazon Lex but for our final sprint, we had a functional voice recognition chat-bot that was able to update the live site physician dashboard with a limited range of data from the user. 

Learnings

• This was my first experience developing a product from ideation to prototype and my first experience closely collaborating with engineers. I took away a lot of valuable knowledge about how to adapt my communication approaches based on my audience.

• We followed a set curriculum that was designed for us to focus on different parts of the development process at different times. I think my team and I found that we should have deviated from the curriculum in order to test earlier in the process.

• It was incredibly encouraging to see how much enthusiasm doctors had for our solution. My biggest take away is that health tech is a dynamic space with lots of problem areas and physicians are eager to solve them.

• Rapid development sprints can be extremely efficient in driving progress but they are only useful if you can go into them with a set plan of action.

• I gained some great insight on how to tell your audience an impactful story. We presented our product pitch in 3 sprints, 3 SCRUM sessions, and 3 crit sessions. We refined our narrative a lot and in the end I think it was much more compelling and clear.

FORWARD

Our sponsor company Hale.life is continuing their exploration of the AIME model in the functional medicine space and we have offered our consulting services.