Zoosk Subscription Bundles Case Study
Project Background:
The store bundles project focused revamping the Zoosk store to allow users to purchase a bundled subscription.
My Role and Timeline:
I was the main designer on this project and the project timeline was 1 month.
iOS, Android, Web, UI Design, Interaction Design
Project Goals
↳ Revamp the Zoosk store
↳ Clearly example the benefits of each bundle plan and make it easy for the user to compare plans
↳ Reduce the friction when purchasing on Zoosk
Software:
Getting Started
Define user flows
One of the first things that we focused on was to define the different sections of screens within the iOS app:
↳ Speaker Profile Onboarding
The speaker profile onboarding essentially is the collection of the information that will be displayed on the speaker's profile. The speaker's profile is viewed by event organizers who are able to filter for speakers based on their background and content the
↳ Opportunity Flow
When an event organizer send a speaker a request to speak at an event then the speaker must go through the opportunity flow. This flow is made up of the opportunity view with information about the event. A send terms form that the speaker can input and a decline confirmation screen if the speaker chooses to decline the invitation.
↳ Speaking Opportunities
The speaking opportunities screens are made up of information about upcoming and past speaking engagements. Also in this flow I had to account for the empty state. This means if a speaker logs into the app and doesn't have any speaking opportunities upcoming or that had occurred.
↳ Booked Event Flow
After a speaker is booked for an event there is a confirmation email sent to the speaker. The speaker is also able to view the details of the speaking engagement on a web app and the iOS app. Once the event is completed the speaker is able to review their experience.
Iterating on Onboarding Flow
Mapping out Onboarding
The first iteration of the onboarding flow was the information needed from speakers broken out into individual screens.
Start Prototyping
I started prototyping early on during this project and it allowed me to quickly navigate through screens and iterate on flow quickly.
I used Framer Classic to create prototypes. Framer Classic has a built in a flow component that makes it really straightforward to make forward and backwards links between different artboards.
Define Components Early
Agreed upon styling both saves development time and ensures consistency in the app design.
While designing the iOS app I ensured that all components used the default iOS system text styles and documented each custom component in order to help speed up development time.
I designed these components in Sketch and made them into symbols components to keep my Sketch file consistent. I then worked with our iOS developer to map the styles I had created in Sketch into his Swift based repo.
Having components that match in both the design file and the frontend implementation saved us time during QA sessions. Designs matched the Sketch file because constraints were taken into consideration during the time we styled the components.
A clear and modular onboarding experience
Landing on a design that scales for future use cases
After different iterations of the onboarding experience were explored, I came to the conclusion that the onboarding experience needed to be modular and come across as simple to the end user. This meant that having a continuous experience with a progress bar might be too overwhelming.
The onboarding experience that I designed allowed new users to see all the information required to complete their profile but also allowed the user to skip the onboarding in general. Skipping the onboarding meant there would be a reminder component that showed up in different screens of the app which encouraged users to complete their profile.
Accept Speaking Opportunity
Landing on a design that scales for future use cases
One of the main experiences in the app is when a speaker receives a speaking opportunity.
After receiving a speaking opportunity the speaker can accept or decline. If the speaker declines an opportunity there is a simple questionnaire required. But if the speaker decides to accept a speaking opportunity, there are number of scenarios and UI elements that could differ depending if the speaking opportunity pays for speaking fees and / or expenses. I mapped out all of those different scenarios for the iOS developer on my team.