Uncovar — Shaping the Future of Online Field Trips

by Blue Bird

Introduction

Before COVID-19, schools are able to enhance the educational and social experiences of students by organizing in-person field trips, ranging from day trips visiting a local museum to week-long tours visiting other cities and educational landmarks. With the current shift to online education caused by COVID-19, these trips are no longer possible. Though some museums partner with tech companies to create virtual tours to allow visitors to view their exhibits, these experiences are singular and do not deliver the same value as in-person field trips. We would like to introduce Uncovar, the platform that is shaping the future of online field trips by providing students with the ultimate learning and social experience. Through the various features that we offer, students will be able to enhance their classroom learnings, while solidifying their friendships with peers.

The design of Uncovar was broken down into three main stages:

1. Empathize and Define
2. Ideate
3. Prototype and Test

This article walks through all three stages and outlines some of the considerations we made throughout the design process.

Empathize and Define

During the empathize and design stage, we defined personas for individuals that would be target users of our product. We came up with three key personas as detailed in the descriptions and empathy maps below.

Persona 1: Daniela M

Daniela is a freshman in high school who enjoys field trips and thinks of them as opportunities to gain hands-on learning. She is actively engaged throughout the field trips but prefers to work with her own group of friends. Daniela’s goals for field trips include getting more hands-on learning experience and spending time with friends.

Persona 2: Ms. Bennet

Ms. Bennet is a 35-year-old middle school teacher who loves her job and is dedicated to the development of children, especially through hands-on activities. Due to the pandemic, she has become more familiar with digital tools and uses them to teach but believes that students are best taught in-person. She is resistant to try products that offer relatively low benefits but is curious about emerging technologies like AR and their impact on future learning.

Persona 3: Jack S

Jack is a 14-year-old boy who has just started at a new high school. He has a very social personality but unfortunately, he can’t connect with his new classmates due to the pandemic. He is very tech-savvy and finds digital school quite easy. He has always enjoyed field trips and thinks hanging out with friends is the best part of a field trip.

Having clarified our three personas, we were able to conduct an exploratory study where we interviewed real individuals that matched our persona descriptions. We asked them questions about their feelings in relation to field trips and gained valuable insight that helped us in future stages of development. The questions asked were as follows:

1. How satisfied have you been with the in-person field trips you’ve taken?
2. How much do you interact socially with your peers during in-person trips?
3. How well do you learn when taking in-person field trips?
4. How satisfied are you with extracurricular activities delivered virtually?
5. In an online setting, do you prefer to learn during real-time lectures or through pre-developed material such as videos, written content, or interactive programs?
6. Have you taken an online field trip or a virtual experience curated by a museum? (If yes, how satisfied were you with the experience?)

In terms of interview results, there were several key findings that we found were consistent across all the individuals we interviewed. One was that students greatly valued the social aspect of field trips and wanted to be able to interact with their peers socially while doing field trip activities. That being said, they also wanted to work with their own friends instead of being assigned to randomized groups. Students also gave importance to hands-on learning and wanted their field trips to feel “different” from a normal classroom lecture. They liked activities that were exploratory in nature, and where students can learn by doing instead of simply listening to a teacher speak.

Using the knowledge gained from the interviews, we mapped out our findings into an affinity diagram (seen below):

We also identified 4 user tasks that were most important to the design of our application.

Task 1: Group Formation

This task can be broken down into two main subtasks. The first subtask requires the user to first view the groups that have been created so far. The second subtask is where they can create their own group with members of their choosing.

Task 2: Starting Field Trip

Task 2 allows users to officially begin their field trip by viewing the activities they are required to complete and contacting their group members via audio or video call. During this task, students will start a call with their group and browse through the given photos of leaves they are meant to find.

Task 3: Sharing Findings with Group Members

Here, students will use a viewfinder feature on the app to visually share their findings with group members. They can do so by notifying their group members to look at the shared view, enabling their viewfinder, then pointing their camera at the leaf they wish to share. The students can then compare the leaf to the photos on the requirements page. If the leaf matches, they may take a photo of it and save it to the requirements page.

Task 4: Help a Group Member Analyze Findings

Task 4 is the counterpart to task 3. When a different group member finds a leaf they wish to share, the user can navigate to the shared view in order to see what their group member has found. To complete this task they simply need to view what the other student has found, and use the requirements checklist to collectively determine if the leaf matches.

Ideate

