Polygon Pop-Up screenshots, iPhone 8.

Polygon Pop-Up

What happened when Brighton’s hottest pop-up teamed up with one of the cities biggest design studios?

The answer was “On the Terrace” – a weekend event that gave some of Brighton’s best restaurants, chefs and producers a chance to show off their skills. But while these functions were a hit with the locals, “On the Terrace” was also the focus of a fascinating, open-ended design challenge.

Create a new digital experience for iOS users.

Pop-up event.

The current situation

Pop-up events hosted by Polygon were hotly anticipated by their customers. Since 2015, they’d slowly managed to gather an impressive following on their social media accounts (Facebook, Twitter and Instagram), as well as their tickets frequently selling out. With an average rating of 4.9 stars on Facebook, it seemed that users had minimal complaints – with many lamenting the fact that Polygon only operated during the summer months.

So why did they need a new digital experience?

Crossed out eye icon.

Company visibility?

Polygon only had two hits on the first page of Google searches. They were also only available through their social media pages, meaning they weren’t as visible as they could have been.

Crossed out ticket icon.

Ticket availability?

Polygon posted events on their Facebook page to their followers – meaning tickets could be prioritised among these users.

These problems seemed to be symptoms of a larger issue – attracting new customers. It seemed that Polygon was a “hidden gem”, instead of one of the “go-to events” of the summer. After all, how would you hear about a Polygon event?

If you or a friend weren’t following Polygon on social media, it was unlikely that you’d know about them or their events.

Customer profiles

To increase my understanding of the types of people that go to pop-ups, I decided to briefly look at the demographics of Polygon’s followers. The insights from this helped form the user personas that were created later in the design process.

Through trawling through the reviews left by customers on Polygon’s Facebook page (and consulting other sources), I discovered three key things about them;

  • they tended to be over 30,
  • they tended to go in groups,
  • they tended to go more than once.

As well as this, some customers recommended getting there early to get seats (although this was probably only for free events). For paid events, the problem turned to getting tickets before they sold out – with previous updates on Twitter indicating that often, places were limited.

The main pain point for customers seemed to revolve around getting tickets or seats, as events were normally extremely popular.

However, customers weren’t the only people with a stake in the solution.

Other stakeholders

There were two other stakeholders who the solution needed to serve – vendors, as well as Polygon themselves. Their needs varied from customers; while vendors would need an easier way to get in contact with the company, Polygon might want more information about their customers (to create better events for them). However, the app wouldn’t be primarily designed for these groups.

Customers would be less motivated than vendors and Polygon, meaning the solution needed to focus on making things easier for them to do.

Considering everything, it made sense for the solution to be an events app – something that listed every Polygon event and their availability, as well as allowing customers to book tickets and manage their bookings. While it would predominantly be focused on customers, potential vendors would also be able to get in contact with Polygon through the app.

The solution

*If there are sizing issues on this page, or if there a blank screen, you can also use the prototype here.

So how did I get to this?

User research

As this was a completely new project, I knew that some form of user research had to be conducted. But with limited time, I decided to focus on the demographics of actual customers, before using these to create personas.

Demographics were used to uncover customer’s general trends, before personas were used to reveal specific problems.

The personas created were inspired by three real Polygon customers. They were;

  • “Ellie”, a 21 year old media arts student,
  • “Faye”, a 44 year old content manager,
  • “Ian” , a 35 year old graphic designer.

From here, ‘job stories’ were created for each persona. The aim of these was to focus on why a user would want to carry out a specific action, instead of what action they would take, as the latter relied on far more assumptions than the former.

Job stories, Polygon users.
Job story ideas that were used to help create the completed user personas.

Basing user personas on real people made identifying what their motivations and creating backstories a lot easier. It also removed some of my own personal bias, which was especially important as I was working solo on this project, and couldn’t bounce ideas off others.

Persona, eleventh-hour user. Persona, foodie user. Persona, idea user.

For the rest of the design, I took inspiration from the “design sprint” methodology – a process that allows teams to develop an idea into a prototype in a week.

