iOS Part I: Event Details Redesign
The iOS team goal when I joined was to increase the events sent on iOS. After some user testing we noticed large dropoffs during the event details portion of the create flow, after card customizationg and before adding guest emails. Considering engineering resources, we decided to make Event Details our focus.
The Original Experience
Originally optimized for the iPad, this information-intensive step of the user journey was frustratingly fitful, taking users into different views that slowed down entry. With other issues like small touchpoints, illogical order of operations, lack of hiearchy, mysterious action buttons, the old event details flow was ripe for a rethink.
In order to make it clear to the user what information they needed to fill out, I linearized all the required fields so it resembled more of a traditional table view. I also collapsed the advanced options that we offer on desktop, since events created on mobile are generally more casual.
Integrating Smart Search
One of the obvious features we wanted to add was smart search for event location. The backend was already set up for our desktop web app so traslating the work I had done from there to mobile was pretty straight forward.Since a lot of hosted events on mobile are private parties, we wanted to make it easy for a host to edit search results to add apartment number or completely custom address entries.
Putting it All Together
The vertical slide felt faster than the traditional sideways slide transition. This also removed contextual confusion from the user of moving “right” to the next step of the process. This contributed to the goal of reducing friction in this step to move the user to delivery.
iOS Part II: Upcoming Events
Because of technical constraints, our goal over the next quarter shifted from increasing event creation to increasing user engagment within the app. A major friction point for hosts was finding their upcoming events within the app. If we could contextually surface users' events on the homescreen, our bet was that it would increase overall time in the app.
I created a matrix of user needs based on whether they were hosting or attending an event, where in the event timeline the user was accessing the app, and what actions the user has already taken on the event page.
Once we had our user stories, my PM and I defined some feature goals to help give more shape to the feature the team was going to build.
Mapping the CTA's
We wanted to keep the actions straightforward for the Host or the Guest, so we used the user journies we created earlier to define a set of CTA's and an order in which they would appear depending how close to the date of the event.The scope of this action mapping started large, and once we were satisfied that all the different use cases were satisfied, we widdled down the CTA's to the essential few that we would build into the MVP.
I came up with three different interaction models to surface a user's upcoming event. Because less than 10% of users had more than two upcoming events, creating separate streams for hosted vs. invited events wasn't necessary.
Variations
These were a couple of prototypes I made in Framer JS as I was exploring this option. The feedback I got was while it was lightweight, fast and actionable, it wasn't in the user's face enough, and wouldn't be a dramatic enough way to test our assumption.
Because a complete dashboard page would involve significant development resources and a rearchitecturing of the app, we ultimately chose a model that loaded the upcoming events onto the user's homescreen without an initial tap. While the module pushes the marketing tiles below, they remain accessible as the user scrolls down.
Your Event, When You Need It
In the end we stitched together a seamless experience between the user's homepage and their event. The main CTA on each event card takes the user to a specific action within the event page. We saw a dramatic increase of event page response and prompted us to continue planning utility features within the app.
