UX Case Study
MOBILE APP DESIGN

ClimbZen

TL;DR

The challenge

Rock climbing is a popular sport that appeals to a wide audience of ages, genders, and capabilities. Like other fitness activities, it’s a way for people to be healthy and work on achieving goals (both solo and in group settings), but its unique appeal is that climbing is as much problem-solving as it is strength.

The goal of ClimbZen was to help experienced climbers get focused on their climbs and mentally frame them in a positive way so that they could physically perform well.

GIVEN PROJECT CONSTRAINTS:
  1. 3-week timeline
  2. Deliverable was a mobile app mid-fi prototype
  3. Users were rock climbers
  4. And that's it!

My role

I really enjoy planning and organizing, so I volunteered to be project manager. I've managed my own projects doing agency work before, but ClimbZen was my first run as a project manager to peers. This was also my first time as a UX Designer working with other UXers, so I was excited to see what we could come up with! I wanted my teammates to feel comfortable with their roles, so I asked them to choose deliverables on which they wanted to take lead. All 3 of the others wanted to be involved with prototyping, so I took charge of user research.

The solution

I put a lot of emphasis on thorough user research to help us clarify the problem and who our users were, whom ended up being experienced climbers with a core frustration: when they fell off the wall because they lost focus. Throughout the design process, it was a struggle to keep user empathy at the top of the team's mind. By proving our user's needs with our research and usability testing, I was able to keep us on track for finding a solution that was in line with their goals.

ClimbZen helps experienced climbers get focused for their climbing session with positive messages and helpful tips throughout the day, exercises tailored to how they’re feeling mentally, physically, and emotionally, and beta maps to help them visualize success before their climb.

User Research

Understanding our users and their needs

Because this project was so open-ended, we needed to narrow it down to a more specific user group and problem space. We started with a proto-persona to guide our research plan, centered around a beginner-intermediate indoor climber, and hypothesized that climbers get frustrated when they aren't progressing through difficulty gradings as fast as they think they should be. We proceeded to conduct 1:1 interviews with 8 participants who climbed regularly. Our goals were to understand:

  • indoor rock climbers’ current climbing habits.
  • their motivations for pursuing the sport.
  • what pain points they may have during the typical climbing session.

Interviews were particularly fun for me; I always enjoy making connections during interviews but this was especially cool because some of our participants were true athletes and discovering their thought process was fascinating. That user empathy really gave me the drive to see this project done well. After compiling our notes, it turned out our hypothesis was totally wrong! Our users were actually:

  • intermediate-advanced climbers.
  • motivated by the mental challenge and problem-solving aspect of climbing, not the grading numbers.
  • frustrated by distractions from being "in the moment" and lapses of focus that cause them to fail their climbs.

So what's the problem?

In other words, our users were experienced enough that it wasn't their physical strength holding them back from their best performance, it was their mentality! This is what I focused on to make our user persona, Taylor; to clarify why she climbs and her need for staying mentally positive and getting in the zone for her climbing sessions; and to keep us on track for the rest of the project.

Ideate

Brainstorming and hiccups

My team members were absolutely brimming with ideas even before we had started research, so I passed on the user persona and left it to them to brainstorm features and prioritize them into an MVP. I was looking forward to the results!... but at this point I realized that my teammates were maybe a little too goal-oriented. Their ideation resulted in an app that centered around 3D body-scanning and AR mapping over the climbing route, and didn't at all address the mental strengthening our persona needed.

I decided to step back in and redo the brainstorm with them to better focus our solution on our users, but I faced some pushback from a couple of teammates:

  • One member was particularly adamant about including "cutting-edge technology".
  • Another member didn't want to end up with a "boring and ugly" product.