After completing the empathize and define stage, we dived into the ideate stage by defining user stories and creating various storyboards, sketches, and user flows. We had four potential features in mind, which are Viewfinder, Audio/ Video Call, Requirement Page, and Teacher/ Student communication. The general process we followed started with outlining the user story of a feature, which consisted of an epic expressing the high-level needs or wants of the user, followed by two to three specific system requirements that need to be addressed in order to achieve the high-level needs or wants. After gaining a clear understanding of the user goal at both a high-level and the system-requirement level, we built storyboards around each feature by creating a scenario and plot to illustrate how users might interact with the feature. Finally, after syncing on the storyboards, we leveraged Figma to build sketches and user flows to illustrate how the feature might look and how the users might interact with it on a mobile app. See below for our deliverables during the Ideate stage:

Viewfinder

• User stories:

As a user, I want to share my findings with my group members

1. As a user, I need to enable my viewfinder and notify my group members to see it
2. As a user, I need to be able to point my viewfinder at the object I want to share
3. As a user, I need to be able to stop sharing my viewfinder when I’m done

• Storyboard:

The storyboard documents the process of a user sharing her current view with her group members during the field trip.

• Sketch and User Flow:

The sketch and user flow realize the needs and wants of a user with respect to view sharing with group members. While sharing their current view, the user is able to see a list of other people who are currently seeing their view. Additionally, the user may capture their view into a photo and directly save it to the requirement page, without interrupting their view-sharing session.

Audio/ Video Call:

• User stories:

As a user, I need to be able to communicate with my teammates easily.

1. As a user, I need to call all my teammates at the same time (group call)
2. As a user, I need to share ideas with them and over call and end the call when we are done.

• Storyboard:

The storyboard simply documents the process of starting a group call.

• Sketch and User Flow:

The sketch and user flow realize the needs and wants of a user with respect to multi-way communication. The user is prompted to either start a call or join an existing call, where they can manage the video and audio setting as well as see their friends. They can also explore other content while remaining on the call.

Requirement Page:

• User Story:

As a user, I need to know how to engage with this virtual field trip

1. As a user, I want to see the whole scope of tasks I have to perform on a single page
2. As a user, I want information relevant to the task I am about to perform when I need it
3. As a user, I want tools that help me learn the information I am supposed to

• Storyboard:

The storyboard illustrates the process of a student completing the requirements while on a field trip.

• Sketch and User Flow:

This is one of our more content-heavy sketches and user flows. The visual and text are highly compact to illustrate the process of checking off requirements when satisfied, as well as adding or deleting a photo to the requirement page.

Teacher/ Student Communication:

• User Story:

As a teacher, I want to help students understand what they’re currently engaging with in the real world so that they can better understand the learning objectives taught in class.

1. As a teacher, I need to be able to see when students need my help.
2. As a teacher, I need to be able to communicate efficiently with students.
3. As a teacher, I need to be able to show students new information

• Storyboard:

The storyboard illustrates the process of a group of confused students seeking help from their teacher, who joins the call and helps them out.

• Sketch and User Flow:

The sketch and user flow depict the process and components required to allow a teacher to help their students, including the video chat and call queueing interface.

Our buddy team provided insightful and actionable feedback to our design. Some of which challenged the scope of our product by pointing out that it needs to cater to more than field trips that analyze leaves. Others influenced our decision-making in the prototype stage — for example, one feedback pointed out that a viewfinder functionality could be combined with the Audio/ Video call feature, which we incorporated into our prototype.

Prototype and Test

Low-Fidelity Prototypes and Evaluation

• Prototypes

After finishing our sketches and user flows, it was time to build our first prototypes. We selected two of our features — the requirements page and the audio/video call feature — and turned them into low fidelity prototypes. Since we had already built our sketches in Figma, this was a simple process; we simply used Figma’s built-in prototyping feature to turn the user flows into dynamic prototypes. We then conducted a series of interviews for each of these prototypes.

• Evaluation

We conducted a total of three evaluations of our paper prototypes. One mock evaluation with a member of our buddy team, and then two evaluations with evaluators not familiar with our prototype. See figure x for the complete evaluation script. The general flow of the evaluation went as follows: we first introduced the evaluator to their role as a student on a field trip, and their goals during this field trip, emulating the preamble they would receive from their teacher if they were using Uncovar in the real world. Next, we guided them through the two tasks. First, we instructed them to navigate to the requirements page and gave them tasks requiring them to use its various features, such as learning more about a leaf (requiring them to click into one of the information modals) and to delete a photo they had uploaded (requiring them to interact with the photo deletion flow). Next, we directed evaluators to the audio/video page and gave them tasks that directed them through the various features in the video call feature. Throughout this process, we observed how the evaluators interacted with the app, looking for points of confusion, misunderstanding, and general imperfect usability.

In general, our evaluators viewed the features positively. However, there were some areas we could improve in. Some evaluators were confused by the swipe gesture we used to hide and reveal the video call bar on the requirements page. There was also confusion about the purpose of the checklist on the requirements page, and in one case, the facilitator had to explain to the evaluator how to use it.

The complete script for the low-fidelity evaluations

High-Fidelity Prototypes and Evaluation

• Prototypes

After finishing the low-fidelity evaluations, we decided to make some modifications to our features to address the issues discovered. We made two main changes: first, we removed the swipe functionality from the video call bar and instead use a button that users can tap to minimize and expand the bar as desired. Second, we removed the concept of a checklist from the requirements page. Not only was this a confusing feature, but its use as a potential grading mechanism was highly tied to our example field trip; we desire our design to be highly flexible to a variety of field trip concepts. Next, we took these updated designs and built our high-fidelity prototype. During a team meeting, we made several key decisions: we brainstormed on various names and settled on Uncovar. We worked to create a selection of color palettes before finalizing a single palette to use throughout the final prototype (we selected a color palette that not only provided a playful, adventurous feel to draw users in but provided a broad selection of colors we could use for concepts such as “positive”, “negative”, “info”, as well as page bases and accent colors). We also finalized page layouts and the look and feel of the prototype. With the groundwork laid, one of our group members then built the final high-fidelity prototype.

• Evaluation

With our high-fidelity prototype in hand, it was time to conduct more evaluations. This time, we conducted two forms of evaluation.

Our first form of evaluation was a heuristic evaluation. A heuristic evaluation involves an expert evaluator judging your prototype against a set of established usability principles; in our case, our experts were fellow members of our class, and the heuristics we selected can be seen in Figure y (copies of which were filled out by our evaluators). Again, while evaluators overall rated our prototype as well polished and logical, they were able to find a few problems which can be fixed in further iterations. Namely, our prototype lacks an established entry and exit flow, and the names chosen for our two features, “View Field Trip Requirements” and “View Group Assignment” did not align with what evaluators expected when they entered the features.

We also conducted a cognitive walkthrough with a member of our target audience; in our case, a 12-year-old female middle school student. A cognitive walkthrough involves giving the interviewee a high-level task, then comparing their approach and interactions with the prototype to a previously created ideal flow. This allows us to identify areas where the user’s model of the prototype does not correspond to our designers’ model. Some points of confusion for our interviewee are as follows: similarly, to our heuristic evaluators, she was confused by the nomenclature of our features. Additionally, our interviewee never attempted to click on any of the descriptions to view the information modal; perhaps she did not feel like she needed more information, or she never understood these were clickable items to begin with.

The heuristic worksheet we provided our heuristic evaluators, including the heuristics we selected for consideration

Future Design Possibilities

There are a few areas where future work on our design should take place. The biggest issue currently is the nomenclature of our two main features. “View Group Assignment” leads to a video call, while “View Field Trip Requirements” leads to the actual assignment. These names are leftovers from previous design iterations and should be updated to reflect their current contents. Further design iterations could also investigate how the pages are split up; it may be possible to contain the entire group video call interface in the video call bar (or at least made accessible from the video call bar), which would remove the need to have a top-level page dedicated to it, removing the entire nomenclature problem to begin with.

Conclusion

Reflecting on the design process, we were the most surprised by three things as they challenged our assumptions. The first surprise is the misalignment of the definition of “social value” to us and our target users. We perceived it to be the ability to meet new friends, but our target users wanted to stick to their existing social circle. The second surprise came from our own group’s understanding of the viewfinder feature and whether it is a stand-alone feature from the audio/video call feature. Finally, our assumptions on how the requirement page should be laid out were challenged by the results from our various interviews. Our initial design was to have check-lists that users collaboratively check off, but we later changed it to a simple “classification” block to address the users’ concern that a check-list may be too convoluted.

For the future, we hope that Uncover becomes the platform that helps students make the most of their online field trips. Uncovar will hopefully realize the potential of online field trips by leveraging emerging technologies such as AR and VR and add value to students by providing a unique experience that is unparalleled by the conventional field trips they are familiar with.