Duration
1 Week Sprint
Work Type
Case Study
Tools
Miro, Xd, Ps, Marvel
Role
Interaction Design
A photo-editing app wants to pivot from being 'just a tool' to a geolocation based photo sharing platform; an instagram meets google maps for the experience driven, millennial explorer.
The Problem
Gramcity wants to be more than just a robust photo editing solution--they want to create a social platform around discovering, traveling to and sharing unique photo locations.
My Role
I did all the UX and UI design based on the ethnographic and user centered research in the form of persona's and empathy maps.
Process
User & context, task analysis (map), competitive analysis, ideation, converging, wireflows, prototyping, design validation (test), synthesis, usability report.
Constraints
This was a 5 day sprint I used to practice the GV method.
Getting users through the onboarding flow quickly and efficiently is paramount for user retention.
Favoring proficiency (expectation) over efficiency--borrowing from known interaction patterns like google maps, Airbnb and pinterest leverages user mental models.
Flexibility and efficiency of use and google maps UI are leveraged here to allow for waypoint use cases and prevent behavior momentum.
In order to better understand the user, Gramcity provides us with two persona’s Nick and Sarah. Emotionally these two persona’s are very similar as both are anxious about surfacing meaningful photo opportunities. This convergent quality was such that Sarah’s user flow would benefit greatly from Nick’s and vice versa so I combined them into one Persona with two use cases: Planned and Unplanned.
Millennials looking for authentic experiences, self-sufficient, love to learn, explorers more than they are travelers, not generic, don’t want a “packaged deal”, want a story, want to feel autonomous, free, agency.
Using mobbin I looked at different market spaces and the solutions they generated: Pinterest, Airbnb, Instagram, and Google Maps were great sources of usability and heuristic inspiration and gave me an understanding of users' differing mental models while performing tasks like building lists, trip planning, and discovering compelling content.
Trust seemed hugely important to me and at first I thought about this literally--sketching out the way in which users might experience permission requests (1 + 2). Did I need reciprocity to soften the blow? After sketching a short onboarding flow (3 + 4) all the permission customization seemed confusing without a clear value proposition. Trust = utility not transparency. TTV needs to be faster.
The screens below focus on delivering that TTV more quickly and in context.
Experimented with maps and POI or images as POI. Drawer (3) or modal (4).
(5) surfaces POI via a feed (pinterest or instagram). (6) the side feed provides the information in context (recognition rather than recall).
The feed/map should mimic the other. Click on one and the other mirrors or are they independent? Ability to Zoom (8)?
Building off of this idea of fast/utility = trust I sketched out a permission in context (location) dropping people onto a map (screens 1-3) Pinterest's solution to 'pinning in context' with a modal window of floating action buttons seemed like a elegant solution to this problem (screens 4-6).
Based on the research I started generating opportunities in the form of HMW’s. I then placed hypotheses under their corresponding opportunity/HMW. I then placed my low and mid fidelity wire-flows/frames under their corresponding hypothesis:
HMW help our user discover the hidden gems that are most relevant to their interests?
After testing this on friends with paper prototypes it became clear this drastically increased the onboarding time because of choice paralysis. You also need a significant number of labeled/catalogued photos to surface for corresponding preferences--something the platform won't have for a while; In this version filters will be the preferred method. Classic onboarding it is:
HMW help our user discover the hidden gems that are most relevant to their interests?
HMW help our users learn / decide on which hidden gem to visit?
When deciding what needed to be true for this product to work, trust was central. Trust here means: ease of use. To that end I explored how to maintain velocity through a users discovery, planning and navigation flow. Below is V2 of the prototype. To understand how those changes were made see section 5 Usability Test.
Route 1 focuses on discovering a nearby POI and getting to it as quickly as possible in this case by walking.
Route 2 focuses on building a trip comprised of two POI.
The spontaneous route (1) and the pre-planned route (2) align with our persona's Nick and Sarah. It's reasonable to assume that during a "trip" a user might benefit from features associated with either use case so I combined them. Red routes for Route 1 + Route 2 from the prototype are shown below.
I followed the GV sprint 5 act interview. Interviewees were introduced to the market and problem space and the purpose of the interview. Interviewee tasks; 1. discovery a nearby (in Paris) photo opportunity and; 2. plan a photo trip of 1-4 locations on a day in September in Paris. The image below illustrates changes made between prototype V1 and V2.
Problems (1,2,3,4) and corresponding solutions (1a,2a,3a) made between V1 and V2 are illustrated below. In a dendrogram style I only marked a screen if all interviewees had negative feedback. That negative feedback was: a lack of social api login (1), having to choose what type of trip you wanted (spontaneous or planned) (2), asking for location permission (3) before a destination had been chosen (discoverability issues with the modal of FAB's (click and hold) (4).
Based on the user feedback, social API was retained, choosing a trip type (spontaneous or planned) was axed and the modal of FAB's was retained.
Fast a relative; breaking complex tasks down into incremental sub-tasks can have a significant effect on people’s perception of how long it takes to complete a flow.
There's tremendous opportunity for Augmented Reality features using geofencing, location, google maps/reviews api etc. High priority, actionable next steps are listed below.
Future Iterations:
Expanding the Scope:
The next phase of the prototype should be leveraging what we learned in the interviews to refine the sign-in and onboarding process and build out a minimally viable prototype to explore the sharing aspect of the app. Finally, the app (even in prototype form) should be taken out into the wild to see how it enhances or detracts from the experience of discovering things in the physical world.