Flow maps

The mapping process was different from anything I’d tried before. With a blank slate on which to create a solution, design focus switched to keeping two user actions as frictionless as possible (adding an event to your basket, and the checkout process).

Task flow, add to basket. User flow, checkout.
Task flow for adding items to a user’s order (left), and the user flow for the checkout process (right). An early idea was to ask for reviews at the end of an event (as people would be more likely to give higher ratings due to the peak-end rule), but wasn’t used as Polygon events were usually unique.

Design cues were also included to encourage the user – with the biggest being a progress bar at the top of the payment screen, to visually represent how close customers were to booking tickets.

This process had been reduced to its essentials via a card sort, leaving only three stages (two of which could be completed with a single tap);

  • payment method,
  • payment details (only if using card),
  • order review.
Checkout process, Polygon.
This design aimed to make use of the ‘goal gradient’ – a principle that states efforts increase as we move closer to a goal. It also aimed to give users a sense of progress by showing them what they’d already completed.

Onboarding

Where should the customer registration wall be introduced – on opening the app, before checkout or not at all?

Each of these solutions had a potential pitfall. No registration at all would make some features (such as managing bookings) redundant, while research for my AppyParking redesign told me that making users register before the app delivered any meaningful value would decrease conversion rates and increase user frustration (making quitting the app more likely).

But placing registration before checkout could also have the same effect, as well as distracting the user from the most pressing task for Polygon – buying tickets. And with non-registration not meeting stakeholder needs (customer data), a fourth option suddenly became viable – registration after placing an order.

Confirmation screen, Polygon.
I reduced registration to its key components – an email and a password. By doing this, I realised that users would already have willingly supplied half the required information (their email address, for order confirmation).

With user emails already gathered by the app, the only barrier to creating an account was a password. My hypothesis became that asking for one after the main task of checkout had been completed, not setting overly strict password requirements (minimum length, capital letters etc.), and formatting the choice in a way that made it stand out (a large “create account” button) would lead to users signing up.

Studies suggest that 32% of consumers have stopped creating an online account due to complex password requirements.

Screen sketching

Now halfway through, screen sketching could begin. But what needed to be included on each one?

A quick brainstorm, consisting of information that a particular screen needed, was done for the screens that would be most visited; “home”, “discover” & “event information”, as well as the checkout process. This list was then compared to existing event based apps (EventBrite, Meetup etc.) to identify the differences between the two, before a card sort was used to optimise each screen.

Main user screens, Polygon.
With the landing page needing to appeal to a wide audience, sorting and filtering were included to allow users to manipulate information on this page to match their needs. This was later extended to the “discover” screen.

While most of the sort was standard, it influenced a big design decision relating to the checkout process.

The name and address of the cardholder are used on some e-commerce websites as an extra layer of security. However, this isn’t compulsory, but rather up to the payment merchant to decide on (as some existing event apps omitted this information).

As extra form fields add friction, as well as online shopping abandonment rates being approximately 75%, the decision was taken to remove this to boost conversion, subject to A/B testing. (see note).

2019 UPDATE: With the recent attention on user data & security, in hindsight I'd include the cardholder name/address fields as default, and then test to see if removing them increased conversions by a significant amount - instead of the other way around.

UI and testing

With screen sketching completed, finalised screen designs were created with the help of a design library. From here, I quickly created an interactive prototype with Marvel (an inVision alternative), to test the design with users. A quick heuristic evaluation was also carried out, again using Nielsen’s heuristics to test against.

While the design seemed to go down well, some key changes were made to make it even better. These included;

Menu details

I’d copied the event information from Polygon’s Facebook page – which didn’t have any information about the menu inside. To solve this, a “menu” section was added onto the event information screen.

Ticket availability

With no way of knowing how popular an event was, information about the number of tickets left was added to the options overlay. This ended up acting as both social validation (by showing how many people/friends were going), and created a scarcity effect.

Screens. Polygon app.

Want to read more?