Oppia Android App

Objective

Create an Android app for an EdTech organization given the current informational hierarchy of their website. Make it intuitive for child users while factoring in age, literacy levels, and internet connectivity issues. Test the mocks through user interviews and iterate based on feedback.

Info

Role: UI/UX Designer
Platform:
Android Mobile App
Tools:
Adobe XD

Cover photo of Oppia Android App screens for the Oppia Android App case study.

Overview

Oppia offers free education for all

Screenshot of Oppia's Library Page website. It shows sections of explorations users can play through.

Oppia is a non-profit organization that aims to provide free education to children around the world. In underdeveloped countries, internet speed can be unstable and slow, making it unreliable for users who need it for their studies.

With that in mind, Oppia’s Android app was designed and developed to allow users to browse, play, or download lessons based on their internet status and preference, all while making it engaging and intuitive to use. 

This case study focuses on the features within the Topic Page portion of the project.

Design process

Chantel's design process for the Android app. The first stage is "Discover," the second stage is "Design" that iterates back to itself, the third state is "Review" that iterates back to "Design," and the fourth and final stage is "Deliver."

Research

Key Terms of Oppia

Table showing the breakdown of a "Topic." This comprises of at least 1 Story and several of skills called "Subtopics."

Understanding the hierarchy of information helps me break down what needs to be displayed and at what frequency they occur:

  1. Topic:  the subject matter to be taught. A topic will consist of a set of stories.
  2. Subtopic: a skill is what the student should be able to do.
  3. Story: realistic scenarios that teach the topic. A story consists of a linearly ordered set of explorations or lessons.
  4. Chapter or Lesson: learning units within Oppia.

Goals and factors to consider

The organization wants to develop an Android app that allows users to play lessons from their device wherever they go through offline downloads. The target audience is children in underdeveloped countries who may have limited or unreliable internet.

Goals established for this project. Create a mobile learning app where users are able to read a summary of what the Topic is about, Download a topic to play its lessons, view all curated compilations of lessons, also called Stories, Practice their skills within the Topic, and Review the skills as summarized notes. Design while accounting for limitations such as lack of internet connectivity, English learned as a second language, and children who will be using this learning app. We can solve this by leveraging the Android library for the design layout and avoid flashy animations, relying on icons, affordance, and using basic terms as labels, and researching user expectations and finding a broad solution for all children.

Users: How do children vary in age?

We had to account that children would use this app and outlined how different user experiences would be for these age ranges:

User experience among children's age groups.

Source: Design For Kids: Digital Products for Playing and Learning (Gelman, 2014), Teenager’s UX: Designing for Teens (Joyce, Nielsen, 2019)

This helped me established these UX goals for all age groups:

  1. Show the information up front so users know how to navigate straight to the lessons
  2. Make interactions predictable by creating actions that have expected results
  3. Don’t make the interface too childish

Solution: Keep it together with tabs

Since all information is under the "Topic" hierarchy, the best way to navigate through it is by using Material Design’s Tab component. Tabs allow content items at the same level of hierarchy to be grouped together and can be customized to include icons for visual representation.

Tab example from Material Design's library

Design

Initial Wireframes

First draft of the 1st tab of the Topic Page. Currently called the 'Overview' tab. First draft of the 2nd tab of the Topic Page. Currently called the 'Play' tab. First draft of the 3rd tab of the Topic Page. Currently called the 'Train' tab. First draft of the 4th tab of the Topic Page. Currently called the 'Review' tab.

Overview

  • Display a summary of what the concept is

  • Visualize the download state of the Topic

Play

  • Play and view progress of each Story

Train

  • Quiz the user on self-selected Skills

Review

  • Go over the notes of Skills

Test & Analyze

Conduct user interviews

The next step was to test our mocks through user interviews.

Steps taken before conducting interviews.

I created an interview script to give to a UX Research team that was conducting this study in India. I had to keep in mind what prerequisites interviewees need to have in order to participate in this study and had the following in mind:

  1. Some experience with an Android device
  2. Experience with using the internet (either through phone apps or a web browser)
  3. May know limited English as a second language

Analyze & Iterate

Compromises made (and what could done next time)

UX research showed that young children had difficulty reading the app's content, largely due to their cognitive and literacy levels at their age. While edits can be made to the vocabulary used throughout the app, definitive math terms cannot be replaced as this would affect the quality of the educational material.

More foresight will be made in future user studies with children so that the content, not just the UI, is adjusted accordingly and more data can be synthesized.

Labels and icons

Tab names were edited based on suggestions and feedback given. We also darkened the primary green color to comply with W3 contrast ratios.

Differences between first and second iteration of Tab menu items.

Adjustments to the Lessons Tab

Analysis from the latest iteration of the Lessons Tab (previously known as Play Tab).

Conclusions

Designing for children with limitations challenged me to research and create a product that works for everybody. I juggled tradeoffs between written content and visual aesthetics, but never at the expense of the user experience. Instead, I listened to user feedback about what improvements can be made and understood why these changes need to be made.

Check out the video below of the finished screens or the mock where you can view other features I designed: