Ryo
Product Designer

HMDB

Historical Movie Database

Image alt tag

We all want to learn more about the world, but history books are boring, and “facts and figures” are hard to visualize. HMDB allows you to search for anything in history, and see what movies corresponding. Whether it’s ancient Rome, 7th-century China, or the Industrial Revolution, HMDB is designed to help you learn cultural and historical context, before your deep dive into traditional learning materials.

Overview

Problem: Interest in studying history is declining, and students find history books and traditional educational materials to be boring. However, as one author puts it, “Kids don’t hate history — they hate the way we teach it.”

Solution: The best way to understand and remember historical events isn’t to memorize dates and names — it’s to imagine history as it happened. While many movies won’t give a perfectly accurate account, they are great at retaining attention, making them a powerful supplement to traditional educational materials. This app utilizes film to help us imagine cultures, people, and events throughout history.

Timeframe: I designed this app during my free weekends over a 2-month period.

Role: This app was done entirely by myself. This involved…

  • User research

  • Information architecture

  • UX & UI design

  • Prototyping & user testing

Tools:

  • Pen & paper — sketches, paper prototypes

  • Whimsical — wireframes

  • Sketch — user personas, UI design

The Process

I used the Design Thinking framework for this project, because I like its non-linear approach. It realistically reflects the changes of scope and direction in my own work experience, by providing flexibility in how to solve problems as a result of user feedback.

HMDB: Historical Movie Database

Navigation

Research

Background Research

In order to get an accurate reflection of film consumption among all demographics, and in order to validate my primary research findings, I conducted a fair amount of secondary research.

Key findings from HotDocs’ 2014 & 2018 studies

Key findings from HotDocs’ 2014 & 2018 studies

Two studies reported teachers who found their students are more motivated and better able to learn when movie scenes are shown in class. And since documentaries are essentially about educating (not just entertaining) viewers, the findings from two large-scale studies (each involving over 3,000 Canadian documentary-watchers) indicate why. For context, 57% (6.7 million households) across Canada subscribed to Netflix in 2018, and young people in particular prefer to watch movies at home. 

The findings from my secondary research were consistent with my primary research findings.

Qualitative user data (blue); user contrasts (red); user similarities (numbered), data synthesis/contextualization (purple)

Qualitative user data (blue); user contrasts (red); user similarities (numbered), data synthesis/contextualization (purple)

User Research

I conducted half-hour interviewers with five people (aged 26–69, 2 female, 3 male). I asked questions about their film- and TV-viewing behaviour, as well as what kinds of informal education they engage in.

The large amount of qualitative data was organized into the “AEIOU” table, which helped put things into the context of users.

From there, I compared and contrasted the users, and synthesized all of the data in order to determine how many user archetypes I could identify. The data revealed three archetypes, which I turned into user personas.

Primary User Persona: Aubrey the Student

Primary User Persona: Aubrey the Student

User Personas

My research led to three user personas. I originally picked Ashley (the “Lifelong Learner”) as the primary persona, because I considered the fact that there are many more active adult learners than either students or educators (i.e., demographically). 

However, after some early user testing, it made sense to change the primary to Aubrey (the “Student”), as explained in the next section.

Defining the Scope
Early (overly complex) concept of interactive scaled timeline

Early (overly complex) concept of interactive scaled timeline

Scope Change

Originally, there were elaborate plans for advanced features, including: 

  • interactive scaled timelines (pictured here)

  • public comments and private notes for each movie

  • TV and film support

  • user-generated ratings of historical accuracy

Initial user testing showed significant usability issues with many of these things (e.g., imagine putting a film set in 500 BCE and 2019 on the same timeline).

During my iterative process, I switched my primary persona to Aubrey (the Student), and eliminated the overly-complex features. This radically simplified the app, and shrunk the scope to a much more feasible set of core features.

Requirements

After the scope change. three key requirements were identified through the user research:

  1. The product must be a mobile app, since this is Aubrey’s preferred medium

  2. Users must be able to find movies based on historical details (e.g., times, places, people, themes)

  3. Users must be able to save lists of movies; and the lists should be able to be ordered chronologically, thereby enabling users to make their own timelines

Early Designs & Iterations
The

The "Red Routes" Matrix

User Stories

In order to start fleshing out the app, I made a list of 10 tasks that the primary persona would care about the most. These tasks were then plotted inside a Red Routes Matrix to determine which features to prioritize designing.

The three most significant tasks to the primary persona (Aubrey) were turned into user stories

  • "As a school student, I want to know what happened right before and after a movie's plot, so that I know the context of whatever movie upfront."

  • “As someone who’s pretty busy, I want to make various lists of movies, so that I can watch them whenever I'm free later.”

  • "As a curious browser of content, I want to be able to filter out movies set in certain places, times, or genres that I don't want to see"

Improvements shown in green. Numbers reflect a 1–5 scale, from strongly agree (1) to strongly disagree (5)

Improvements shown in green. Numbers reflect a 1–5 scale, from strongly agree (1) to strongly disagree (5)

Sketches

I decided to make paper prototypes with the user stories in mind. The first two rounds of testing was done with hand-written sketches; whereas the third was with wireframes that were printed and cut out on paper (see below).

User Testing

User testing entailed the completion of tasks such as:

  • Imagine you have an upcoming civil rights essay for school... where would you find your list of movies on that subject?

  • How would you search for movies set in Ancient Rome?

Early testing showed the app to have a very confusing UX, which was excellent feedback. Finding pain points early led to changing the primary persona and the core functionality.

Through each round of testing, self-reported user satisfaction scores improved. Furthermore, some of the tasks in the first round were not able to be successfully completed, whereas all of the tasks were successful in the last round of testing.

Wireframes

Once I had an idea about how the core functionality would work, the wireframes enabled me to rapidly iterate and explore various options. The following image is a sample of several of the main user flows one would experience using the app.

Final Designs
HMDB: Historical Movie Database

Iterative Design

The UI was designed to be familiar to users of streaming services like Netflix; with features such as the vertical scroll and the horizontal carousels. A final user test showed general improvement on task completion times, and users liked the colour that was added by the film posters over the otherwise plain background.

Evolution of the Movie Page

Evolution of the Movie Page

Takeaways

What I learnt:

  • Conduct secondary research first — Learning as much as possible upfront always helps to understand the context, and to prepare for user interviews

  • Be flexible with your ideas — Let the data override your preconceptions, as you observe how people interact with your app

  • Early failures can lead to big wins — The early user testing I did was met with considerable frustration on the part of the user, but every test ended up improving the app. The key is to learn from your mistakes, and don’t take it personally

  • Do fewer things well, not many things poorly — This became clear to me as discovered that my app was too complex in its early versions

  • Don’t focus on features, focus on needs — It’s tempting to start with this “cool feature” you want to add (e.g., a scaled interactive timeline); but users care about whatever solves their problems, not necessarily what you think is cool