Earth Hour

See Prototype
Duration:
3 months Fall 2021 (September- December)
Role: UX Designer

Summary

A conceptual interactive prototype made for the Apple Watch. In a world where time travel exists, people like to travel along the space-time continuum to visit cultures long forgotten. Earth Hour provides the travel information you need to enjoy your trip to the distant past

Executive Summary

In my Interaction Design 2 class, I worked with a team. My teammates were our team leader Katie Peterson, Antonella Mai, and Conor Blankenship. We created a companion travel resources app from a world where time travel existed. We developed using Lean UX methods in the fall of 2021, from late September to mid-December.

Introduction

Noa recently won an all-expenses-paid trip to 15th century Italy using the latest time travel technology. However, Noa does not know much about society during this time, and she is allowed little to no technology on her trip to give information about the civilization. However, she is allowed to bring her smartwatch with her.

Earth Hour, our Apple Watch prototype, is a hypothetical travel resource for the average time traveler.

We used Lean UX in our approach to create this app. What is Lean UX? Lean UX is a fast-paced environment focused on building a Minimum Viable Product (MVP). Using our initial assumptions of user needs for a time travel resource app, we would iterate our design using what we learn from the people about their experience with a travel app. Lean UX uses the organization from UX, the MVP from Lean, and Scrum from Agile. In Lean UX, we use Scrum to create an MVP. Typically, Scrum consists of two Sprints.

So, to cover the process of how we created Earth Hour. I will go through the two Sprints we completed and what happened to the prototype in these weeks.

We designed the prototype for our Interaction Design 2 class. Our team Leader Katie found that we were allowed to use no bounds for parameters for the project from what our professor said. Katie came up with the concept for a time travel resource app.

Sprint 1

A sprint is a phase where we work to complete a product backlog which is a list of features to tackle in the period. Each Sprint is three weeks. The first week is called design week. It is where we decide where the direction of where the product backlogs. The following two weeks are where we test and execute our assumptions on the prototype.

We arranged to have around five meetings a week. These meetings comprise three virtual and two in-person meetings. We used Zoom and Discord to interview our users.

Design Week 0

In our initial meeting, we filled out several documents. They were the New Product Problem Template, Assumption Template, our First Proto-Personas, the Product Backlog, and a Sprint 1 Backlog. Let me explain how each helps my team and my focus on our assumptions for Sprint One.

The Product Problem Template explains the problem we found with other travel resource services, and they do not compile a cohesive guide for travelers.

In the assumption template, we outlined what we believed users would need if they traveled back in time.

The Proto-Personas were created based on the assumptions of what users might use our prototype. It helped with our visualization.

Proto-Personas

The Assumption Template gave us the needs we thought the product should fulfill. We began working on the Product Backlog. The Product Backlog prioritizes the users' needs and creates a list of needed features.

Finally, the Sprint Backlog is what we need to focus on and test with our interviews.



Sprint Week 1

During our weekly meetings, we checked on the wireframe's progress and the necessary adjustments. We had different areas of the wireframe. We used the Sprint Backlog to work on features and divide them based on sections of features.

We also held three interviews with people interested in travel or experience in the area. The interviewees were Artemis, Leann, and Joe. Our questions focused on what would be necessary for them when traveling. Questions about the customs of the places one would visit or food they might eat. After learning answers such as these, we adjusted our wireframes to include these sections.

Sprint Week 2

Everyone had started on each prototype section. We also interviewed three more people of different travel interests. We started showing the interviewees the prototype to get feedback about where we needed to innovate.

We asked questions about preferred features and how they would see their information. It is hard to tell how much information we can put on the watch prototype. We received more requests about new features. These features were bookmarks and a food section.

Sprint 2

Design Week 0

After Sprint 1, we needed to review our data and decide which tasks were most important in our project. There were many things we knew differently compared to when we started. We reevaluated our original documents with our current knowledge and corrected the product backlog. We added the bookmark feature and food section to the information section. People also wanted us to add an area for their settings. Due to the new information we collected from the Sprint 1 interviews, we also decided to eliminate the secondary Proto-Persona. Our users do not fit this secondary persona.

We also changed the overall wireframe to display the new sections that we had added.

Sprint Week 1

We held three virtual touch-in meetings to review where we were and what needed to happen next. We also met up twice in person while working on the prototypes. We interviewed three more people to see their reactions as they went through the app prototype. Our main questions focused on how they felt about their interactions with the prototype and their current pain points.

Some users suggested we change the icons, while others expressed differing opinions about the color palette. Users asked us about the orientation of some sections, such as the information section, to a mobile layout. We changed the screen layout of the information section due to the user's feedback.

Sprint Week 2

As we finished our last meetings, we were heading to the final stretch of the prototype. We had our final three interviewees go through the prototype and ask them if anything was confusing to them about the prototype. Some were confused about the screen navigation. They seemed to be getting lost on different screens. Our prototype was almost complete other than these last-minute fixes.

We finalized our proto-persona for the last time. Since the beginning, it has changed a lot as we dropped the secondary proto persona in the revalidation stage. In our original assumptions, we assumed that our audience would aim toward both recreational use and research. Recreational characteristics were more prevalent than research-oriented characteristics. Thus we eliminated the second Proto-Persona.

Conclusion

This project was a fun experience that I enjoyed with my teammates. I would love to do this again with them. We had an out-of-this-world theme when we started to create this prototype. I learned a lot about creating an MVP for our time-travel resource app for the apple watch in a fast-paced environment. There were some recurring problems that I would fix with this project. Some interviewees did not always understand that this app was not supposed to transport people to the past but be a fun time travel resource for people. Also, we seemed to have some indecisiveness about a color palette because our users gave varied responses about color. If I repeated this project, I would make visual design a priority.

Let's Connect!

Get in touch for opportunities or just to say Hi!