I had to figure out a way to convince them that the app didn't need to be cutting-edge or fancy-looking, it needed to help our user. It was honestly super stressful for me to find the right way of talking to them too, because I didn't want to just start bossing people around; I had to make them understand why we had to pivot. I chose to explain "You are not your user. Taylor is," and why (from Taylor's point of view) the current direction didn't address her needs. Luckily it worked!

Brainstorming 2.0 and prioritizing

We were a little bit behind schedule because we had do a second brainstorm, but it was worth reorienting our project direction. To help guide us further, we dove into researching sport psychology and found a key process for athletes to improve their performance:

  • Plan - Analyzing and identifying areas to improve
  • Practice - Doing drills in a safe environment
  • Perform - Applying and solidifying the new habits from practice

Doing this additional research helped us tremendously to come up with ideas that much better addressed the mental needs of our climbers. We narrowed down the features based on value for the user and complexity of implementing within the short timeline. This helped us prioritize what information and screens to include in the user flow, sketches, and wireframes to come.

CLIMBZEN KEY FEATURES:
  • Positive messages and helpful tips (which we named "Lucky Thoughts") sent throughout the day to jumpstart a positive mental framework
  • Suggested meditation, breathing, and other mental exercises to be incorporated into the climbers' warm-up routine
  • Pre-climb quiz to ensure that the suggested exercise addresses the climber's mental, physical, and emotional state at the time
  • Beta maps to help visualize what a successful sequence looks like ("beta" is the lingo for specific direction on how to complete a particular climb)

Breaking down the steps

It was clear users needed to get focused before starting their climbing session. I wanted to map out how ClimbZen would prepare them accordingly and what decisions they might make to help the team design screens, so I made a user flow.

TAYLOR'S HAPPY PATH:
  1. Opts in to receive Lucky Thoughts
  2. Takes pre-climb quiz when she gets to the climbing gym to assess what type of exercise she needs
  3. Follows along with the suggested exercise by ClimbZen
  4. Finishes exercise and navigates to Beta Maps
  5. Takes a photo of the climb she wants to tackle and uses the drawing tools to annotate the climb
  6. With her mind in the zone and her beta visualized, Taylor successfully completes her climb!

Prototype

Turning the user flow into solution sketches

We needed to think through how to solve the problem we found in user research, so we started sketching solutions. We broke up the user flow into chunks for 3 of us to sketch so we could get them done more efficiently.

  1. Onboarding and Lucky Thoughts
  2. Check-in quiz, suggested exercise, and exercise library
  3. Beta maps

The idea was to put the sketched chunks together into a lo-fi prototype and start testing as soon as possible so user feedback could make our solution more robust. Since we were working off the user flow, we already knew what information needed to be included and were able to work fast.

However, we didn't account for how different our sketching styles would be when we came back together. We thought it would be unnecessarily confusing for any testers if the sketches were turned into a prototype as they were, plus we had feedback on each other's solutions that we wanted to incorporate. We decided to turn them into digital wireframes with a single style first. I took this as a lesson learned for the future: when dividing work, take some time to align on output styles first!

Wireframing and more hiccups

One team member was confident in their wireframing ability and volunteered for the job. At this time I hadn't been using Figma or Adobe XD for very long. I thought it would take me way too long to do the work on our already tight schedule, so it was a relief that someone else seemed to know what they were doing.

To be completely honest, I was disappointed when my teammate came back with their work. They had taken liberties to change the solutions we had all agreed on before with the justification "I thought it looked cooler this way." This resulted in wireframes that the rest of us found confusing even as people who should already have known how the app was supposed to work, leaving us even more worried for new users. As much as I wanted to redo the wireframes before moving on to testing, there just wasn't enough time. We needed feedback fast if we wanted to incorporate any of it into the deliverable by the deadline.

Usability Testing

I may have thought the wireframes were confusing, but what about our users? Would they find it intuitive? To figure this out, we conducted usability tests with 5 participants who regularly climbed and watched as they tried to complete the tasks that we set out for them:

  • Navigate through onboarding to the home screen
  • Take a check-in quiz and listen to the recommended exercise based on their result
  • Add a new beta map

Our findings were, unfortunately, as expected. Users were too distracted by the wireframes themselves to give us any sort of useful feedback on the features, or to describe whether or not they addressed the need for mental strength. Two different testers even said "I don't know what I'm looking at. This looks like modern art". Big yikes.

Iterate

Communication snafus while iterating

Since users were so confused over the wireframes, we definitely needed an overhaul. It doesn't make sense, however, to just tell someone "redo them" without giving direction, so I pulled out the biggest issues that needed addressing from our user testing notes by organizing them based on frequency and priority. These included:

  • using images to make things clearer.
  • using consistent color and font to help indicate primary, secondary, and tertiary info.
  • using consistent button and text field treatments to help indicate what's a button and what’s not.
  • fixing the button mapping and adding back buttons.
  • simplifying screens (especially for beta maps) and navigation.
  • fixing incorrect labels and icons.

I showed the team member who did the wireframes the specific points to fix and framed my feedback with "I know you just wanted to make this interaction cooler, but you aren't your user. From the user's point of view they need it to be intuitive, not cool." My teammate was very receptive and was happy to work on incorporating this critique, but somehow we kept misunderstanding each other's design intent. I wish I could have figured out a better way to visually communicate, but you can't win 'em all.

Mid-fi prototyping

With only two days to go before the deadline and not very much progress made on this iteration, I decided it was time to pass the responsibility on to another team member who was excited about prototyping. Since we had so little time left, I worked in tandem with them to design mid-fi screens that addressed the feedback from usability testing. As a result, we were able to deliver the mid-fi prototype in time for the deadline! Phew.

Lessons Learned

This project was a maelstrom of challenges and adapting on the fly!

TIME MANAGEMENT:

The short deadline meant that decisions had to be made quick, so we couldn't take the time to go back and fix mistakes step by step; we just had to roll with the outcome, and I had to learn to prioritize and let less important details go.

YOU ARE NOT YOUR USER:

Managing peers is HARD. I can't expect people to work the same way I do and wasn't in a superior position to direct my team, so I had to be careful in my communication and reason out my feedback to their work. Several times a teammate would say things like "but it makes sense to me" or "but that's what I would want", and I had to find ways to explain things from our user's point of view. I really had to push for user empathy and that "you are not your user" to help get the message across.

CONFIDENCE:

Entering UX, I wasn't very confident in my skills. Sure I had a design background, but not specifically as a UX Designer on a team before this project. I found I work better as a project manager and as a designer than I initially thought. I learned to believe in myself more.

Next steps

I desperately want to test the mid-fis and get solid feedback on the features and design. A little affirmation from users would be a huge confidence boost after all the struggle! If we had more time, I would have loved to explore another iteration based on that feedback.

Thanks for reading!

Wanna see more?

All Works