Rivers + Roads
Project Overview
As a part of Interactive Design II, we we’re assigned the task of creating a functional app of our choice in teams of 4. I created the idea of Rivers + Roads, an outdoor adventure seeking app that is inclusive to all users and activities.
My team and I developed this idea to fruition through Lean UX over the course of the semester. This page will cover our process, design choices, and experience.
Details
Role: Team Lead
Duration: 11 weeks
Tools: Figma, FigJam, Microsoft Teams
Approach: Lean UX
Problem
With our knowledge, there are currently no apps on the market that offer a free way for users to find all kinds of outdoor activities in one place including biking, walking, running, hiking, skiing, snowboarding, fishing, camping, kayaking, etc. We decided to create this app to not only be inclusive to all activities but to fit the needs of diverse users whether they are young, old, handicap, have children or pets, men or women.
Objectives
Learn the Lean UX Process
Develop a functional prototype
Make research based decisions in design
Collaborative Effectively
Method
Lean UX is a user-centric design methodology that integrates the principles of lean thinking into the user experience design process. It places a strong emphasis on collaboration, rapid iteration, and continuous feedback to create products that meet user needs with efficiency and flexibility. In contrast to traditional UX methods, Lean UX minimizes extensive documentation and upfront planning, focusing instead on creating a shared understanding among cross-functional teams, including designers, developers, and product managers. By promoting a culture of constant learning and adaptation, Lean UX encourages teams to validate assumptions through user feedback and testing, ensuring that the final product is not only intuitive and valuable but, also aligned with user expectations. This iterative and collaborative approach enables teams to respond quickly to changes in user preferences and market dynamics, fostering a more agile and responsive design process.
In our Interactive Design II course at Kennesaw State University, we were taught the Lean UX process, although it was slightly modified for limited time. One of the biggest things to note, in our class all team members were designers, there were no developers to collaborate with and the role of a product manager was played by the team leader while they also acted as a designer.
In the timeline of this class, we had two brainstorm weeks, two three-week sprints (including a design week 0 for both sprints, and a final refinement week. We begin on week 4 as the first three weeks we’re spent reading Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf and Josh Seiden.
Week 4 - 6: The Brain Storm
While finishing up reading the final chapters of Lean UX, we begun working on the rough draft of the Lean UX canvas. This included defining the business problem and business outcomes, creating proto-persona(s), developing user outcomes and benefits, brainstorming solutions, and making hypotheses.
We begun with the first task of defining our business problem statement. The team and I sat down and participated in a dot voting exercise where we all quickly wrote sticky notes to answer questions like “who are the users/consumers?”, “what are the other competing apps?”, “what do those apps lack?” and “what will show us success?”. These ideas were far and wide with no wrong answers. We voted and came to a final problem statement.
We then moved to business outcomes, unsurprisingly enough this task was a struggle for a team made up only of designers. With little experience in the business side of things, we landed with a focus for three business outcomes: profitability, customer satisfaction, and consumer based growth.
Then, with these personas built, we created user outcomes and benefits. This task focused on what the user’s wanted to accomplish, how they feel about the process, how our product helps them achieve their goals, why a user would seek out our product, and finally what behavioral changes we can observe once their goals are met. This process came pretty easy to us as a team since we had just mapped out our business problem, outcomes, and user needs/wants.
Next came proto-persona creation, where we created fictional characters to represent users in our project based on our assumptions. From the get-go, we created 2 personas, a male and a female both representing young adults - one a single woman, and one a father, both with varying wants and needs but, similar goals. These personas wanted community, easy access to trails, safety, and displayed a fitness/health driven perspective.
Solutions were up next, we came up with solutions that fit both our consumers needs and the business problem simultaneously. This process was an affinity mapping activity in which we began with the question “What solutions can we design and build that will serve our proto-personas and create their desired outcomes?”. These sticky notes were then grouped by features: map, social media, safety focus, personal profile, organization, and search/filter.
Finally, as our last task, we created a list of hypotheses including business outcomes, proto-personas, user outcomes, and features. This list was created by combining all of our assumptions from the previous steps into unified statements. We created 9 total hypotheses in this brainstorm phase. These hypothesis ranged from features like the filter, safety, social media, etc. while lining up with the direct outcome of profitability, customer satisfaction, or user base growth. It was very helpful for us to start with the user outcomes and the rest filled in easily.
Sprint 1
Design Week 0 (Week 8 of Semester)
This week was mainly focused on finishing and refining all of our work done in the previous weeks on the UX Canvas. For the purpose of keeping this fairly short, I’ll explain additions and changes we made to the Canvas previously created and explained. Many things stayed the same as no research had been done thus very little had change in our perspectives and mind set.
The first change we developed was removing profitability from the business outcomes tree graph. Upon further research and feedback, we found it unrealistic for a start-up to achieve consumer growth and satisfaction while also being profitable. Although in a perfect world, every app and start-up would be profitable but, its very unlikely. To start out, we wanted to focus more on the consumer rather than to be lucrative.
Next, we moved to proto-personas. Where we felt our persona’s fit our ideal customers very well we thought it would be smart to add in an older individual to express the need for accessibility in both filter and safety features. We created a third persona, Jill Baker to represent this. While adding her, we decided to reformat and reword the previous created personas with a goal to need layout yet, the content remained the same.
We spent the bulk of our time reworking the hypothesis table and working on prioritization to help create our product backlog and sprint 1 backlog. First things first, we reworked the hypothesis table to include Jill Baker (the new persona) while also editing both other personas hypotheses as it felt rushed in the previous week.
Once the hypothesis table was complete to a point we collectively were satisfied with and no longer had profitability as a business outcome, we moved to focus on hypothesis prioritization. This phase is where we laid out each individual hypothesis on an X and Y axis to measure both the level of risk and perceived value. Initially, I found this task to be intimidated because I was not confident in our ability to make risk assessments on our assumptions when nothing had been researched or confirmed true.
The previous task of the hypothesis prioritization canvas was dire for our success in creating a hypothesis table in order of priority. By priority, we wanted to go ahead and build all the low risk high value items and create a plan for developing and testing high value items with potential medium to high risk. We added the reason for risk to each hypothesis. This then turned into an MVP (minimum viable product) table. This table would include each hypothesis and a summary of how we planned to test it in the following two weeks of sprint 1.
With the MVP’s now described and laid out by priority, we mocked up our product backlog and sprint 1 backlog. The product backlog included all the features that needed to be built and tested over both sprints while, the sprint 1 backlog focused on features that would be brought to fruition in the next two weeks. Looking back, we went a little too easy this first sprint and should’ve added a bit more to our plates to save ourselves some stress and rush later on.
Sprint 1 Week 1 (Week 9 of Semester)
After all this preparation, it was finally Sprint 1 Week 1 which meant it was time to build and begin testing our theories and assumptions. First to set the parameters, in this class we we’re to have 3 interviews each week with 3 stand-up meetings balanced throughout the week.
In this first week of testing we mainly focused on the essential question of “is there a need for this product?” while also testing a few features. This we week began testing banner ads and their placement, a safety/911 feature, the main map feature, as well as the filter sort function. We mocked up some supremely low-fidelity wireframes to simply get the point across to users. Below you can see the low-fi wireframes we created .
Alongside this, we also created a questionnaire featuring both questions about the wireframes as well as questions about the interviewee’s preferences, abilities, likes, dislikes, and overarching personality to see if we were on the right track with our personas. It was incredibly important in this phase to confirm the need and want for our app from users comparable to the personas. Each team member created 10 to 15 questions about the wireframes they’d created while we collectively created a series of introduction questions. These interviewee focused introduction questions and our preface to low fidelity frames can be viewed below.
After each interview, we would meet as a team and affinity map. This mapping exercise helped us store our thoughts and important take aways and group them to gather and organize our findings. At the end of the sprint, I would go back and summarize the content so we could have a small synthesized paragraph to bring to our next week of testing.
While we were building and testing in week 1 of sprint 1, I decided it was necessary for me to put together a style guide to prepare for the following weeks. This process was pretty simple but, I still wanted to include my fellow team members. I created a base style guide with colors and fonts, but gave alternative options. We sat down in a 30 minute meeting and made group decisions on what we liked, dislike, and what would be our final style guide. Although there were minor edits and additions as we went through each week, the ideas remained the same. Below are the final results.
Once the style guide was created, I decided I might as well start building our main components. This included creating an icon page, our various headers, the iPhone layout, the navigation bar, clickable buttons, and vertically scrolling frames for stories and activities selectors. These features would be reiterated throughout but, at this point it was important for us to have a base idea for consistency.
Sprint 1 Week 2 (Week 10 of Semester)
Sprint 1 week 1 went by in a blink and it felt like we were getting into the grove of things.
In week 2, some of our tests remained the same to get further input while we also expanded to create some medium fidelity wireframes too. In this week we focused on the home page, the map feature, the activities listing, social media, the history page, and the 911 safety feature. This week was a vital turning point in our process. Below are the wireframes we tested in week 2 of sprint 1.
Once all of our interviews and testing wrapped up, we collectively did a retrospective to gather what we felt went well, what we struggled with, and how we can all improve in the cohesive sprint 1. This was conducted in a bit of an affinity mapping manner where we all posted our categorized sticky notes and went through with them together. This activity really prompted us to self reflect and be more intentional with our efforts for the next sprint.
Sprint 2
Design Week 0 (Week 11 of Semester)
This week we spent sometime reviewing and refining our UX Canvas based on the findings we gathered in sprint 1 testing. Again, we kept the same base information and went back and changed or added items to better fit our personas, solutions, and outcomes.
First we reorganized our business outcomes to make more logical sense. I think in the beginning we did not take the business view as seriously as we should’ve. We struggled to see this business perspective and we had unrealistic expectations for a start up, brand new app.
Next, we moved on to reviewing our personas. We kept the general traits, needs, wants, and characteristics along the same lines of what we previous came up with in sprint 1 week 0 but, we had some big picture items to change. In testing, we came to the realization that most ‘outdoorsy’ or ‘adventurous’ people don’t really care about social media or have a need for an adventure finding app to include social media. Our first task was to remove all social media assumptions we’d created from each persona. The other adjustments made in each persona we’re simply made out of organization and professionalism
Once we had take all social media needs removed from each persona, we had to go through and adjust the social media hypotheses and mvps. We also removed the hypotheses revolving advertisements and profitability, which we had realized to be unrealistic in the previous sprint but still tested to confirm. The rest of our hypotheses remained the same although, we prioritized the risk and value of a few that were overlooked and underestimated in size and effort of the previous sprint.
Finally. it was time to revisit our product backlog and create a sprint 2 backlog. In this phase, we first removed all profitablity and social media features from the previous product backlog since they were no longer relevant to our users or business outcomes. We then reorganized the priority of these hypotheses based on our prioritization canvas that we had readjusted to be more accurate. We then started the sprint 2 backlog. This time around, with it being our last sprint, we needed to complete more and double down to finish the needed features. We were also better prepared to accurately size features based on effort and time put into them once we completed sprint 1. With all of this in mind, we created our sprint 2 backlog to include all the features left to complete and planned for who would work on them and when in the next two weeks of this sprint. This completed our adjustments to the UX Canvas. We jumped right into creating and prepping for sprint 2 week 1.
Sprint 2 Week 1 (Week 12 of Semester)
In our retrospective, we came to the conclusion that week needed more specific deadlines to fix the rush at the end of each week of the previous sprint. Our goal was to have all the building of wireframes for MVP’s and questions for the test completed in the first three days of each week. Then, we would complete testing in the second set of three days with a last final day to recuperate, organize our findings, and layout a plan for the next week.
With this in mind, we jumped right into building wireframes. We focused on the refining and creating the home page, filter and sort, review history, leave a review flow, share feature, user status, and history pages. We each created a questionnaire for our features as well as adjusted the introduction questions to concern less about a need for the app and more about personal preference of colors, needs, layout, and bigger picture items.
Sprint 2 Week 2 (Week 13 of Semester)
In our final week of testing and last week of the sprint, I decided to reformat the way we were completing work. At this point, we had created puzzle pieces that didn’t fit or flow together. I decided to layout a flow of screens starting with a notification for a new hike found near the user to then prompt them straight into the app where there would be a pop up for the new hike with the ability to click through the rest of the app. This was vital for us to create a more well rounded flow. I honestly wish I would’ve formatted our work production and completion to be like this much sooner.
I started by laying out blank screens with the frame name containing an explanation of the contents on each screen. Then, we met as a team and divided up the work to be completed. Many of the pages and features had already been created and needed adjustments or were currently in progress. I had the task of creating the notification page, the login flow, the home screen, the base image map with pins, the map personal view, the profile page, the clickable activities listing pages (4 total), the activity history page, and the status page. Rovid, a team member, was tasked with the map pop up from the clickable pin, the map flow from starting an activity to completing an activity, and the filter/sort page. Erin was responsible for completing the review flow which was four total pages, and the map swipe up containing activity metrics and the safety feature. Lastly, Jeff was to create the favorites page, the share page, and the reviews history page.
We crammed to finish editing a more cohesive layout so we could still complete testing. This week’s testing was more focused on the complete flow with questions aimed at design choices, consistency, and flow. Through the testing and mapping, we came to some big conclusions of things we needed to alter in the final refinement week.
We conducted our retrospective for sprint 2 and compared this weeks experience and results to the goals we had set in the improvement section of the previous sprints retrospective. I think this week went well for what it was but it did feel rushed simply because we had underestimated the level of work to be done in previous weeks and had to complete more this time around.
Refinement Week
(Week 14 of Semester)
In sprint 2 week 2 testing and retrospective, we gathered some great insights to edit and change our prototype to make Rivers + Roads more lovable for the users. Most of our interviewees were not big fans of our main font and had some questions about colors and consistency. With only having one week left, as well as needing to create process pages and complete review forms, I decided my team members needed time to focus on their other tasks at hand, as we still had other tasks to complete and it narrowing down to finals week, so I’d take on refinement alone.
I still wanted to include the other team members opinions on the big changes surrounding fonts and colors so i created mock ups with different fonts and pairings and different colors and sent them for a vote. Outside of these big picture, collective changes, I went through each screen and edited them with attention to detail and emphasis on visual design. This was a very time consuming process but it needed to be done. I made changes to each page to promote consistency and increase the visual appeal as well as reorganizing the layers of each screen for viewing purposes.
I spent countless hours reworking the prototyping connections to make sure everything clicked and navigated the way it should as we experience many wrong connections in testing. I also reworked several components for visual appeal as some features and pages were lacking the high fidelity we needed.
Conclusion
In this page, I previously discussed the process of Lean UX applied to the development of Rivers + Roads, an app for adventure seekers of all kinds looking for a wide variety of different activities in one spot. I have explained our experience using a modified version of agile Lean UX including our design choices, our understanding of users and business outcomes, and our process of development,
If I had more time…
Expand on visual design — I think there is space for visual appeal that we might’ve overlooked or neglected.
Create a more functional map — The activity we laid out was implied and representative, I would like to go back and build out a more animated, accurate, scrollable, and overall more usable version.
Spend more time understanding business outcomes — I would like to expand on my knowledge of the business side of design so I can create more realistic limits and goals.
Create a more animated prototype — The flow we created is heavily implied. I would like to spend some time creating after delay effects to emulate a user actually using the app rather than just clicking page to page and assuming where you would type, click, scroll, etc.
Enhance the Status feature — Although I really am pleased with the state of the Status feature, I think it would be great to expand by adding a leaderboard and a more collective activity history of how many workouts, calories, goals, etc. the user had completed.
Retry the Social Media angle — We found through testing that our ideal users were not passionate about or intrigued by the idea of our app containing social media sharing so we dwindled the idea down to ‘local stories’ that tag to the location but, we never built out how this flow would work, how users can add, or what the experience would look like.
Retrospective
Lean UX posed many unexpected challenges as it was my first time really following and learning this process while also having to lead a group of three other students learning it simultaneously. I am not disappointed with the outcome of our final product but, I do think there are several aspects that could use improvement and things that I would have loved to have done differently.
For one, I had not previously known my team members before this semester so, it would have been extremely valuable to get their personal preferences, where they sit in design and prototyping skills, what they were all comfortable and confident completing, and the specifics of what they wanted to learn and improve on. Not creating this understanding from the start posed a huge challenge of trying to understand all the members skills and abilities while building an app together and trying to meet their needs as team members while being understanding, graceful, and empathetic to them as individuals.
I think in our Lean UX experience, we often felt rushed to the finish line each week, looking back I would’ve added more structure to our sprint plans and pushed for harsher deadlines on completing MVP wireframes, questionnaires, and user tests. I wish I would’ve planned out a flow and built MVP’s into the flow from the very beginning to help us create a bigger picture layout from the beginning rather than have a few well thought out and tested frames that did not fit together or flow well.
I think as a team, consistency was a struggle. Some members wanted to create their own thing, and while I support creativity and trying new ideas, they needed to be spoken out loud and discussed for the purpose of consistency in testing and overall production. On the other hand, other members wanted to develop in the lowest fidelity possible until the last second which also aided our testings to be broken up with interviewees unable to focus on functions and features due to the distraction of inconsistency and absence of visual appeal. By waiting to fix these inconsistent designs to try to give my team members the benefit of the doubt and creative freedom, I made my bed for myself and I had to lay in it. By that I mean the refinement week was spent by me going back in and fixing colors, fonts, spacing, sizing, layout, connections, and everything in between.
I also found that taking interview data and getting members to think critically in applying it is hard to encourage. I always accepted ideas, thoughts, comments, and concerns, but it was occasionally challenging to get real, valuable insights and opinions. In all honesty, there were times where I struggled to really understand the comments and answers we were shared in testing myself. It was challenging for us as a team to read between the lines to better understand what users really want and need and not necessarily what they say they want, like, or dislike.
Lastly, I found that when it came to the final hour, all team members were locked in and focused but, in the beginning maintaining focus, professionalism, and organization was a challenge. Again, as my first experience leading, I wasn’t sure how to go about bringing attentions back and keeping them to help the meetings and building of the canvas and MVP’s serious. If we had been as focused for the entirety of the semester as everyone was in the last week or so, I think we would’ve been less stressed and more pleased with our final product.
A word on Leadership
It is important to note, this was my first leadership experience in this major and of this caliber. In the beginning of the semester, we were tasked with creating a short pitch of an app idea in which the class would rank each presentation and the teams would be chosen by a cross reference of all rankings. I went in with the intention of becoming a leader as I knew it would be a valuable experience and I would ideally like to hold a leadership position in the future. I was ecstatic when I was elected team leader and got the opportunity to build out my app idea.
I found many highs and lows in leadership. At times, it was a lot. I facilitated the organization of all members schedules, set up all meetings and led them, progressed production, while trying to maintain focus, positive attitudes, and meet the needs of each team member. I not only acted as a team member in completing the work at hand but, I also acted a ‘product owner’ and led decision making and kept us on track with the vision for the app. Below, I’ve included some of the organizational and planning templates I created to help keep us on track.
Some of the greatest challenges I experienced were due to the fact that this process was for a course project and completed by college students. For one, all of the team members had varying and often opposing schedules, especially since we all were full time students with jobs on top of that. Scheduling became a great headache to overcome. It is also important to note that in this phase, skill levels vary widely as well as the will to work. I began with the idea that we would all be on the same or at least similar pages in the design skill department but that just was not the case and there was little time for teaching opportunities although I tried my best to help where I could. I found great challenge in coming to terms with the fact that not everyone is willing to put in the same level of effort all the time - which is predictable but, I had neglected this thought from the get-go. It was occasionally challenging to receive critically thought out insights from team members.
Overall, I think all members did a satisfactory job and I worked overtime to meet them half way and work with them to better our product. I think these challenges are all common in the design world and I feel like being a team leader was a valuable experience for me. I have a variety of things to work on and grow into in terms of leadership but, I am pleased to have started now.