Case Study — Integrating an event feature into Fandango’s App

Fandango is one of the big names in buying movie tickets. They have a website and mobile app. The gist of Fandango is that you can buy a movie ticket and ditch the lines at the box office. The company first opened in 2000. A cool little fun fact, Fandango was acquired by Comcast in 2007! They have been making lots of business-y moves since then and are constantly trying to innovate ways to keep up with the ever-changing movie market. Since, as you know, movie-goers are finding new ways to watch content.


1.0–My role

My main role was was as the Project Manager working in a group with two other UX designers. This project took two weeks to complete. My role within the group consisted of:

  • Organizing and keeping track of team progress
  • Brainstorming together to come up with design solutions
  • Designing the mobile prototype in Sketch
  • Conducting user testing

1.1–The goal

We were given a brief for the type of feature we were to integrate into Fandango. This was the goal:

Fandango has decided to expand their market from movie tickets to purchasing tickets to concerts and local events. Fandango wants to build a service that notifies you of events happening in your area, allows you to easily purchase tickets, and then use a digital pass to attend the event.

So, some of the main questions that popped into our heads were:

  • how do we integrate this feature into the existing brand?
  • How does discovering events differ from movies?
  • What are the differences between movies and events?
  • Who are our users and how do we meet their needs?

Keeping these questions in mind when approaching research was important.

2. Research, research, research

2.0–Who are our users? Let’s interview them!

We first started by putting together questions for a screener survey. The goal of the screener survey was to gain some insights into how people discovered events, whether it be by word of mouth or social media, and to find users to interview that were already familiar with purchasing event tickets. Finding out these insights would begin to give us some inspiration and ideas for the design solution later on.

Some of our findings from the screener survey

We got some good feedback for our screener survey, finding out that 87% of people did share events through word of mouth or social media, and as expected, Ticketmaster was the most common means for purchasing tickets at a resounding 92.7%. We then selected 10 users to interview one-on-one.

Interviewing with a user selected from our screener survey

2.1–Takeaways from our interviews

Interviewing the users was a fun experience, especially since the topic of our interviews, concerts and events, is one of a happy tone. When it came to finding events, 80% of our users depended on social media. Also, we discovered that users either had no issue with using their smart phone for digital tickets, or that they preferred a physical copy of it, either by mail or by printing it out at home. When it came to this, it was interesting to see that a female majority preferred having the physical tickets. Additionally, it represented a sentimental value to them, so it made sense.

2.2 — Spotting trends

From the user interviews, we then synthesized the data into findings by using the method of affinity mapping. Affinity Mapping is a visual aid to spot out trends much easier–typically using post-it-notes and grouping them together. It becomes easier to see common trends. Although, the post-it-notes really insisted on falling off the wall, but I digress.

Some of our Affinity Mapping groups

Based on our findings, we identified three different archetypes of event-goers which we titled–the active seeker, the passive attendee, and the purely social attendee. Connecting the dots from our user interviews to the affinity mapping, we discovered that our users fell into these archetypes:

  • Some users were passionate about finding events and going to them
  • Some users loved going to events but needed a little incentive to go
  • some users just didn’t go unless they were reminded from friends

We created these personas based on these archetypes that would give the user an identity. I’ll explain the user personas in further detail in the next section.

2.3–Creating user personas

User personas are users created based on common threads from the interview findings. Although fictional, these people bring life to the user we are designing for. As mentioned earlier, we identified three types of event goers.

Our three personas–Jacob is our main user while the other two are still considered throughout the design process

Our primary persona, Jacob, is a kick-ass guy that loves to hang out with his friends, and is the kind of person that knows what is going on in his area. He influences his friends to go to events with him, and he is tech saavy and excited about technology. I’m sure you have a friend like Jacob!

We consider him our power user in relation to the feature we are implementing. His needs will be valued the most, while Shannon and Victoria’s needs will still be considered during the design process.

2.4 — Competitive Analysis

One of the UX Designers from the team handled the competitive analysis portion of the project. The analysis would aid in design suggestions for how we could display events. We identified three competitors we wanted to investigate further: EventBrite, LiveNation, Stubhub. We identified these competitors through our screener survey. If you’re asking yourself why didn’t you choose Ticketmaster? It’s because the app was down and not working, so we decided to go with EventBrite instead, which is actually owned by Ticketmaster. We even tweeted at Ticketmaster with concerns about the app not working–no response.

Some of the main takeaways were:

  • All of the apps have a similar checkout process
  • Digital tickets were standard
  • Events are recommended/personalized to the user
  • Social media is used to share events with friends
  • The option to add to calendar is always present

