QueuePals: using Behavior Design to create a zero-contact virtual waiting room solution
Last quarter, I took EDUC 302: Behavior Design at Stanford University with BJ Fogg. After completing a personal project to stay in touch with my grandparents, and then a small group project to help make long distance relationships feel more fun, I worked with two Stanford students to launch QueuePals, a virtual waiting room solution that enables patients to safely check into doctor’s appointments via text message.
In the three weeks we had to work on the project, we went from the vague aspiration of “helping people adjust to the new normal” to a highly specific solution that helped over 50 patients check into their doctor’s appointments at two clinics.
Our success stemmed from focusing intensely on what we learned about Behavior Design, and channeling that into our development process.
Following the 7 steps of Behavior Design
The 7 steps of Behavior Design to design a product are:
1. Clarify the aspiration or desired outcome
2. Magic-wand target behaviors
3. Crispify the target behaviors
4. Focus map to select target behaviors
5. Make the target behaviors easier to do
6. Starfish options for behavior flows
7. Snaptest to get insights fast
(credit: BJ Fogg)
The video below walks through the entire project in-depth.
My 4 main takeaways from this project are:
- It’s nearly impossible for your objective to be too specific.
- Who you have access to is just as important as what problem you want to solve and how you will solve it.
- Snaptest: ship early, ship often, and use existing tools to replace custom-built solutions whenever possible.
- When in doubt, refer to the two maxims of Behavior Design.
Get specific
The aspiration we started with—“to address the most pressing challenges of the coronavirus pandemic”—was far too broad of an aspiration to be useful for any of our projects. To narrow things down, as a class we first brainstormed a list of over 20 different subtopics, including but not limited to:
- Small businesses facing financial hardship
- The spread of misinformation
- Future-proofing the healthcare system against future waves
- Adjusting to remote work
All of these subtopics were compiled into a Google Form, which we then distributed through social media. Over 100 responses rated each of the subtopics, and we ended up with a crowdsourced list of challenges considered “most pressing.”
With my group, we ended up narrowing down our aspiration to “improving safety and mitigating risk of infection in the primary care patient journey as society adapts to the consequences from the COVID-19 pandemic.” We then further narrowed down to a single part of the patient journey: the waiting room.
Who do you have access to?
When kicking off a new and exciting project, it’s easy to get caught up thinking of what problems you can solve and how you might solve them.
The problem and solution are critical, but just as important is having a way to access a group of users who suffer from that problem and would be interested in your solution. Not only is this super important to be able to test and iterate quickly, but it also validates that the problem you are working on is indeed a real problem for real people.
With QueuePals, we knew we wanted to tackle a problem in the healthcare space. However, we knew we didn’t have immediate access to hospital administrators, and even if we did, we knew working with that group would also require getting through a lot of red tape.
However, through personal connections through family or organizations like GetUsPPE, we knew we had access to primary care physicians. Additionally, we recognized that smaller, family-owned clinics would be able to test our solution significantly quicker than larger medical institutions.
The power of the snaptest
If you have 100 hours, would you rather test your solution 25 times or just once?
This was a question posed to us by David Ngo, and it highlights the power of the snaptest.
Whereas the traditional design process optimizes for the interface design of the product itself, the goal of Behavior Design and snaptesting is to optimize a target behavior—the product is a means to an end rather than the end itself.
Instead of getting caught up in software development and spending weeks trying to achieve perfect fidelity, you will be much better served using simple, prebuilt tools to simulate the experience of the target behavior as best as possible within four hours.
To snaptest out our text-based waiting room solution, we first used our class itself. Gathering a list with everybody’s phone numbers, we enabled the Zoom waiting room feature. Ten minutes before class started, we manually texted out our behavior prompt:
EDUC 302 Check-In: Hi [name], we are testing a virtual waiting room solution. Please reply “YES” when you are here in the Zoom waiting room for class to begin.
With nothing more than iMessage and a spreadsheet of phone numbers, we were able to test how people would respond to this message, and observe potential issues down the road (for example, 2–3 min delayed response times, and replies other than “yes”).
Even when launching in 2 clinics, we decided to go with Glide Apps, a no-code, Google Sheets based solution to build and deploy our web app. The only code we wrote was a few functions with Google Apps Scripts to use Twilio to automate the text message sending and receiving.
As a team of 3 computer science majors, we no doubt could have crunched out an app from scratch. But why spend 100 hours building something when 4 is all we needed to test the target behavior with our users? The doctors and their staff didn’t care what was under the hood, and neither did the patients—so snaptest until you get the behaviors right, then worry about building for scale.
The two maxims of Behavior Design
- Help people do what they already want to do
- Help people feel successful
It takes practice, but viewing the world through the lens of these two maxims is a fantastic way to predict the success of a product or project. Nearly every successful product helps people achieve a behavior they already wanted to do, but couldn’t (or couldn’t easily do). Successful products also empower the people who use them, creating a positive feedback loop that leads to long term user engagement and success.
To illustrate, for anyone looking to publish and share articles online, Medium is one of easiest ways to do so, with a quick sign-up process, streamlined editing interface, and many sharing options. After an article is published, “claps,” comments, and follows help writers feel successful and promotes ongoing engagement with the community.
Satisfying the two maxims alone cannot 100% predict the success of a project, but it certainly is the best starting point—it is nearly impossible to try to launch a product and then motivate disinterested people into wanting to use it.
When launching QueuePals, we worked with a doctor who was already manually messaging his patients to have them wait outside in their cars, but was having trouble keeping track of when to message which patient and when they responded. By automating this entire process, we helped patients do what they wanted (minimize contact), the doctor do what he wanted (keep patients safe and focus on providing care), and the staff do what they wanted (manage a schedule and track patient check-ins live).
I’m certainly no expert on Behavior Design, but after taking EDUC 302 and applying the methods of Behavior Design to my projects, I recognize its tremendous value and hope to keep learning.
Thank you to BJ Fogg and Will Shan for a fantastic class! If you want to learn more about applying the methods of Behavior Design, I highly recommend reading Tiny Habits.
Update: we’re scaling QueuePals this fall 2020 with support from Coding it Forward and Schmidt Futures’ First Act Fund!
