Rivers & Roads
A new way to track your outdoor activities
ROLE
Research
UI Design
Prototyping
Interactions
TIMELINE
October - November 2023
TOOLS
Figma
Figjam
Teams
TEAM
Rovid Chavez
Olivia Summers
Erin Weir
Jeff Opoku
Rivers & Roads
Rivers & Roads is an outdoor adventure application that allows you to track, locate and save any trails you find. It uses the community to make updates on any hazard events due to weather.
Challenges
Create a map that distinguishes itself from other competitors
Be a social and informative but not enough that it turns into another social media app
Keep the interests of our users by providing reasons to come back
Our Approach: Lean UX
In this project , I worked alongside 3 other team members to create Rivers & Roads. We approached it by utilizing Lean UX and it’s framework of three principles: UX, Lean and Scrum. UX focuses on understanding the needs of the user, Lean which is testing and validating our assumptions in a quick manner, and Scrum allows the team to stay in track through a series of meetings. The process is split into two sprints, each divided into 3 weeks. We had the initial week to create our problem statements, business assumptions, proto-personas, product backlog and sprint backlogs. Then, proceed to use our sprint backlogs to create our wireframes. lastly, we tested those wireframes in our interview sessions. For sprint 2, we focused on crafting a medium fidelity prototype that we could test. After all the testing we would go back to transform it into a high-fidelity prototype.
Sprint One: Week Zero
Kick-starting Rivers and Roads
In Design Week 0, we began with our product problem statement in order to create some assumptions and have an idea of what our project could be. Our product problem statement entails the current state of outdoor adventure mobile apps, how they are failing and the way we can approach with our solutions.
Product Problem Statement: The current state of Outdoor Adventure Mobile Apps has focused primarily on tracking hiking, walking, and running trails. What existing products fail to address is being inclusive to all types of outdoor activities for all types of people including their location and limitations. Our product will address this gap by expanding “outdoor activities” to include swimming, fishing, kayaking, canoeing, etc. for users who may be older, have children, have pets, etc. Our initial focus will be outdoorsy young adults who may be in a new place for college or post graduation. We'll know we are successful when we see reviews of adventures in the app, reviews of the app, friend referrals, and growth.
We then proceeded to create a business outcome, this was broken into three parts: Impact, Outcome(lagging) and Outcome(leading). The purpose is to make fairly high-level speculations about how our product will work.
Impact: How do we know that our strategy has succeeded?
Outcome (Lagging): What behaviors can we observe/measure that indicate we’re going to achieve our impact metric?
Outcome (leading): What behaviors lead to the behavior that we want to see above?
We came to the conclusion that our customers would be satisfied with the idea of a tracking system that is easy and useful, that level of happiness will likely get us positive reviews.
One speculation for our impact mapping
Proto-personas: The best guess to our users
We originally developed one proto-persona as our best guest as to who may use Rivers and Roads. We had a very limited amount of time for our sprints and Lean UX incorporated a way to use personas that was suited for out timeline. Introducing Proto-personas, which require little to no background research and study, only a few hours of work making assumptions as to who will be using our product and why. Then, we seek evidence to confirm or deny our assumptions as we progress through the sprints. Note that these personas can change drastically as time goes by.
We first focused on individuals who are active such as college students or instructors.
Affinity Mapping & Product Backlogs
Affinity mapping is a the simplest way to work as a team, each of my team members worked individually to brainstorm solution ideas that would solve the business problem considering our personas. First, our team leader posed a question and we began to seek solutions. Then, we each gathered as many ideas as possible and compiled them in a set of sticky notes. Some could be a single word, a sentence or a sketch. Lastly, we sorted them out and voted on what ideas stay.
A few of our sticky notes
In order to test all of assumptions, we built multiple hypothesis statements. Each statement would focus on the business Outcome, the proto-persons, the user outcome and a feature. Completing this would yield our product backlog , which indicated what we needed to accomplish to create Rivers & Roads.
Next, we reorganized the order each hypothesis. At the very top of the list we have the riskiest and the least at the very bottom. It was important to identify the riskiest statement because they tend to require more resources and time. Our conclusion for the riskiest hypothesis was the map function with possible ads.
Having organized and completed our backlog, we select a couple of hypothesis statements that would kick off our week 1.
Product Backlog
Sprint One, Week One
With our Sprint backlog established, we switched wears and began our 2-day Stand-ups. These are 15 minute meetings conducted every other day that allow our team members to give feedback on their work, updates on any problems that arise, and the goals and expectations for the next meeting. We used Teams to hold our Stand-ups which keep our team aligned and focused for the remainder of the project. In our first Teams meeting, we split the backlog to each team member. Everyone would create a low fidelity prototype of the section they chosen. Additionally, we would write a set of questions for our individual work and later compile them for our interviews. I worked on the map and filter screens.
Interview Process
We decide that for our benefit we would interviewing 3 candidates each week ranging from young active adults to older active adults, as they represented our personas. Having this many candidates allowed us to validate our hypothesis quickly. Our interviews ranged from 45 -60 minute each. The way we structured the questionnaire was opening with an overview statement of the scope of the project and what the project was about, followed by a set of introduction questions I created, and our individual questions for each section. For each interview we prepared an interview script and recording in case we missed something or needed to check our facts. Post-interview, we would have an affinity mapping session to compare notes and
Week 1: Insight
People were interested in the concept of a broader activity tracking app
Some features did not seem as useful as we originally thought
Affinity mapping and Questionnaire
Sprint One, Week Two
Retrospective
Retrospective is a meeting where we as a team takes an honest look back at the past Sprint. It examines what went well, what could have gone better and what will we try next. We noticed an inconsistency with what people liked for one of our pages during sprint one. I decided to combined the single elements liked from our feedback to get a more consistent page.
Sprint Two: Week Zero
Revalidating our Work
With the start of Sprint Two, most of our information would remain the same except with a few modifications. In week zero of Sprint Two, we revisited that work done on Sprint One and made alterations to certain sections based on our conclusions. These sections include our Proto-personas, Affinity Map, Business Outcome and Hypothesis. Revalidation means taking a look at Sprint One and evaluating whether the information we have still hold true. We noticed that many of our interviewees did not care for the social media aspect of the app, so we moved it down on the priority list.
Proto-Persona
We did not do any drastic changes to our personas, our only change was to persona #1 Camila. We decide to remove the focus of a community since we are staying away from the social media aspect that we originally had intended to do. Our interviews provided sufficient backup to remove this goal.
Sprint Two: Week One
For week two we decided to do a few different things. Based on interviewees comments from the last Sprint, we had to add color to our prototypes. Many of of interviews had the same consistent problem of having issues with the low-fidelity grey hues. We took all mostly took on different tasks from our Backlog.
Interviews
For our testing sessions we created a template, added color styles and text styles for a smoother flow on everyone’s work. On the first Sprint we had an issue with fonts and color that distracted all our interviewees from the main content. We stopped making multiple iterations of a page, instead we would tried ask them questions that would focus on a yes or no, followed by a why they felt that way, in return we received more feedback than before. Some pages like this filter page would use very minimal interactive buttons to demonstrate some ideas. As some interviews would perceive thing better visually.
On Stand-up or post interview meetings we would make sure to help out one another by giving each other examples of other apps or ideas we had hear of before to help with our individual research.
Sprint Two: Week Two
Usability Testing
For the last Sprint week, we finalized our last round of usability testing with our semi high-fidelity prototype. In this session we re-interviewed one of our previous users, who was in HR and studied psychology. She had many qualities that aligned with our personas and overall found that the app could cater to her needs and likes. As far as improvements to make, we had a couple of visual color clashes that needed to be addressed and font sizes that needed to be corrected.
Final Design
In retrospective this app allows the user to see new trails, expeditions, and adventures that they may not have been able to find on their own.
Our product will help the user organize their planning and expand their local knowledge with a nearby treks by use of a search option, in app GPS, social reviews + pictures, and packing lists.
In Summary
Lean UX looks complicated at first but once you get to understand how it works, it really allows you to get a lot of work done without wasting time and because of this, I feel like we were efficient in most of our sprints. Lean UX sprints go by fast and you require a lot of communication from your team members. I appreciate the effort my team put into consistently showing up for our meeting and communicating effectively.
Some things I would love to do differently are our early stages of wireframing. Most of my work felt too high fidelity and all of our teams work lacked organization and consistency. I feel like most of our interviewees struggled to understanding the idea at first because it felt like various individual designs trying to be one thing. I am however thankful we managed to correct this on sprint 2.
If we had more time to work on this project I would love to do one more round of interviews with our earlier candidates and use one more week to refine our prototypes. I think some of the map elements could have use some color adjustments and more interactivity.