The Death of Groups Texts Starts Here.
We all know and have likely been in the dreaded group text to try and organize dinner with more than 3 friends. It's a never-ending back-and-forth of when everyone is free, when can the couple with kids find a sitter, and what diet is Carol on this week? RendezView simplifies the scheduling and locating of a hang with your friends. No sign up required, guests and hosts alike can input any necessary considerations (i.e. - diet, level of effort, size of group), and through a swiping interface ensure everyone is accounted for and heard when agreeing on the location.
Overview
My Role -- Sole designer (certificate capstone project)
Timeline -- 3 months
Problem Statement
As the capstone project for General Assembly's UX/UI Design course work, we were tasked with solving a problem we are passionate about. Timely enough, I had recently been in several conversations about group texts around the holidays. I quickly narrowed in on three problem statements:
1. Adults need a quick and easy communication/decision making medium so they can easily agree on a time and place to meet.
2. Folks need a way to find new things (restaurants, events, venues) to do in town within their personal interests other than word of mouth and social media/influencers.
3. We become overwhelmed when juggling our own schedules and needs with the schedules and needs of others due to cognitive overload and fear of negative social perception.
Assumptions
- Folks know how Tinder works. (I was wrong.)
- The interface of when2meet/lettucemeet was so simple, I didn’t think I would need to explain. (I was also wrong.)
- Most people use group texts to organize hang out’s... and hate them. (I was correct.)
Through comparative analysis, it became clear that currently existing websites do not have cross-over in the features I was seeking for RendezView. My ideal outcome was to bridge the gap of scheduling applications, event planning/suggesting, and review sites. Of the 12 competitors I reviewed, 3 checked the most features, excited, and inspired me. These included when2meet.com, Partiful, and Yelp.
When2Meet.com
Wins
- Ability to collect group feedback to find a central time to meet.
- If a Host has been selected, they can put in either specific days in the week (assuming same availability weekly), or specific dates and time windows.
- Creates a unique link for each event, and very simple design.
Drawbacks
- No option for guest list
- Other event details cannot be added.
- No privacy settings.
Yelp
Wins
- Smart Suggestions - If a restaurant exists in your city, it’s likely there is a Yelp page for it.
- Sponsored ads take priority, and suggestions are not catered to user interest.
- Primary filter focuses in on a service or restaurants (no events).
- Secondary filters are robust – Expense, category, features, distance…
Drawbacks
- While Yelp offers a wide variety of restaurants and services, there are no events.
- There is a missed opportunity for restaurants who have not signed up.
- Community feedback of "low traffic" restaurants being hidden or removed from the platform.
Partiful
Wins
- Offers a fun and interactive experience when creating an event page (serotonin boost for the MySpace-age crowd).
- GIFs, memes, and emoji's keep users engaged.
- Option for event upgrade features, including guest list visibility, open or closed invite, and COVID protocols.
- Ability to sync to calendars, and only notifies if there are changes or the event is approaching.
Drawbacks
- Requires the host to specify all details of guest list, date/time, and location.
User Interviews
Through 15 interviews with a range of backgrounds (career, age, home life), I gathered a host of details users said they would be interested to see on a platform like what I described.
User Flows
I created user flows that would aide in the designing portion of development. In most of the scheduling sites I researched, there always needed to be a "host". I had originally intended on there being a singular user flow, but quickly realized the importance of a specific Host and Return User flows to make the event grounded to some base-line parameters.
Host Flow
Something I was passionate about is making "sign up" optional. The user is greeted with a quick onboarding to understand what the app can be used for, then is greeted with a "been here before?" screen. In future-state, this will need to be fleshed out further to include flows for monitoring, duplicating events, reviewing favorites, etc.
Return/Guest Flow
Return/Guest flow was fairly straightforward. The caveat to future-state build would be the guest user can skip inputting preferences if they have a profile/membership. This would cut upwards of 5 minutes of inputting information and bring the user to the swipe function.
Low-Fidelity Sketches
User Testing & Edits
OnBoarding
In one of the first user tests I observed, the user quickly got lost and forgot the task at hand almost immediately. This taught me that I needed to create some user onboarding. I created the screen at the top of this page to introduce the application uses, and also developed the onboarding video shown here to guide users through how they needed to interact with the application.
Swipe Functionality
I had assumed in the beginning, that most people knew intuitively how to interact with a Tinder-like interface. I quickly realized, that is not true. I had intended the thumbs up/down to be a secondary way to say a user was interested or not in a specific location. This was ultimately confused with "liking" or "disliking" a location. The star was intended to be for users who decide to create a profile. This feature would allow those users to add a location to their favorites collection.
I opted to create a directional box to visually instruct users how to interact with it. For folks on dating applications, it was intuitive to swipe right. Users who had not used a dating app or had some time since thought it should be the other way around -- swipe left if you like something, swipe right if you do not. I ultimately decided to follow status quo with what dating applications are doing currently.
Scheduling and Availability
I had been so impressed with the simplicity of when2meet.com and lettucemeet.com, that I thought other users would find this easy to use as well. Another wrong assumption on two parts - design and UX writing.
Before, users could not see a second dot (background before) that would allow them to place a time range of their availability. In the second design iteration (foreground before), users were hesitant to physically touch and drag on the screen to populate a range of availability.
Ultimately, I opted for checkboxes between hours and changed the instruction verbiage to make this screen more accessible. Additional design learning was in consistency -- I realized that the blue "next" button was not consistent with my intentional design to not favor a specific mobile platform. That was edited to the neutral grey button.services using state-of-the-art equipment.
Navigational Buttons
Something that should have been very obvious from the beginning was the need for navigational buttons. Users would get past the screen of additional considerations (diet, cost, religious, etc), and remember they forgot to include a consideration. They would try to go back, but I had not made a way for the user to edit previous screen selections. This was a quick and easy fix, again staying true to my focus on mobile platform neutrality.