Cheatsheets

As one of the final projects in ENTR 390, a digital product design class, we were tasked to construct an app concept and write a case study documenting our experience building the app experience. I decided to tackle a problem with the current micro-learning app industry.

Busy Professionals wants a means to quickly acquire literacy in varying specialized fields to converse with other professionals.

Micro-learning is a fascinating new way for people to learn; the premise of micro learning rely on high-frequency, gamified user experiences that instantly reward users for acquiring bite sized information.

Unfortunately, many of the popular micro-learning experiences have been strictly scoped in the content taught. The very strengths of micro learning are also its weaknesses; small "lessons" of content make it hard for users to acquire complex concepts. Because so, the most successful micro-learning app experiences have been vocabulary/language apps like Duolingo, Quizlet, and other flashcard focused app experiences.

Cheatsheets intends to deviate from the micro-learning formula slightly; it retains the visual metaphor of a flashcard, but creates a more dense and diverse content delivery format to allow users to digest more complex subjects. Content on the platform will be created by users and aided by an editor staff that helps to create a consistent tone and quality.

The word "learning" usually connotes an action that results in "mastery" or "near-mastery" of a subject. Learning under this premise, becomes black and white, a big reason why micro-learning apps can only teach a very specific category of content to users: language/vocabulary.

Cheatsheets interprets "learning" differently, one's intent to learn a content may not be a conquest for mastery, instead people learn new subjects to "try" out the subject, to engage in conversation in social/professional settings, satisfy a personal curiosity, or get inspired. "Learning", in this sense, is a nuanced experience that, dependent to the goal of the user, can take different amounts of commitment to fulfill the user's goal. Cheatsheets intends to be a micro-learning app for this definition of learning; users will not master concepts on the platform, but learn with their goals in mind.

I have quantified a users role on the platform into two general states:

1. Learner: Explore new cheatsheets to use, learn from cheatsheets, review cheatsheets, request new cheatsheets

2. Creator: Create new cheatsheets, manage previous cheatsheets

With these two states and the actions attributed to the roles, I defined how I wanted to fulfill the actions attributed to each state.

Explore new cheatsheets to use: A page that presents editorially selected cheatsheets, recommended cheatsheets, and popular cheatsheets. Search feature should also be added

Learn from cheatsheets: Pages for users to interact and read the content of a cheatsheet.

Review Cheatsheets: A page for users to view previously viewed,pinned/bookmarked cheatsheets.

Request new cheatsheets: A page for users to request a cheatsheet that is not in the Cheatsheets collection.

Create new cheatsheets: A user flow that allows a user to create a new cheatsheet, modify the settings of it, add/edit/delete the corresponding cards with it, and get editor staff feedback for the content.

Manage previous cheatsheets: A way for creators to manage their previous cheatsheet drafts, editor staff comments, and published cheatsheets.

With these actions, I thought it best to structure the app experience over a tab bar for four specific page experiences.

Explore page: The unofficial "home" of the app experience; users can choose among different "lists" of curated cheatsheet content to explore.

Search page: The search page for users to find a specific cheatsheet. Request cheatsheet feature is embedded into the search results page.

Profile page: The page collecting users viewing history, bookmarked, and reading list of cheatsheets.

Editor page: The page providing all the editor suite of actions to users.

I have previously considered a user flow where drafts/published user cheatsheets fall under profile page and editor page will be replaced with a create cheatsheet page. Chose against that design because of possible confusion to users when they are in the "Learner" state and seeing "Creator" state actions in the UI. Also, many other content driven apps abide to a similar "Creator"/"User" split in the user experience. Thought to continue with industry standard.

Here are the initial sketches of the UI:

The core visual component is the "cheatsheet"; I wanted to explore the many ways I wanted to express a card in a list and on its own page:

I wanted to retain the visual metaphor of a flash card, and resorted to using a colored card component:

Here is the initial version of the UI created:

I had a particular challenge in expressing other page functionality on each of the four main pages. The navigation system constructed in this version was confusing and hidden. The search feature also felt too busy.

The "Learner" actions/user journey was easy to construct, but the "Creator" actions were more nuanced and complex. I had a struggle creating the complete user flow for each unique action that a "Creator" can take. A "cheatsheet" can take on many states: draft, screened by editor staff, published, unlisted.

To express each cheatsheet state and the corresponding collection of functionality in the UI was a daunting task.

Design wise, the UI uses Helvetica and semi-bold quite liberally; the UI color scheme was purposefully muted to allow the cheatsheet card colors to stand out. The UI is heavily inspired by Apple's iOS 12 design philosophy and a mix of Medium app's design style.

With more time, I would want to continue to explore the "Creator" user experience and create a more concise experience. The current mockup also doesn't contain error/empty states. Also, I do not think I explored the "card" experience of cheat sheet content enough. Most of the time was devoted to the "Creator" user experience; the cheatsheet experience feels lacking because so.