Some of these main takeaways were particularly important to us, especially when it came to how our users felt about sharing the events. Unlike movies, our users expressed the need to be able to share an event before buying a ticket.

2.5–User Flows

We created user flows for each of the competitors. User flows are steps in which the user will take for a certain task whether it be discovering a product or purchasing something.

I chose to look at StubHub’s mobile app on-boarding process. But little did I know, I was going to accidentally purchase a $300 Yankees ticket. I went through the whole on-boarding process, continued with buying the ticket, and then tapped “Buy Now” without realizing it would purchase it. I was unable to return the ticket and had to re-list it. I was panicking since I’ve never sold a sports ticket before. It sold on the day of the game though. I was actually going to go to the game if it didn’t sell, as a consequence for my foolish mistake, but, I would’ve been extremely bitter inside.

Here’s a look into the process of my $300 mistake, with a wireframe:

2.6–Feature Prioritization (using the MOSCOW method)

Moving onto feature prioritization, we wanted to hone in on which features we would actually implement into our design without developing featuritis (the disease of implementing too many features at once) — A disease we certainly wanted to avoid.

The MOSCOW method is a a form of discussion, by visual guidance of 4-columns that you place each feature idea within: Must have, should have, could have, and won’t have.

Here’s the chart we came up with:

We referred to this chart when drafting up our initial sketches. We knew we were going to include the must have features, though. The must have features were necessary in order to meet our goal. Out of all the other features, we chose to include the “related events” from the should have column because our competitors had it.

3. Solution

3.0–Overview of our solution

We started our solution process with sketching as a team, then coming up with a digital prototype in Invision to test with. We went through 3 iterations based on testing feedback.

3.1–Design studio as a team

Design studio is a cool practice for rapidly ideating designs. With your team, everyone take 10 minutes to sketch out their ideas. Then, each member present their sketches for 3 minutes without interruption. Interestingly enough, some of us sketched out the same ideas.

Here’s a link if you would like to read about Design Studio further.

3.2–Digitizing the sketches in Sketch

Initial Version — some detail is omitted

I designed the prototype in Sketch. The initial prototype was designed to be medium fidelity. I designed a few of the key screens and then we conducted user testing with Invision.

3.3–Information Architecture

One of the main changes for our solution was with the Information Architecture of the app. We needed to add an “Events” section to the app, but wanted to integrate it without much hassle. Our solution was to move “Account” from the toolbar, combining it with the “Messages” on the top-left.

Why did we do this? During our interviews, we asked them about the Fandango app, and no one understood the meaning of the message inbox within the app. One user specifically said “I hate this, everytime I open the message inbox to get rid of the annoying notification badge, it’s just a promotion! Not even an actual message to me.”

Before (left) and after (right)

3.4–Proposed Fandango appmap

As explained above, we integrated “Account” with “Messages,” clearing up a space on the toolbar to add the “Events” section.

Appmap for our Fandango solution

3.5–User testing and iterations

We went through 3 iterations of our prototype. Each iteration, we tested with 3–5 users. We asked our testers to find an event and then purchase a ticket for it, find the ticket in their purchase history, and share the event and add it to their calendar. Here are the changes for each iteration round, annotated in the photos below.

As a reminder, the features we included were:

  • Share through social media: A need expressed by our users
  • Add to calendar: A need expressed by our users
  • Wallet app integration (already exists in Fandango)
  • Filter for events: Re-organize the filters for events
  • Related event: Found through our competitive analysis
Iteration round #1
Iteration round #2
Iteration round #3

4. Invision Prototype

I created the final prototype in Invision. Invision is a powerful online prototyping tool — it lets you create clickable prototypes with ease!

Final prototype

5. Next steps and closing thoughts

User testing for the desktop version of Fandango would be the next step. We primarily focused on designing for mobile since part of our goal was for the user to have a digital pass to attend an event. We had some really awesome ideas for this, too many actually, but we settled with the minimal viable product so that we could successfully accomplish our goal. Incorporating more details into the prototype, adding some of the features from the Won’t column of our Feature Prioritization would be some of the next steps, too. It’s okay if you don’t include everything initially, it’s a process that shouldn’t be rushed.

Working in a group can be quite rewarding and challenging at the same time. I enjoyed being the project manager, and it’s definitely a role I feel comfortable and confident doing. Admittedly, I can be overbearing at times. This project helped me figure out new ways to keep morale up which is critical in having a team perform to the best of its ability.

Like what you read? Give Kimberly Sola a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.