Adventure Together - Matthew Design

Example Case Study

Adventure Together

An event planning app for groups of friends

Platform

Mobile App for Apple and Android devices

Problem

Groups of people who vacation, attend concerts and other events together can at times struggle with finding one another, share photos or videos, and stay in contact during the event period. Whether they want to sync up on a meeting place or share a photo, these users typically resort to multiple ways to complete these tasks which means shuffling apps, managing contacts, and chatting with the appropriate group members at any given time. These tasks take thought and time away from enjoying friends and the event itself.

Goals

Adventure Together’s main goal is “set it and forget it” convenience around a group event. One group member sets the dates of an event, the venue and invites other group members to join this event. Once joined, members can share photos, location info, and chat with minimal effort.

Team

Project Lead, Developer, Designer, Marketing

My Role

Designer / Project Coordinator

Project Status

Version 1 concept completed

UX Phases

Sketching, Card Sorting, Personas, Journey Maps, Top Tasks, IA, Wireframing, High-Fidelity Mocks

Section #1: Planning

Preliminary list of features

Our first step in the process was to assess functions and features present on modern smartphones that users want to interact with while amongst their friends at different events. From this assessment, we then defined a list of “must-haves” (things the app has to do at a minimum to be a valuable MVP) as well as the “nice to haves” (features that augment the experience beyond the basic problems are were solving for).

This focus on an MVP allowed us to achieve a working product much sooner to put in front of potential users of the Adventure Together app.

Example Must Haves:

I can share photos or chat with a group of friends as a whole without having to select individuals or have them in my contacts.
I can provide my location to the whole group during an event so they know where to meet me.

Example Nice to Haves:

Local weather information or suggested activities around the venue location is displayed in the app.
Ability to reserve seating for venues for the entire group directly through the app.

Defining a sample problem

To help determine if we are solving a real problem that users have we created the following sample problem:

I am attending an AC/DC concert. I have left my group of friends and moved up close to the stage to capture some great shots of the band. I can snap the pictures now and send them to my friends immediately or later on.

Whether sending the photos now or later the steps to achieve this on a standard smartphone are:

Open the camera app
Snap the picture
Open my text app
Choose a new chat or locate an existing one
Find and choose the first friend
Find and choose each additional friend in turn
Select attach
Browse the gallery for the images and select them.
Send

This is not a terribly hard task list, especially if there is a group text already existing recently where you can attach the images. However, walking through all these steps with the distraction and noise of a concert or by delaying step 3 onward to later on, for example after the concert, there is still the cognitive effort to finish the task.

Setting the goal

Remembering our goal of “convenience” we needed to take each action and distill it into simple clicks in the proper context. Context, in this case, would help the user to understand the next step or impact of an action without the cognitive load.

One big advantage of the app immediately is the pre-meditated nature of preparing for an event beforehand when the event noise and distraction are not yet happening. This means the user can eliminate a lot of the steps and pre-set the context of the app so they aren’t navigating and switching things around while in the middle of the fun.

IE. I already know when I take this picture (from within this app) it will be shared with these friends automatically because all of this was set up by me before the event started.

This theme in our discussions caused an important idea to arise early on around the concept of an “event” taking place that defined the boundaries of the actions that users would perform. Notably, during the event period, set by a range between two dates, users would open up their access to fellow group members so that they were more easily and readily available during that period for more seamless interaction.

Because of normal privacy concerns of most people, the event is finite and access only happens within the event range as agreed upon by each participant. Once the event ends that access is turned off and thus resuming the group members’ normal privacy levels without the user having to take action. After this transition, the artifacts created during the event would then become historical and read-only in nature.

We agreed this key principle would be a defining part of the Adventure Together app.

Grouping Exercise

After the list was defined we did an exercise around the key tasks that would happen in each “area” for example taking pictures or looking at a gallery of shared images. A couple of examples of an “area” we defined were “media” or “location services” (see the full list in the image below).

The exercise meant thinking about exactly what types of tasks users would want to accomplish and would associate to a given context. This would begin to inform the information architecture.

