Trail damage occurs when mountain bike riders ignore conditions and ride on wet trails.
Creating Outdoor Damage Reports
People love their trails. Sometimes, they love them to death by riding horses, mountain bikes, or hiking on them when they are way too muddy to handle. Many times park users have used trails when they were wet, obstructed by trees, or covered by water, leaving damaging ruts, holes, or off-trail detours. The end result is a trail that has to be rebuilt or closed altogether.
Why do park users do this? A large part has to do with a lack of communication between park managers, park users, and park custodians. Park custodians (like many Trail Advocacy Non-Profits) know when trails are usable and when they are not. However, that information often does not get to park managers (who can close trails) nor to average park users (who can be told not to use trails).
Additionally, park users have no consistent or centralized way to report trail damage or give feedback on trails that should be closed before more park users arrive. This leaves everyone involved with a huge problem: how do you let everyone know (in near real-time) when trails can and cannot be used?
The Goal: Stop Riders from Damaging Trails
The Non-Profit interested in creating Trailgrinder was committed to environmentally and socially responsible mountain biking. For years their mission has been to facilitate recreational trail cycling, educating about the sport of mountain biking, maintaining local trails, and advocating for increased multi-user trail access. Now, they wanted to find a way to communicate the condition of a trail within specific parks before someone showed up to ride. This would help everyone plan their rides better and greatly improve the protection of trail networks for years to come.
The Vision: Democratized Decision Making
Authority is not something mountain bikers care for. I discovered early on that simply making timely and accurate trail information available to all park users was not enough. Even when the information was available whenever and wherever they needed it, riders wouldn't pay attention to it. In order to get them to stop using trails that were in poor shape, riders needed to be part of the solution. Especially after bad weather or heavy rains when most riders want to know if everything has returned to normal.
This meant that Trailgrinder couldn't be another top-down reporting system controlled by a few elites inside the Non-Profit. Mainly because too many mountain bikers disagreed on the criteria that constitute the need to close a trail. Some advocates think that certain conditions (e.g. light rain) don't have much impact on a trail, while other advocates believe that if someone drops a snowcone on the trail it should be closed.
The multitude of UX research collected from trail-side interviews gave me a clear understanding that the riders were the best source of trail information. Additionally, with too many trails and too few trail advocates to provide any timely information, it didn't make much sense to add 'trail condition management' to the Non-Profit's lists of responsibilities. Instead, I wanted to leverage the hundreds of mountain bikers as a free reporting resource. By opening up trail condition reporting to the existing trail culture, the advocacy of everyday park users (and active park managers) could crowdsource the decision. This would remove the need for Non-Profit volunteers to conduct daily spot-checks (in real-time) while unleashing an army of trail reporters to do the work for them.
Creating Personas from the Pain
The pain of poor trail communication emerged as:
- 'No standard for allowing people to judge trail conditions.'
- 'No status of any given park's trail system at a glance.'
- 'No way to disagree or justify a trail closure.'
- 'No way to report the reopening of the trail after a problem has been solved.'
- 'No process for riders to locate, identify, and report trail hazards.'
This manifested into five (5) key personas for the project:
- Park Manager Mariam -- Wants everyone to be happy and safe while in the park.
- Trail Boss Brian -- Wants the keep the trail in good condition but has no help and limited time.
- Biker Jim -- Just wants to ride his bike. The muddier the better.
- Evangelist Ernie -- Needs to tell everyone a tree is down on the trail.
- Get Off My Lawn Larry -- Always wants to close the trail if it rains one drop.
All these personas want the same outcome: A trail that is safe, open, and undamaged. However, each has a different idea on how to achieve that outcome. If everyone could share what they mean when they same 'trail damage', then they could also agree on when a trail should be closed.
A classic scenario that Trailgrinder could solve: A tree down on the trail.
Example Scenario: A Tree Is Down
One Trailgrinder scenario centered around the justification for closing a trail due to a downed tree:
Evanglist Ernie reports a tree down that gets the attention of Park Manager Mariam, Get Off My Lawn Larry and Trail Boss Brian. They all think the trail should be closed until the tree can be removed and use Trailgrinder to vote the trail 'CLOSED' until work can be completed. Only Biker Jim doesn't think one downed tree should close the entire trail but has been outvoted.
In the past, Biker Jim would have ridden that trail regardless of the closure notice like dozens of other mountain bikers. He would have either not have received the message, climb over the downed tree to continue his ride, or expanded the trail by creating a detour around it. The downside is that the erosion caused by detours around a downed tree leads to rutting, damaged foliage, and water pooling. Not too difficult for most mountain bikes to navigate but tough on horses and hikers. The more ruts and mud, the wider the trail detours. It's a vicious cycle.
This time, however, Trailgrinder socialized the reasons to Biker Jim. behind a closure in an open dialog where Biker Jim gets to understand WHY Get Off My Lawn Larry sees the need to close the trail. He also gets to hear from Trail Boss Brian about how the trail could be opened if only he had some help. Biker Jim is no longer in the dark about the reasons.
Meanwhile, Trail Boss Brian now had Biker Jim's attention (maybe for the first time) and the rare opportunity to enlist his help as a volunteer to remove the downed tree Evanglist Ernie had reported. When Biker Jim agrees to help Trail Boss Brian remove the down tree a week ahead of schedule, suddenly Get Off My Lawn Larry doesn't have any reason to think the trail should be closed. The tree removal reverses everyone's vote about the trail back to 'OPEN'.
With everyone happy, Park Manager Mariam has nothing to worry about and can focus her attention on other issues within the park.
Crafting the Prototypes
The first early prototypes wireframes of this concept focused on a user interface that favored the active trail user:
Trailgrinder application park favorites at-a-glance wireframes.
This manifested as a list of the park user's favorites parks with 'At-a-Glance' trail condition symbols showing open, closes, or hazardous conditions. They only needed to search for your favorite park once. Once it was saved as a favorite, the capability to make reports or see park details becomes available.
Originally, when the park had a closed or hazard status (some open, some closed, problem areas), you could click on the park button and discover the justification for that condition, where the problems were reported, and see who voted to close it. However, the Non-Profit started to rethink the democratization aspect of closure. Instead, they opted to allow a park manager or trail advocacy volunteer to have the final say based on the reports.
This changed the wireframes to show only the final decision on the park details screen and not the ongoing discussion. The report was placed on a sub-screen under Reports along with News and Events. A 5-day forecast was also added to provide more clarity with regards to closure justifications as follows:
Trailgrinder application example of park detail wireframes.
Converting Wireframes into UI Mockups
Once the Non-Profit could see how the wireframes represented a real capability, the client asked to move forward with a medium-fidelity mockup for usability testing. The mockups set the mood for an application that shared a user interface (UI) look and feels that represented an outdoor color palette:
Trailgrinder mockup color pallet.
These mockups also established an iconography for at-a-glance information:
Trailgrinder application example of park detail mockups.
Usability testing feedback led me to simplify the hazard reporting UI by only allowing users to classify problems by four categories:
- Red -- Bees and Wasps
- Yellow -- Deep Mud
- Green -- Downed Tree
- White -- Flooding
This would keep park users from getting too creative and allow the Non-Profit trail bosses to prioritize trail work. It would also give just enough information to know what tools to bring, inform riders on where problem areas were located on the map, and justify changes to a given trail condition.
Wearable Prototype Testing
Trailgrinder was not targeted at anyone specific mobile device at first. However, during the UX usability testing an interesting idea was presented that utilized emerging wearable technology. I had access to the new Sony smartwatch at the time and pitched the idea of extending the trail reporting tool as a wearable application.
Additionally, because the Sony Smartwatch was ideal for Samsung Android smartphones, I mocked up how Trailgrinder would appear if the original prototypes were converted to work with both devices:
Trailgrinder application showing that a favorite park is closed and the hazard location that caused it.
The Sony Smartwatch application would amplify trail hazard reporting by using an icon-based interface to send data to the Trailgrinder application running on the mobile phone. This would allow a rider to report hazards without having to stop their ride and pull their phone out of a backpack.
The UI was designed to provide only the minimal amount of information such as setting the type and geocoordinates of the hazard with large, touch screen icons:
Trailgrinder Sony Smartwatch mockup screens.
Because the Sony Smartwatch could be both worn on the wrist or mounted to the handlebars of a mountain bike, a rider could technically report a trail hazard without having to stop:
Trailgrinder Sony Smartwatch Bike-Mount mockup.
Ultimately, Trailgrinder had the potential of expanding beyond mountain bikers to all park users. This would allow anyone using the park to report hazards, trail conditions, and be an active member of the trail community.
Do You Know Your Trails?
Unfortunately, the Non-Profit did not see any benefit in expanding the tool's capability and only focused their attention on a mountain biker-only application. In 2015, had completed the UX design of the application and was standing by as the Non-Profit looked into funding its development. Eventually, they had a volunteer within their organization develop a Beta Version of the application without my involvement.
Rebranded as 'Trail Status' for both Andriod and iPhone, the Beta Version did not include any of the trail reporting or hazard indentification when it was released in both the Apple App Store and Google Play Store in 2016:
Trailgrinder application BETA download promo.
Furthermore, the Sony SmartWatch extension of the application was never developed or transitioned to newer products like the Samsung or Apple smartwatch.
I believe that because this application did not include the key features that spoke directly to the pain it was designed to address, it resembled a simplified version of a Facebook post in the application form. The app store statistic backed up this assessment when, after fewer than 500 downloads in 2-years, the Non-Profit shut it down and ended the entire project.
Build, Measure, Learn
Overall, the application helped me learn two very fundamental facts. The first was that trail advocacy groups will always have a hard time communicating trail conditions when park managers and users see Facebook as a perfectly viable alternative for communicating park trail conditions. Yet, because trail advocate organizations see themselves as the source of truth for trail conditions, many park users have a hard time trusting their decision-making process when they can see the trail is okay with their own eyes. Until these organizations can become more transparent with their standards, they will continue to be seen as knee-jerk groups that close trails when someone drops a snowcone.
The second fundamental fact was that crowdsourcing trail conditions can work. If park users were allowed to have a say in closure decisions more people would adhere to that decision. When only a few people control the status of any given trail, applications like Trailgrinder will always have difficulty time becoming popular with park users.