Redesigning Sofar’s Event Pages

The Challenge

Besides achieving a higher completion rate from entering the page to successfully purchasing tickets, the secondary goal of the redesign was to give the pages a new fresh look that redefines Sofar’s visual identity.

Before I dive into the core problems identified during the project, let’s get an understanding of the design context first.

About Sofar

Sofar offers secret intimate music events in over 300 cities around the world. Why secret? Because the venue is kept secret until one day before the event and users don’t know who is playing until they arrive at the show. Why intimate? Because the concerts are held in small venues and living rooms with little capacity.

Sofar events are held in small cozy venues, giving a stage to emerging artists.

How ticketing at Sofar works

On the event pages, users get information about a given Sofar event and can acquire tickets for it. But not only the concerts are slightly different compared to common gigs, also the way ticketing works differs from other websites and apps: At Sofar, users can’t buy tickets straight away, but have to apply for tickets. If being selected, users have to confirm their place on the guest list, otherwise it’s given to someone else.

Sounds complicated? Redesigning Sofar’s event pages was indeed the most complex design challenge I’ve solved so far. Let’s have a closer look.

The Approach


Understanding the underlying system

To be able to design the user-facing side of the ticketing experience, I had to understand the technical environment and how things work behind the scenes. Looking at the flow chart below, it quickly became clear that there are lots of different states and scenarios I will have to take into account.

Overview of different states within the same event page flow.

One reason for the variety of scenarios is that Sofar uses different ticketing models in different cities:

  1. Fixed price tickets + online payment (London + some US cities)
  2. Pay what you want + online payment (all UK cities and US cities except fixed price cities)
  3. Donation-based tickets + payment at the concert (all other cities)

Although changing ticketing models and payment systems was not in scope of the project, the redesign aimed to simplify the current process and improve information consistency across all ticketing models.

Investigating the problem

I analysed the current user experiences and gathered information and results from previous research and user testing sessions. Apart from the visual design which didn’t look like 2017 anymore, the following issues turned out to be the ones that need fixing:

  • Lack of consistency across ticketing models
    Due to the use of different ticketing models in different cities, users were confronted with different designs when they looked for gigs in London versus in Berlin. This didn’t only result in an inconsistent experience for the user, it also increased complexity for design and development when relaesing new features.

  • Confusion about the Sofar process
    As described above, users have to apply for tickets instead of buying them and will receive the event address only the day before the event. Many users didn’t understand this process, resulting in low ticket confirmation rates and a large number of customer support queries.

  • Poor information hierarchy
    A reasons why there was a lot of confusion around getting tickets is that information was not very well distributed and displayed throughout the flow. Users were often overloaded with information not relevant at the given situation whereas important details were easy to overlook.
Sofar’s event page design before the redesign

Defining principles for the user experience

Based on the analysis of the existing design and its issues, I defined some principles the new design should follow to avoid those. They became a helpful resources later in the process when making design decisions and remind a little bit of the 10 usability heuristics by Jakob Nielsen.


Declaring assumptions and writing the problem statement document

The identified issues and UX principles in turn led to hypotheses we wanted to validate through testing and experiments. Based on the Lean UX methodology, I created a problem statement document capturing all assumptions we had around the problem and possible solutions. It helped align the team and write a testing plan.

The ingredients of a problem statement document, own graphic based on Lean UX

Getting into the habit of writing a problem statement document was a key element of the user-centred design process I introduced at Sofar Sounds. The event page redesign project was seen as an opportunity to test and refine this process.


Designing the information architecture using the UI Puzzle technique

After doing the research on the current design, it became clear what information was needed to help users accomplish their task of applying for tickets. We had to do a better job explaining what Sofar is, how ticketing works and what the next thing is the user needs to do.

Now I had to bring this information into a clear information hierarchy. For this task, I used an exercise I came up during another project. I like to call it UI puzzle. All you need is stickies, sharpies and scissors for three simple steps:

  1. Sketch: Draw every component on one sticky (navigation, buttons etc). Duplicate any components you need several times (e.g. images, copy).
  2. Cut: Crop and cut out components if necessary but make sure they are still sticky
  3. Map: Stick post its on the wall and move them around until a good information hierarchy is achieved.
The information hierarchy for all states mapped on the wall.

This method which borrows the principles of Atomic Design works well for several reasons:

  • Dev-friendly: The designer thinks in terms of components from the very beginning which leads to consistency, reduces complexity and encourages reusing elements.
  • Fast: Moving post its on a wall to explore multiple solutions goes much faster than sketching wireframes for every single combination.
  • Collaborative: The team can gather on the wall, move stickies around and find the best solution together. It’s like a whiteboard session but without accidentally erasing screens with your elbow.

From stickies to paper sketches and wireframes

Although I found paper sketches too detailed when it comes to high level prioritisation of content and components, they are inevitable when it comes to rapidly creating wireframes for responsive web designs as well as more detailed interaction design.

A full book of paper sketches for the desktop design

Making the most of Nested Symbols in Sketch

