The flavor of a memory | WedSnap Case Study
Megan LeAnne | UX Designer
THE CHALLENGE
While some call a wedding, “The Best Day of My Life,” there are other titles we could consider appropriate:
From cakes to flowers to food menus, couples bear loads of responsibilities. The memories that always seem to stick, however, are the special ones:
the shared looks across the room, the first dance, two families sharing the same room for perhaps the first time ever.
How do we capture these memories?
Most often, couples opt to hire a photographer. There’s only one problem: one person can’t be in the right place at the right time for the entire evening. What’s more — a stranger doesn’t know what photos might mean the most — what small moments would be worth reliving.
This problem led to our team of five being tasked to design the solution: an iOS native application for storing all wedding photos in one central location. These photos, taken by wedding guests, would be uploaded to a database in real time.
The true question — how do we create a nostalgic, collaborative, and multi-perspective photo album just for the bride and groom?
We had four weeks in total (October 1 — Oct 29) to research, design, build, and test our solution.
DESIGN PROCESS
The Team
Our team consisted of three designers and two developers:
Designers: Eric Cottrell | Sean Rockwood | Megan LeAnne
Developers: Markus Varner | John Tate
My Roles
Forming a Blueprint
Being a new team, I knew that the first and most important step was to set up expectations. I drafted a “Team Norms” document and asked everyone to share their needs for workflow and any boundaries surrounding communication. Then, I led the team in a discussion about how we communicate: how can designers share ideas with developers most effectively, and vice versa? I also created shared documents on Trello and Google Drive to increase transparency.
During this time, the design team identified two major competitors that seemed to be addressing the same problem. We decided to conduct usability tests on their products to understand what was working and how we could improve upon those experiences. These tests revealed the following pain points:
Assumptions
Once we had established our communication channels and benchmarked the market, it was time to get to work.
Though both of my design teammates were married, they were still uncertain about the scope and intricacies of the problem. We began by identifying and challenging our assumptions about the people we wanted to interview. These included:
Research
Our initial interviews were largely focused on empathizing:
What is the emotional importance of wedding photography?
What are the behaviors surrounding photos from a wedding?
Our interviewees included married couples, brides-to-be, and those who have attended weddings in the past. We also sent out a survey to friends and family members.
We asked questions such as:
These interviews highlighted the following data about behaviors surrounding wedding photo sharing:
- Most people found that the process of setting up photo-sharing accounts (hashtags, dropboxes, group texts) was too much work. What’s more, these mediums diminished the photo quality.
- Most people didn’t even remember they took photos, or if they did, just sent them through a text message days, or sometimes months later.
- A few interviewees mentioned that the guest photos they did receive were of poor quality, and they hardly ever saved them.
After countless interviews, we began wondering what we could do to make the app experience more valuable. It needed to be better than setting up a hashtag, but without too much cognitive load for the users. It also needed to focus on the emotional experience of sharing memories; quality photography was not our goal.
Solving the Right Problem
Nearing the end of the week, we took some time to reflect on the data and consider our initial project goals. We realized that the problem wasn’t that we needed a way to share the photos. The problem was: the experience of downloading an app for a wedding last-minute is annoying.
Another pain point in the wedding process seemed to be cropping up in our interviews: collecting RSVPs. Over and over again, brides complained about never knowing how many people would show up, and the stress of planning for the unknown.
We realized that in order for our solution to be effective, it needed to address the goals of the couple AND the wedding guest.
After a long week, we compiled our interview data and drafted the two user personas.
Claire & Jackson need an easier way to collect their RSVPs. They want to experience as much of their wedding as possible, but don’t want the hassle of planning everything themselves or the expense of hiring a professional.
Jason perpetually forgets to RSVP, and always has to look up the wedding information last-minute. He wants to support his friends and see them face-to-face for their big day.
User Storyboarding
The next step in our process was to storyboard with our developers. This process helped us to collectively determine what features were the most valuable for both the couple and the guest.
We agreed upon a feature set that was sensitive to the constraints of both design and development:
- Claire & Jackson use the application to collect RSVPs
- Claire & Jackson are able to delete any photos that end up in the final album as a second barrier to inappropriate content
- Jason uses the application to submit his RSVP (eliminating the last-minute download)
- Jason is able to see what photos he took natively before they upload
- Jason is given a time window (3 days) to delete any photos he doesn’t want seen by the couple
- Jason is incentivized to allow two notifications, one for taking photos at the wedding, and one the day after to remove any unwanted photos
The storyboarding process also helped us to understand the unique time logic required for the application’s development.
The views for each user would evolve in relation to the date of the wedding:
Low Fidelity Ideation
While the developers got to work on the build, we began sketching out potential solutions. We started by individually drawing out specific user journeys, then brought them together to compare notes.
I started by sketching out the Guest Invitation view, followed by the RSVP process.
The next day, we compared our ideas and began collaborating on the main user journey.
We had questions about the best order of content, such as:
Not knowing the best way forward, we resolved that our users would show us in testing.
Onboarding
We prototyped our onboarding experiences based on the two personas.
- The Account Creator
Our initial solution allowed the user to first create an event, then create an account to save the event. All testing feedback was useful as we began our next iteration:
- “The progress bar looks like buttons!”
- “It doesn’t make sense to create an event without an account.”
- “How are they validating my device?”
And most significantly…
“So when does my partner get to add their contacts?”
During the first phase, we hadn’t considered that each person in the couple would want the invitation functionality. We discussed this challenge with the developers. Our conclusion was to have two separate invitation codes sent: the fiancé code (which linked to the account), and the guest code (which linked to the event). This way, the couple could share the account and invite guests from both devices. This revealed the need for an extra onboarding experience.
After what seemed like a resolution, we tested two more rounds of user flows.
2. The Fiancé
Because the fiancé didn’t create the event, their onboarding was much simpler. We were solely concerned with communicating their account information (shared couple password), and how to invite guests from their contacts.
3. The Guest
The guest’s onboarding presented its own set of challenges:
When one of the main values of your application involves push notifications, how do you ensure the user will WANT to say yes?
In testing this wireframe, users repeatedly opted out of notifications. Over and over again, without reading any text, users said no.
We realized that our design needed three major qualities to be effective:
Users wanted to establish an emotional connection before agreeing to out-of-app communication. This connection would largely depend on the timing of the ask.
We couldn’t prompt them to agree to notifications on the first screen — it was too soon. We also couldn’t prompt them after the onboarding process — it was too late. It had to be in the perfect spot.
The feedback from the first rounds of testing was crucial before executing our high-fidelity designs. We felt confident moving forward that our narratives were, if not perfect, at minimum creating a valuable and intuitive experience.
Expect the Unexpected
As we handed off our designs to developers, however, we faced another challenge.
We were too busy pushing to finish the product. Predictably, this push caused us to overlook important communication. We never walked the developers through our wireframes. Instead, we made the faulty assumption that they would let us know if there were problems.
This gap in communication led designers and developers to build out two different versions of the application. Once we discovered the issue, we had to regroup with compassion and focus.
We walked through the prototypes, discussed the solutions, and resolved with these compromises:
- Instead of verifying the device through an SMS code, the account creator would use an email account to sign-up.
- In order to link the couple accounts, adding the Fiancé would need to happen as part of the account creation (as opposed to generating a unique code).
Considering these changes, we developed a new onboarding architecture for each user:
With clear and unanimous team agreement, we rebuilt our wireframes.
The Design System
All three designers agreed that clean and minimal UI was best. Because the onboarding was so complicated, we wanted users to feel at ease once dropped into the main navigation.
We agreed to use Material Design to style our application. We also relied heavily on gestural swiping and tapping for our interactions. In addition, we created small illustrations to add flavor and tone to otherwise empty spaces.
The Navigation
Originally, we aimed to keep our three navigation views (Wedding/Guests/Photos) the same on both the guest and couple side. After testing this solution, however, we had to make a change.
Guests did not understand “Guests” as the place to edit their RSVP. When we tried out “RSVP,” couples did not understand it as the place to view their guest list. We consulted with the developers, and agreed that using two navigation bars was the best solution.
Refining the Tone and Copy
While my teammates were developing the logo and style, I focused my energy on the copy. I wanted to ensure that our copy was tonally consistent.
I began by reading articles from Wedding Officiants. These articles explained their process for developing the right tone in their ceremonies. What seemed unanimous was the need for warmth, joy, and easy-to-digest language (with a bit of playfulness dashed in). It also seemed important that our app avoided ostracizing any specific faith, culture, or spiritual groups.
This was especially relevant when designing the copy for error messages and value propositions.
While I aimed for a playful tone, testing feedback suggested that users wanted to know what the error was first and foremost.
Humor needed to take a backseat.
Testing the Outcomes
We are waiting for our developers to finish their build of the final design. Once we hear back, we plan on following up with another round of usability testing. Check back to see more!
Personal Retrospective
As designers, unpacking our assumptions about a project can be an exercise that extends beyond the project itself. I learned to challenge my assumptions about those I work with, myself included.
Learning about my teammates helped me to listen more and to recognize when my own biases were leading me astray.
Given more time, I would have asked the developers more questions along the way. I would have asked what was important to them, how the database operated, and how we could consider those needs as we designed our solutions.
Thank you for reading!
Feel free to connect with me on LinkedIn and view my Portfolio.
