Further developing Anchor’s in-meeting experience
Developing a task flow and sketching out Anchor’s in-meeting interventions.
After a mild detour exploring the style of our app and prior to divvying up our taskflows, our team met to get a better idea of our site map and what fell within the scope of our behavioral intervention. You can find the results below, with the happy path highlighted in yellow.
Ideally, our users would set up the Zoom app through some form of setup wizard after downloading it in the Zapp marketplace, at which point we walk them through first setting up a few preferences (that can be later accessed in Zoom’s preferences). Following this, they’d enter a reinforcement loop of in-meeting experiences and analytics (punctuated at times with visits to the Preferences page to edit accordingly).
The in-meeting experience
The in-meeting experience is unique in that it’s largely passive for the user once they’ve entered the meeting — at that point, the system has to do a lot of the heavy lifting to prod the user to drink water. You can find the taskflow for the in-meeting experience below.
Some things to call out:
- The Set meeting preferences subtask would be primarily implemented as a series of questions in a form, asking questions such as how long the user expected the meeting to last, what triggers from a bank they’d like to use, and other information that would otherwise be gathered for scheduled meetings.
- The most important part of the taskflow above is the funky loop created around Continue meeting, where the user will spend the majority of their time. Think of it like a finite-state machine on autopilot until the end of the meeting — the system will check if a trigger word was uttered, prompt the user to drink if so, and not otherwise. If the user attempts to modify the settings, they’ll be taken to a similar preferences taskflow.
- At the end of the meeting, we’ll prompt users to visit their analytics and share some at a glance — however, we won’t force them to!
Below is a sketch of how the intervention will look in-meeting.
The screen above is an iteration from a wireflow from last week after considering that users may not want their reminders to be distracting, but still noticeable — the solution below reflects a pulsing icon with a message box that pops up when it’s time to drink. Ideally, an audio cue would also play, in case the user is not paying attention or is away from the computer.
Next steps
From here, our team’s next steps include precisely defining what information we need to effectively carry out the intervention during meetings and fleshing out the screens toward a higher-fidelity prototype.