Working on a complex project as this one, keeping designs easily changeable and adaptable is key to avoid hours of repetitive (and super annoying) work. I created Symbols of every component I designed and used them as nested symbols in other symbols.

Due to the number of states I had to design, multiple screens emerged seemingly automatically. Using Symbols helped me to keep updates efficient.

However, it took me some time to organise the symbols page and it’s hard to keep it organised. I found plugins like Rename It and Sort Me helpful but they have their limitations, for instance Sort Me only sorts artboards in the list, not on the working surface.

Keeping symbols organised using ‘/’ in the artboard title.

Running design critiques with the team

Collecting feedback from different disciplines, including engineering, product management, marketing, customer support and other stakeholders works as an important sanity check. Nobody wants to wast users’ time by testing designs which are neither technically feasible, nor desirable from the business perspective.

Printing out designs and putting them on the wall made discussions easier and created a great setting for collaboration.


Recruiting the right users for the task to complete

I wrote a testing plan to ensure that each user type (extreme user, casual user, new user) and each device (desktop, mobile) are equally represented for each ticketing model. To keep it as natural as possible, existing users were recruited from cities which use the given ticketing model, which resulted in a mix of remote and in-person interviews.

Since confusion around ticketing was one of the main issues identified in the research phase, I recruited more new users to test if the design supports understanding the ticketing process for people who haven’t bought tickets on our website before.

All in all, we tested with 15 users, 5 for each ticketing model by following the rule of of 5.

Creating clickable prototypes with Marvel and InVision

For the moderated testing sessions, I created clickable prototypes for mobile in Marvel, and for desktop in InVision. Each ticketing model needed to be represented by a prototype, so that overall six prototypes (3 for each platform) were created.

Clickable prototype created with Marvel

Conducing tests and iterating on the fly

After only a few tests, it already became clear what the main issues are, so we wanted to use the remaining sessions to test different solutions. I incorporated what we learned into the prototypes after every 3-5 tests, and was therefore able to test variations of certain design elements.

To make sure feedback could be processed properly, I used Lookback to record in-person interviews and ScreenFlow for remote sessions.

Lookback lets you record the phones’s screen and the webcam simultaneously on your Mac.


After the designs were finalised and development work had already started, there were still a few things to do. Two of them were creating icons and animating transitions which were less important in the rapid prototyping stage.

Creating our own icon set

The icons used in the design got considerably good feedback during testing, but they were grabbed from other resources we didn’t have a licence for. The FontAwesome icons we used on our site had been practical, but didn’t match the new design language anymore.

Hence, we decided to create our own icon set that can be easily expanded when new icons are needed. We used the Material Design icon grid to make sure all icons look consistent and decided together with the development team to keep all icons as simple svgs that work well with code. Since Sketch sometimes causes issues with exporting svgs, I kept these helpful tips in mind.

Icons based on the material design icon grid

Designing transitions using Principle

Although micro interactions and transitions should be already considered during the exploration phase and not just at the end when the design is finished, animating designs takes time which shouldn't be spent until it’s clear how the overall interactive flow will look like.

One feature which users found very useful during testing was the possibility to send tickets to a friend after the purchase. However, it wasn’t clear to users how to send the ticket and when it was successfully sent. This is where transitions become an effective design tool: They give users clear feedback on the action taken and the current status.

The button changes its label, telling the user that the ticket was successfully sent.


Efficient dev-design collaboration in Zeplin

To ensure a smooth developer handoff, Zeplin was our tool of choice. Besides the advantage of having all designs in one place and accessible for all team members, its commenting feature made it easy to answer questions, guide discussions, and find solutions together without having to run a meeting all the time.

Zeplin automatically extracts specs like sizes and colours.

The Solution

As identified in testing, the new event page design solves key problems with the previous design, like a poor information hierarchy and a lack of contextual guidance through the Sofar process. This was achieved by following a user-centered design approach I established along the project.


At the same time, redesigning Sofar’s event pages was a highly complex task due to a variety of scenarios and unreliable content managed by local city teams. The more this complexity pushed me into details, the easier it was to lose sight of the big picture. (I wrote a blog post that covers my experience more deeply.)

Hence, as in every project, the biggest gain are the lessons learned:


Break big projects into small pieces

Complex design challenges require the involvement of different disciplines, most importantly product management and engineering in alignment with business needs and requirements. The designer must not be left alone during the crucial part of planning and prioritising work. Designing and shipping smaller pieces also ensures that development is involved in the design process early on.

Start the project with high level ideation

Design the big picture before getting lost in constraints. Otherwise your creativity will be limited and you will be only optimising what’s already there instead of redesigning the experience. Involve your team members in these sessions to benefit from their creativity and product knowledge, especially if you are new to the company.

Don’t postpone user testing

Show sketches to people in the team and test with users early in the process. Low-fidelity designs encourage more honest feedback and discussion than a polished prototype that seems finished. Never wait to do user testing even if the design challenge is very complex and new issues evolve all the time. Instead, break the project down into smaller feature sets and test one at a time.