Portfolio 4: Meet
--
Timeframe of project: Fall 2015
Meet was completed as part of a quarter-long project for CS147, Introduction to Human-Computer Interaction, at Stanford. The project was done in a team of four, of which I served as the designer. Amongst 62 teams, Meet was awarded Best Overall and Best Visual Design in a final project fair with industry judges.
The initial meeting for the project yielded a common team interest of finding ways to improve productivity. Ironically, after many user interviews and many more meetings, productivity in meetings was highlighted as a persistent concern. Although solutions have been attempted by many (Sunrise, When2Meet, etc.), Meet takes a different angle in solving meeting ineffectiveness, through starting mobile-first and avoiding a oft-done simple meeting scheduling solution.
The purpose of Meet is to make users more aware of their own meeting behavior and provide productive roadblocks to reduce the number of meetings and attendees.
Needfinding to Ideation
Needfinding separated users into either Students or Professionals, both potential markets for Meet. Students were selected from the Stanford undergraduate population and observed in club meetings, study groups, and group projects. Professionals were contacted at a design agency, a commercial tech startup, and a non-profit, and observed in one-on-one meetings, small-group meetings, and company-wide all-hands.
Observation focused on three areas of a meeting: before-meeting planning and preparation, during-meeting interactions, and post-meeting follow-up and questions.
The big takeaway from needfinding, boiled down from a plethora of problems, was that people lacked awareness — in how much time they were spending in meetings, in the purpose of specific meetings, and in general meeting behavior and etiquette.
A variety of potential solution were tested using low-investment experience prototypes — Google Docs, short moderated discussions, and focus groups.
Low-Fidelity Prototype
Extending the ideation stage, a low-fidelity paper prototype was developed. Users were asked to complete a variety of tasks on an “app” (screens drawn on paper): creating and setting the agenda of a meeting, inviting attendees to a meeting, and adding feedback and action items post-meeting. Each of the tasks represented a separate user flow in the prototype, and could be iterated on quickly.
Medium-Fidelity Prototype
Following feedback from the low-fidelity prototype, the medium-fidelity prototype was designed and hosted on Invision. This simulated look, feel, and interaction of the final product. Shown below are the opening and home screens of the prototype.
Main tabs leading to additional screens included a meeting list tab and a statistics tab.
Further testing with users on the medium-fidelity prototype yielded two conclusions. One was that setting the agenda of a meeting, a feature central to the medium-fidelity prototype, wasn’t practical on mobile. Second was that there needed to be a better feedback loop between meeting host and attendees — a simple RSVP wasn’t enough. These points are addressed in the high-fidelity prototype, which constitute the bulk of the writeup below.
High-Fidelity Prototype
The high-fidelity prototype is a shippable final product. The app was built in iOS using Swift.
Navigation
Meet uses a bottom tabbed navigation bar. Shown on the left is an earlier version of the app’s navigation, which consisted of tabs to see upcoming meetings, create a new meeting, see received meeting invitations, and track overall stats, respectively.
This was eventually condensed to a final version, right, which places greater emphasis on statistics (now Dashboard) to track user behavior, consolidates new and invited meetings into a single “Upcoming” tab, and separates meetings the user is organizing into its own unique tab.
Dashboard
Meet requires users login to interact with the app, whether hosting or attending a meeting. Following sign-on, Meet’s first iteration of its landing screen originally displayed a list of meeting invitations and upcoming meetings, both high-interaction items.
The issue however, was that Meet (like many other apps in its category) seemed to be emphasizing meeting scheduling and content, rather than meeting patterns and behavior, the latter being the desired goal. The solution was the Dashboard.
The Dashboard visualizes meetings in different timeframes selected by the user, either in the past week, month, or all-time. The graph is interactive and can be dragged to show hours on specific days of the time segment. Additionally hours in the previous time period and percent change are displayed at the top of the screen to give the user greater awareness of improvement or decline.
Upcoming
Upcoming meetings (the landing screen in earlier versions) has been pushed to the second tab and divided into two sections; meetings invites awaiting a response from the user, and upcoming meetings the user is hosting or has marked as attending. Clicking on an upcoming meeting gives the user additional details, with options to edit or cancel the meeting if the user is the host.
A notification dot appears in the bottom navigation bar should the user receive a new meeting invite. Upon click of the invite, details will be provided along with a list of meeting “talking points”. Talking points can be thought of as a set of bulleted agenda items for a meeting, each limited to 150 characters.
The user is asked to select points relevant to them, with a default option of “none”. The desired behavior is to decrease the social stigma of saying “no” to a meeting invite with reason being that none of the meeting content is relevant. The response is sent back to the meeting organizer.
Organizing
The final tab of Meet is the meeting organizer tab, which lists out meetings the user is hosting and unfinished drafts of meeting invites. From this screen, or any of the previous screens, a user can create a new meeting invite from an icon on the top-right of the screen. The new meeting is created through a series of swipable pageview screens.
When creating a meeting, most important is the setting of “talking points”. Originally creating a new meeting required input of a full meeting agenda, but this proved quite a lengthy task for mobile. Instead, “talking points” are capped at three, with each talking point’s character limit (150 char) being the length between a tweet (140 char) and a SMS text (160 char).
Talking points are meant to narrow meeting necessity and participation only to those that are relevant, put into effect when those invited RSVP to specific points. In a few user tests, it was even the case that in the process of creating talking points, the meeting organizer themselves realized a meeting was unnecessary. A final summary screen is shown before the user sends out the meeting invites.
Summary
Meet’s interface and task flows need to outweigh the naturally dull nature of meeting scheduling. The app is targeted towards both student groups and professionals, both of whom’s feedback are substantially incorporated into the app. Future development may include greater personalization of meeting invites and integration of texting meeting details to non-users of the app.
Thanks to Derin, Liza, and Theo for being an awesome team on this project!
