EXPLORHER
This is a Human-Centered Design project completed Autumn of 2020 for an upper-level undergraduate course in User Experience Design.
OUR MISSION
We want to design a solution to allow women hikers to find and create a strong and
supportive community of fellow hikers. There is a large population of women who greatly enjoy
recreational outdoor activities but can be limited due to accessibility, lack of community, or lack
of experience. We hope to bring these women together by creating an application to make an
active lifestyle in nature attainable for anyone. We want to break down the barriers that are
preventing women from making connections with other women hikers with shared passions so
they can experience nature together in a safe and supportive environment.
RESEARCH FINDINGS
Our user research consisted of semi-structured interviews with 4 different users as well as competitive analysis. For the interviews, we found four women hikers of all different ages and experiences, and each team member interviewed one of person individually. From these interviews, we had three key findings:
-
Facebook groups are commonly used but are so broad that users have a difficult time finding women with similar interests and hiking goals as them. Additionally, some members of these groups don’t know basic safety or etiquette.
-
Our users have to cross reference many different technologies to plan a hike since hike details on different tools than where you would find others to hike with.
-
All users expressed that hiking in groups or with a companion was preferable, whether it’s for safety and/or community.
We used these findings to build personas and to shape our design decisions to ensure they were meeting a real user need.
Competitive Analysis
For the competitive analysis, each team member chose a technology to analyze and find out how it met and failed the user needs found from the interviews. We looked a Facebook Groups, NWHikers.net, The Mountaineers. From this, we found these key issues:
-
Users can’t filter these forum feeds to find information that is relevant to their personal goals and interests.
-
User’s may not be experienced enough to want to pay for an account or to know how to navigate all the information on these hiking tools.
-
None of these tools prioritized users finding women like themselves with similar experience, pace, and energy, or planning hiking events.
These findings were used to make informed decisions about what features we should and should not include in our design, and what we could do to meet our users’ needs better than these competitive technologies.
PERSONAS
We created personas of two potential users based on our user research. We created these personas by taking common characteristics and patterns from our interviews, and forming overarching archetypes that fit who our ideal user base would be. We focused on finding shared desires, pain points, goals, and current technologies from our interviews to use in these personas.
These helped us to make each following design decision with a focus on our user’s specific characteristics and needs. Additionally, they later helped us create storyboards of scenarios that our users may likely experience that we used to create the main user flows of our app.
USER JOURNEY MAP
We created a user journey map based on the persona Amy, an out of state freshman at the University of Washington. A user journey map is a visual diagram that portrays a user’s thoughts and feelings throughout an event. We created this so we can have some insight into what the users' negative and positive thoughts and emotions are when they are finding people to hike with as well as going on a hike with them. Most of her thoughts and emotions were based on our user research, however some assumptions were made based on our own experiences. The user journey map helped us identify pain points that we wanted to address in our final design. These pain points helped us determine our design requirements in the next step.
STORYBOARDS
We each created storyboards to visualize possible key path scenarios based on our design requirements from the previous step. These storyboards that each of us created helped us think about possible design solutions that would work for our users. After creating these storyboards, we began thinking about what the layout and interactions we wanted for our application. This storyboard helped us decide what interaction and pathways we wanted to include for the next step, the information architecture.
DESIGN REQUIREMENTS
Writing our design requirements helped us articulate the needs of our personas in a new way, and begin to visualize the most important actions & interactions we wanted our app to facilitate. Many of our design requirements were focused on community-building and cultivating connections, such as the following:
-
Users can upload posts for other users to see and respond
-
Filter other users by hiking experience, age, and location to find another user with desired characteristics.
-
User input about hiking experience, pace, age, and location is stored and presented to all app users.
By identifying our design requirements, we were able to begin imagining scenarios where our user group would interact with our application. At this point in the design process, we were able to narrow down the specific needs we were designing for and we began to ideate with the intention to build a community for our users.
As we moved from research and storyboards and into prototyping, it was important for us to figure out the hierarchy of information in our application. The information architecture we created below helped guide us in creating the navigation of our application by determining the major functions we wanted from the application, and the sub pages of these functions. We knew we wanted our application to have a functions such as Calendar, Search, Resources, Profile, and Messaging, and through our IA we determined the pages that would fit into each of those functions. We also had the one-time set up pages, that would aid in creating a more personalized experience for the user.
The functions we chose encompass the core values of community and relationship building based on the design requirements we made earlier. The process of building an information architecture helped us prioritize these main functions of our application and allowed us to narrow down what pages we wanted to delve deeper into for the paper prototypes and ultimately the high fidelity prototype.
PAPER PROTOTYPE
QUICK EVALUATION FINDINGS
The user testing we conducted with our lo-fi prototype revealed that our app wasn’t effectively communicating its primary intended purpose to new users, and that many of our screens were somewhat unintuitive to use and could be improved by closer adherence to conventions found in other apps. Our biggest takeaway was that different users were confused by why one feature or another wasn’t more heavily emphasized, but the testers who gave us this feedback didn’t all have the same features in mind. We took this feedback and aimed to communicate our purpose more clearly in the next step, our annotated wireframes.
We used the information architecture from the previous step as our guide for the lo-fi prototype. We chose three important user pathways and made the pages necessary for them. these are the user flows we chose:
-
Find a hiking event and sign up for a car
-
Find a hiker like you and message them
-
View hiking groups and join one
We created this lo-fi prototype in order to test with our user to see if we missed any important parts of our user pathway. We then started planning for the next step, wireframes, based on the feedback of the people who tested our lo-fi prototype.
ANNOTATED WIREFRAMES
These wireframes show every screen that ExplorHer will have. We used feedback from our quick evaluations of our low fidelity prototype to make this next iteration of the prototyped design process and expand it to cover all possible user flows. We were able to fix pain points that our users had during the evaluation and add more features to better meet the users’ needs. By creating the wireframe, we learned about possible pathways that we hadn’t thought of before. This step allowed us to really flush out the features and design of our app and what all of its functions were. Since the wireframe doesn’t actually contain real content, it serves as the skeleton or blueprint of our next iteration, the high fidelity prototype.
INFORMATION ARCHITECTURE
HIGH FIDELITY PROTOTYPE
GROUP REFLECTION
We are grateful to have worked on ExplorHer together this quarter and the design practice it provided us. For some of us, this was our first experience getting to work through the design process for one project from start to finish -- for others, a chance to refresh and refine our skills. Regardless, we all are proud of our final design and the work we put in to get here. We also want to thank our teaching team, Tyler and William, as well as our peers, testers, and other volunteers that helped us through the process.
​
Our greatest challenge in this process came in the form of resolving some of our dissonant design ideas, ideas that came both from the people we worked with and from within our own team. Some users felt like our app was and should be primarily a hiker social media app, while others thought our primary purpose was to provide hiking information and specifics about trails and locations. We really wanted to put people first, and focus on building safe and fun hiking communities as well as lasting relationships between hikers. However, even this idea had its own disputes. We wanted to include features to keep users up to date on what their friends and others were doing, but wanted to avoid some of the pitfalls and detrimental effects that social media-style features like this can have on users’ overall health. All in all, we felt like we were able to communicate well as a team and resolve our disputes in an efficient and positive manner, and end on ideas we could all get behind.
​
When it comes to our final design, we’re quite satisfied with how it turned out. While it’s often tempting to just jump into an idea and hit the ground running, we felt like we really benefited from the initial weeks we spent on our interviews, user research, personas, and storyboards. We felt like we had a solid plan before we ever put pen to paper for prototyping, and it helped us stay on course and build an app that fit our design requirements. If there’s anything we would change or do differently a second time -- it would be to aim higher and not be afraid to be different. We’d all love to make unique and interesting designs and experiences, but when it comes to building and testing, it’s often most comfortable for both designers and users to stick to the familiar, the patterns that are established or trendy, and it becomes uncomfortable to branch out in novel directions. That said, we feel that our ultimate goal should be to help real people with something they need or want, and we think ExplorHer does just that.