Each team member would think of tasks related to an area keyword and then write out actions they might take in that area. “Area” could also mean “page” or “view” but I kept it vague since we had not defined the IA or flows at this point.

Personas

When thinking about the personas of people that would use the Adventure Together app we approached it largely based on the nature of the relationships within a group that attend an event together. While edge cases such as a couples’ weekend getaway would a feasible scenario, we wanted to capture the dynamics of a group where some members don’t fully know one another (thus do not have each others’ contact info) but are part of the event together. We did not want to assume all users were close friends so that we could define what pieces of information they were willing to share.

So our personas are based on roles defined around levels of involvement within the group that is traveling together. The examples are:

Organizer: The person who initially plans the trip and socially knows every person in the group fairly well.
Backup/ Co-Organizer: This role was added specifically to understand contingent possibilities around an event should the organizer become unavailable. Possibly not needed because of the freeform nature of membership into a friend group. The model suggested is that any invited member can make changes to an event.
Group Member (familiar): A person who is not an organizer but regularly attends events with these friends.
Group Member (unfamiliar): A person who has not previously attended an event with this group and/or doesn’t know many of the group members.

One key discovery around the personas and roles we created was that they were over-complicated based on an initial design idea around seamless photo taking. The reason for this was that privacy in sharing information with the group, which we looked at early on, was largely not a concern at all if the user understood and opted into taking photos from within the app vs. with the default camera app.

For example, rather than specify that I don’t want to share my family photos with the group inside the app, I simply just take photos of my family with the regular camera app. This way only photos I take within the app are group shared.

While this meant that the user had to choose which app to take the photos with, this greatly simplified our approach going forward and we did not have to tackle additional challenges around opting into information sharing on an individual or feature basis.

Journey Map & Top Tasks

Before wiring up any visuals, we took some time to map out a few journeys our personas would go through to complete their tasks. This involved writing a couple of scenarios and listing out individual tasks that might be completed along each journey.

This exercise helped us to quickly see how interweaving the functions closely together would help define their journey and accomplish the tasks they wanted to complete.

From this we see the need that users will want the 5 key actions as a starting point but when a task within the flow calls for another action the user has direct access within their context to that action instead of having to navigate to a top-level.

Peter’s journey below walks through a scenario of finding a beautiful waterfall and then being inspired to share it with the group of friends he is camping with.

Section #2: Concept

Information Architecture

With the discovery completed and journey maps to help inform us of the ways the users will flow through the Adventure Together app, we laid out the information architecture as seen below.

When thinking about the IA of the app we have divided sections into two sets: actions while in an event (which intermingle often) and actions while outside of one.

Concept Wiring

When preparing the concept wireframes we explored accessing the app from two starting points based on whether an event was active or not. If a user is taking their phone out and accessing the app while an event is active they are starting within the event view and would need to navigate out deliberately to the top level if they needed to access actions there.

If the user was not in an event we present a different set of flows and navigation. This lends to the previous key goal of the event and the “event mode”.

Section #3: High Fidelity

Final Concept & branding

With our initial research complete and the features formed from the criteria defined previously it was time to visualize the final product and create the hi-fidelity mockups needed for development.

With the importance of the defined “event mode”, we decided it would be a nice touch to use colors of the event to fill the background while within an event so we could re-enforce the concept subliminally while the event was active and the user was participating.

Section #4: Concept and & Design Complete

Findings & Discoveries

With the app having the unique concept of a time-based period with which users would be in and out of events we found that creating a design that presented a different state for this was a really great way to support the concepts we were trying to convey.

Originally, the assumption was that the smartphone functions were the center of the actions but this complicated the design and would have the user always changing settings and approving requests. Keeping everything within the app and having users decide initially the access smartphone functions in or out of the app proved a simpler approach in the end.

Additionally. we also assumed the use case was that only one event would be happening at a time. However, through conversation with users, it was discovered that events happening during a “parent” event would also want to be planned as well.

One good example was while camping a group would want to plan a day trip to a local town or some an excursion to a national park. This should be easy to arrange and allow a relationship with the currently ongoing event.