AI Powered Interaction Bot to Help Plan Your National Park Expedition

  • Timeline: Two Weeks

  • Team: Team of Three

  • Role: UX Strategist & Designer, User Researcher, Usability Tester, Presenter

  • Deliverables: User Persona, Competitive Matrix, MoSCoW Map, Functional Prototype, Usability Report Client Presentation

  • Tools: Screener Surveys, User Interviews, Persona Development, Prioritizing Features, Sketch, Flinto

  • Project Status: Ongoing


We were challenged with designing a solution on an appropriate platform for a problem our team discovered within a certain topic area. Our team decided to focus and conduct research around National Parks in order to discover a problem users face. All decisions aside from the topic were made from research we conducted.


Understanding the user in order to create a product on an appropriate platform that helps solve the user's needs in and around National Parks. After completing user interviews, our team decided to design a tool that would help users easily find information to plan a trip to a National Park.

Phase 1: Research & Synthesizing

We created a screener survey to find users who had been to National Parks several times within the last two years. This would allow us to identify users who had experienced planning trips using tools and websites currently offered to the public. Our screener survey produced seven individuals for user interviews.

After conducting user interviews, we affinity mapped the observations; and it was clear that most people struggled to find information easily and effectively.
Insights we found were:
  • NPS offers good basic information
  • I rely on Park Rangers for the most detailed, up-to-date information, when I have access to them
  • I rely on locals and past visitors to get details, tips, and advice
  • I like to plan so I know what I'm getting into
  • Scheduling hikes and activities are a must
  • People use simple lists for organizing
With affinity mapping complete, we began to see where the users were struggling in planning their National Park trips. Pertinent information resided on several different websites because the National Parks owned site only informed users about basic information such as location, hours, and what activities are offered at the park. Users shared that while this information was needed, they received better information from other sites that allowed past travels to comment and leave advise. This information led to the making of our persona: Sharon Kim.
Taking into account the persona and all additional information we gathered from the user interviews, we were able to come up with the following problem statement:
The National Park Service has a wealth of information on its website, but the information is hard to locate and doesn't include previous visitors' recommendations.

Sharon struggles to find information on NPS.gov and still has to spend extra time looking for user reviews on multiple other sites.

How might we help Sharon find reliable and up-to-date information and reviews quickly for planning her visit?

Phase 2: Competitive Matrix, MoSCoW Map, Ideate, Proposed Solution

To start solving our user"s problem, we began to assess what was currently being offered in the market. To accomplish this, we created a competitive matrix that included competitors as well as comparators.

Through the competitive matrix we saw an opportunity to create a product that would educate travels about the park as well as assist in planning their trip.

Now that we knew where we wanted to position the product within the market, we needed to decide what features we wanted to include. We MoSCoW mapped with sticky notes on the wall to decide what fetchers needed to be prioritized.
With the features grouped by Must, Should, Could, and Won't; a pattern emerged. All the features we wanted to included fell within three categories:
  • Search
  • Supply list
  • Trip schedule
Having search as the foundation of the product, users could find all the information they needed for their trip and then save the information within a supply list or a trip schedule. This created a Minimum Viable Product we were ready to ideate and produce a solution with.

Phase 3: Ideate, Proposed Solution

Knowing that search was the foundation of the product, we needed to decide the best way a user could search for information. During user interviews, users shared their frustration with search engines.
"Using Google to look for this information is time consuming because I have to click on a result and then look throughout the page to find the information." User 1

"If I search on NPS.gov, they give me a list of articles that may have the information but I don't know till I read through them." User 3
NPS.gov search results for "hiking at rocky mountains"

We conducted a design studio and an idea that was generated was to use an interaction bot to help people search for information. Our user interviews told us that users enjoy talking to the Park Rangers because they have good information that is often updated. Users also responded positively about rangers because they had trust and confidence in them. By using the ranger as an interaction bot, we hoped it would help create the same trust and confidence for the users.
Hand Drawn Chat Bot sketch from Design Studio
Other reasons we felt the interaction bot was a good idea were:
  • Provides an easier way to navigate NPS.gov
  • Search and display content from various sources
  • Provides the ability to "Talk to a Ranger" when planning and scheduling a trip
  • Implementing Nielsen Norman Group recommendations improves the user's experience of the chatbot
Next, we needed to determine what platform we were going to use to make our interaction Park Ranger bot. While a responsive website would allow us to reach anyone with an internet connection, it didn't allow us to connect with certain hardware API we wanted to use. We also chose a native app because:
  • Data stored locally, removing the need to create an account
  • Native app permits microinteractions which help delight the users
  • Full screen design, no browser frame
  • Information can be referenced when no network connection is available
All of this cumulated in a Mid-Fi prototype built in Sketch. Below are several screens showcasing a preview of how a chat with the bot may look.
Mid-Fi Sketch Prototype

Phase 4: Usability Testing Mid-Fi Prototype & Iterate

With a the Mid-Fi prototype, our next step was to conduct usability tests on users. Again we found users through a screener survey confirming users had traveled to several National Parks within the last two years. We found two minor issues as we conducted our usability test. The reports are below:

Phase 5: Hi-Fi Prototype

After receiving comments from the Mid-Fi usability testing, we iterated the design to included changes we observed from the users. We also added color that reflected nature and National Parks. All of the colors were checked to confirm that their contrast passed the Web Content Accessibility Guidelines (WCAG) with AAA.

Video of Prototype: Click to Play

Phase 6: Next Steps

As with all projects, we arrived at a place we were happy with and believed assisted users with planning a trip to the National Parks; however, there are always next steps. For our interaction bot the next steps we would take are:
  • Pin items from chat for later reference
  • Create and manage multiple lists and schedules
  • Share lists and schedules with friends
  • Sync schedule with user's phone calendar
  • Export/download lists and schedules
  • Provide Ranger Bot on iPads at Visitor's Center to support human Rangers
  • Send questions to a human ranger when Ranger Bot cannot provide an answer
Home          Emotion Slider          PeopleJoy          MTA Subway