Tools Used:

User Interviews

Primary Research

I wanted to explore if finding a climbing partner was a universal challenge for rock climbers. If so, what was being done to overcome the problem? In order to find out this information, I recruited participants from the rock climbing community by sending out a survey. Out of the 42 responses I received, I chose 7 participants. Each of those participants interviewed with me remotely for 20 minutes.

Chosen participants ranged from beginner to advanced and climbed at least once a week. 76% of those who took the survey (42 climbers) indicated they had difficulty finding climbing partners. I was interested in conducting interviews with those climbers to have a better understanding of pain points and the overall problem.

Insights

Affinity Mapping

From the interviews, I was able to gain insight about the challenge climbers have finding climbing partners and what is done to overcome this challenge. I used affinity mapping to help me quickly synthesize my findings.

Define

Using the collected information from interviews, I constructed empathy maps. The empathy maps helped me to create my personas, Christina and Justin.

User Stories + Information Architecture

I compiled a list of tasks the user would want to complete, which made up user stories. These tasks revealed what the minimum viable product would consist of.

User Flows

My next step was creating user flows to help me visualize the step by step process my users will go through to complete tasks.

My focus was on the following 4 key red routes:

Developed Sketches

I turned my user flow concepts into low-fidelity sketches in order to test out my ideas on actual climbers who would be my users.

Usability Testing

I input my sketches into POP by Marvel. Using the prototype below, I conducted 5 usability tests. I had each user perform 4 key tasks so I could understand how users interpreted the sketches.

Watch the prototype below:

Iterations

The following changes were made based on the results of the tests I conducted:

Finding Partner Requests
Users had hesitation which icon to tap to find partner requests. Two participants clicked "Messages." I changed the design to use one icon that brings the user to messages and partner requests.

Partners vs. Partner Requests
There was confusion among participants how to go to and from "Partners" and "Partner Requests." I added segmented controls and got more specific in labels by changing "Follow Requests" to "Partner Requests."

Gender Identity
If I included gender identity, it was important that each user was represented. With focus on inclusion, through testing and seeking outside resources, I realized it was most inclusive and not necessary to include gender at all.

From Sketches to Wireframes

Using only grayscale, I composed my wireframes, focusing on how the key elements fit together. I also worked through edge cases and created wireflows.

Style Guide

Before tackling high fidelity mock-ups, I created a stye guide to ensure that my entire design would be uniform. The style guide gave me a foundation to work from to make a smooth transition into my high fidelity mock-ups and to give my product a cohesive feel throughout.

High Fidelity Mock-Ups & Iterations

Once the style guide was set, it gave me a foundation to work from to transform my wireframes into high-fidelity mockups. The screens I constructed are a representation of the product Climb On. The following iterations are based off of user testing.

Partner Request Notification
A red dot to the right of the "Partners" icon was used to notify the user that they received a partner request.

During testing, I found that users had difficulty knowing what that notification was for. In order to resolve this issue, I added another red dot in the specific spot the user should tap.

Encouraging Connection

I thought it would be necessary to make an immediate decision about each potential climbing partner. This would be similar to a dating app where the user chooses "yes" or "no"/swipes "right" or "left." I realized because it is not a dating app, it would be more beneficial for the user to see mutual friends to encourage partnership instead of being pressed to make a fast decision.

Yes or No

In testing, users had an idea what the "x" or "check" would mean, but there was not a confident understanding of what would happen if tapped. Again, I wanted to head away from that "yes" or "no" concept, as this was not a dating app. Users are encouraged to reach out to multiple partners.

Prototype

Using my high fidelity mock-ups, I developed a functioning prototype using InVision. The purpose of prototyping was to identify areas that needed improvement in addition to ensuring that participants were easily able to work through each red route. I conducted 2 rounds of moderated usability testing, with a total of 10 participants, almost all climbers.

Watch the prototype flows below:

Key Learnings

• Discover accurate user needs. Research, user interviews, and testing will reveal the precise needs of the user. User interviews from the start showed me that there was a need for this app, as many climbers currently struggle or have struggled to find climbing partners. This gave me confidence that there would be a user base for this app.

• Iterations are key to a successful design. This was discovered through user testing and through the insight of mature UX designers. I changed the wording from "Partner Up" to "Request Partner," changed icon thickness, and revamped how the user would choose new climbing partners. With each edit, my design was more intuitive for the user, and overall, a stronger design.

• Exposure to existing products will give me insight into what my users are already familiar with. That is why I compared a variety of dating apps to help kick start this app. I wanted my users to be able to navigate Climb On with ease, not having to recall or memorize a new product.