How to Improve the Check-In Process of a Dance Center – UX Case Study

Alina Levyshkina
8 min readNov 17, 2020


There’s a famous dance center in Novosibirsk, which has really talented teachers and a fantastic atmosphere. But there’s one thing that ruins the impression — long lines at the check-in. Students have to come 30 minutes before the class, lose 25 minutes waiting in a line, and change in a hurry. For many of the new students, it’s a deal-breaker.

My challenge was to discover the roots of the problem and come up with a sensible solution.

The most visible problem was the lines during the check-in. I decided to be open-minded about it and find out if it’s a problem for the students. During the project, I went through the Double-Diamond process and discovered two more sticking points for the students.

Planning and Conducting Research

Before the research, the main questions for me were:

  • Do students consider lines a real problem?
  • Are there any other problems?
  • If the problem is there, are there any workarounds that students are currently using?
A CSD-matrix to organize my assumptions  and articulate the goals of the research
A CSD-matrix to organize my assumptions and articulate the goals of the research

To answer the questions and validate (or invalidate) my assumptions, I:

  • analyzed the reviews of the dance center;
  • observed students at the center;
  • conducted interviews with 5 students.
I split the student’s journey into hypothesized stages to better understand the process and design the interview

After analyzing the reviews, observing the students in the dance center, and conducting interviews, I found that there were 3 significant groups of students:

  • new students,
  • intermediate students,
  • and advanced students.

My first assumption was that most of the students were experienced dancers. But after the interviews, I realized — people who have some dancing experience in the past (but not much) make up the majority. The other insights suggested that we had to focus on the intermediates. Here’s why:

  1. intermediates are the majority;
  2. attracting new students isn’t the priority;
  3. advanced students are the minority but very loyal. They are OK with almost everything; they feel like the center is their family.

Customer Persona

The target customer persona is a current student who has some past dancing experience but not a professional. Dancing is her hobby, and she doesn’t have a special connection with the teachers. She’s busy and prioritizes her comfort.

The primary target user concluded from the research

Pain-points of the Persona:

  1. The dance center organization
    Long lines and time-wasting, classes are continually being canceled or moved, the receptionists are often rude. They don’t know relevant and up-to-date information. People still love their classes and teachers, but the mess is a big sticking point.
  2. Lack of information about classes
    Because of the constant canceling, people forget about their classes. Will there be a class? Who’s teaching? Is it classic dancehall or female today? What should I wear? What moves to review?
    And the big one: what should I do to get that information?

I found that people do different things:

  • text to the dance group chat,
  • call the dance center,
  • contact the teacher.

But none of these methods is satisfying enough. At this point, for the first time in the project, a need for a centralized hub ringed a bell.

Customer Journey Map

To see the bigger picture of the students’ experience, I converged all of the research findings into a Customer Journey Map. I actually came up with two CJMs — for the new and current students. It helped me see the whole picture, but we’ll stick with the second one as we decided to focus on the current intermediate clients.

Based on the interviews, I described user goals at each stage, their process, and the channels they use. Guided by the research, I came up with problems that the students face at each stage.

Customer Journey Map for the Persona

Key Insights & How Might We’s

The problem matched our original assumption — the students do consider lines a problem. I’ve validated my assumptions with research and also uncovered some unobvious problems. According to the research, the main issues of our Persona are:

  • long lines and time waisting;
  • complicated first interaction: website, the first lesson;
  • lack of information about the past and next classes;
  • not pleasant experience interacting with the staff;
  • no way to keep track of changes in the schedule.

I redrafted problems into practical insights and organized them into groups using an affinity diagramming exercise. From each group of key insights emerged one or two How Might We’s.

How Might We’s (opportunities) that emerged from the problems I found

To decide what opportunities to focus on first, I ran a prioritization exercise.

Prioritization Matrix

Here are the opportunities I’m going to focus on:

  • to help students be on time,
  • to help students know their schedule,
  • to provide information about classes.

Read the whole design brief if you’re interested.

Now it’s time to look for the solution.

Solution Conceptualizing

I ran 2 brainstorming sessions and clustered the insights.

The results of the brainstorming sessions, already clustered into groups

Then I decided to put my ideas in context to see which ones would be the best for the users and how people will use the product. I created a storyboard and validated it with some of the students I interviewed.

The storyboarding sketch showing the key path scenario

Based on the prioritized How Might We’s and the validated storuboard, I started choosing features for the MVP.

Minimum Viable Product

Using the app, a student will be able to:

  • Check-in by scanning a giant QR code on the wall;
  • See their personal schedule;
  • Have push notifications about changes in a schedule;
  • Pay for their classes in the app: by card or Apple Pay;
  • Get notifications when it’s time to pay.
Features that I selected for the MVP

Information Architecture and First Sketches

I hypothesized how people will use the app based on the user’s mental models. I iterated on the site map as I was doing rough sketches.

Work on Information Architecture in progress
Information Architecture of the app
Rought sketches to find the best interface solution

Wireframes and testing


To test the solution early, I conducted a usability test. I created wireframes and connected them into a prototype to test with 5 students.


1. Check in to the Stretching and the Dancehall classes;
2. Check when your Dancehall classes are & who the teacher is;
2. Renew your Dancehall class membership.

In this first iteration, I created very rough wireframes. Rectangles, no pictures, and clumsy microcopy. When I tested them with the students, they found “the app” extremely difficult to relate to.

Rethinking my first batch of wireframes

I also discovered a usability problem with the check-in screen. I knew that some students had two classes in a row, e.g., an hour of stretching and an hour of a dance class. So I hypothesized that it would be convenient to check in to both classes at a time — no time loss!

But the tests showed that people find it confusing and prefer checking in to different classes separately.

“I usually have one class at the evening. Having the classes in a row is an edge case”

How I thought it should work. The test participants were confused

Also, the participants expected to click the card with the name of the class and scan the QR code immediately. They didn’t realize they had to click the Check-in button every time.

“I thought I would click the card and start scanning the QR code”


I improved the wireframes: made them more detailed, adding relevant content, pictures, and fixing usability issues.

Then I tested the second versions of the wireframes with some of the old testers and 3 new ones. The second batch showed that the interface matched the mental model of the students. They easily used the prototype and completed the task.

How students thought it should work
The “Log in” screen and the 4 main screens of the app

What I Learned

This project took me 4 months. It was a part of the UX Design course that I’ve taken — “UX for Freelancers” by Anfisa Bogomolova. Anfisa was mentoring me, and I learned a lot in these 4 months. Here are 3 of the things I

  1. Never start with a solution
    I’d been thinking about this project for a couple of months before joining the course. And if you looked at some of the first notes and sketches I made before working with my mentor, you’d see that I was all about screens and features.
    The trouble is, if you immediately start thinking about solutions, you might end up solving the wrong problem. Which means wasting time and money. We should always validate our assumptions first.
  2. A good idea is rarely your first one
    Don’t get attached to your first ideas, sketches, and interface solutions. The first idea that comes to your mind is not always the best. It’s a good starting point, but it doesn’t have to end there. Think of some other ways to solve the problem.
  3. Wireframes should have content
    Sure, wireframes don’t have to be beautiful. But people simply don’t understand what it is in from of them without content. Content is queen!

Next Steps

The next steps for this project would be:

  • finish the wireframes for the rest of the scenarios and test them with people who fit the Persona;
  • conduct usability testing in context (in the dance center) and see how it works;
  • polish the UI interactions and create a visual design according to the brand of the dance center;
  • measure the effectiveness of the concept.