Justice Calendar Case Study

Justice Calendar Mockup

Project Overview

Justice is a Marathon, Not a Sprint

Justice Calendar is an application that helps users schedule small amounts of time out of their day regularly to consume content about racial inequity. Our client, Professor Tom Maiorana, came to us with a broad idea for a scheduling app to fight social inequity, which we then narrowed down the racial inequity and focused on prototyping a Google Chrome extension.

Over 6 weeks, our team researched, created, ideated, and prototyped ideas at a rapid pace with the goal of creating an application that would be friendly to users less educated in social inequity. After finishing the 6-week sprint with Design Interactive, the team continued to work with the client as well as a team of back-end developers to refine the idea and bring it to life.

Roles and Responsibilities

This was a six-week sprint where members took turns leading the team for the week’s focus. Anthony led during the research sprint, Lorren led for the ideation sprint, Sydnee led for the low-fidelity spring, and Aileen led for the high-fidelity sprint.

Problem Statement

We started by discussing the idea with our client and then amongst ourselves to come up with a problem statement. After mulling over the important aspects and the overarching goals, we asked the question:

How might we encourage users to commit time each week to learn about racial inequities and set personal goals to spark understanding, self-reflection, and informed action?

The team narrowed down from the problem statement that the basic components the app must include:

1. A way to visually schedule time so there is a commitment of physically taking time out of the day to learn about racial inequity
2. A way to choose the medium in which the content is consumed
3. A way to link the user to the content

Process

Research

Upon starting this sprint, we first consulted with our client, taking notes on his original ideas and asking for sketches that he had created prior. We discussed the initial concept and idea behind a calendar tool that would schedule time to learn about racial injustice and promote anti-racist actions. To learn more about our audience and what they would want to see in such an application, we sent out surveys to several social groups to figure out who would be interested in an app about racial inequity, how much time they would be willing to spend on learning, and what scheduling applications they currently use. We received 81 responses, mostly from college students, and we spent the rest of the week drawing conclusions from the data we gathered.

Research synthesis

Of the 81 respondents to our survey, we saw that:

• 91.4% of respondents identified as people of color
• 51.9% of respondents rated themselves at 3/5 on their level of knowledge on racial inequity.
• 97.5% of respondents were willing to commit at least 5 minutes to learn more
• 61.7% of respondents were willing to commit 15–45 minutes
• 63% of respondents primarily used google calendar to schedule commitments

From this collected data, we took away that:

• People of all ethnicities can learn more about racial injustice and have varying levels of knowledge
• People are generally willing to put in time to learn more about racial injustice
• A majority of people like to use Google Calendar to schedule things for them to do

Ideation

We conducted two activities as a team during our ideation stage: experience mapping and affinity mapping.

Experience mapping

The goal of this activity was to map the entire user flow: how the user would find the application, install it, use it, and the effects of it. We asked ourselves what questions the user would ask themselves during the process of each step to figure out potential pain points that would prevent them from utilizing our application consistently. One pain point that we discovered is that after the user installs our application and signs up, there is nothing that incentivizes them to continue using it or read any of the articles. We then researched how other self-help apps retain their customer usage and determined that rewards or virtual “medals” would be a great solution to reinforce the user to continue learning.

Affinity mapping

We each took 10 minutes to write down any ideas or questions we had about this concept. After each of us finished, we found that most of our ideas could be organized into seven categories: content, expansion, community/discussion, user retention, integration, notifications, and outreach/sharing. We then voted on our top 3 most important ideas and narrowed down the scope of our concept.

Our key takeaways from ideation were that users needed to choose the way they consume content, there should be a place for reflection, and a reward system was needed to keep user engagement.

Prototype

Prior to digital prototyping, each of us independently created wireframes of how we envisioned the concept manifesting. Each of us had a slightly different idea of how the user would navigate the application, from side-bar Google Calendar extensions to full-page browser extensions. We had a meeting to boil down our favorite ideas and research on how other extensions were created.

We created low fidelity and two high fidelity mockups walking a user through signing up for our app, redirecting them to the content, and finally leading them back for a reflection. We iterated several times to make the process smoother and eliminate unnecessary steps.

In our low-fidelity stage, we were more focused on prototyping nodes and how the frames would connect. We explored the overlay feature and how the browser extensions would overlay a page. In this stage, we also experimented with small size windows and full-page windows.

In our high-fidelity stages, we focused on creating a cohesive visual language that would carry over to every frame. We removed any excess steps to create the most seamless experience for the user. It was also important to make the prototype as close to a real experience as possible.

Login & User Setup

From our low-fidelity prototype to our high-fidelity prototype, we wanted to ensure that the process of users getting started was streamlined and smooth. Part of this process was the specific language used in each screen to provide a sense of guidance and comfort throughout the process. We wanted to ensure that users knew exactly what they’re supposed to do and why they’re doing it.

Scheduling

From our user research, we wanted to incorporate seamless integration with Google Calendar and provide a scheduling interface that is both intuitive and familiar.

Calendar View

Users can view the scheduled block of time on a weekly calendar. This would only display the calendar events made from Justice Calendar.

Fullscreen Interfaces

Users can access a larger dashboard with their scheduled content. User stats can incite more engagement and promote consistent use of Justice Calendar. Reflections for certain materials may hold a lot of important and insightful information, so users can also access past reflections in their journal.

Usability Testing

We were able to conduct testing with our client at the time, and we continued to iterate on the verbiage and intuitiveness of the first-time user flow. At the end of the design sprint, our team presented our final version of the high-fidelity prototype to the rest of the cohort and other design professionals.

Further Development

After concluding the project with Design Interactive, our client wanted to hire us for further development of the Justice Calendar project. One of the most prominent changes made in this extension of the project was the shift from a Google Chrome extension to a web application. Nonetheless, the interfaces still looked similar and were optimized for the larger interface size.

During these six additional weeks, we dove straight into ideations and prototyping to design and create this web application. This process was a lot more different than before though because our role as interaction designers also involved bits of web design given that we only had web developers to work with. We were posed with the unique challenge of learning CSS and web design principles after working on our initial prototypes on Figma. We decided to try using Webflow, which simplified the CSS coding to a more intuitive interface while also being able to export to developers so that they can develop the back end with ease.

The site is now live at justice calendar.org

Scope and Constraints

We had two main challenges that we faced along the way and had to overcome.

Remote Collaboration

Due to COVID-19, the team was spread out remotely, with three in California and one in Australia. Overcoming the 17-hour time difference took a lot of planning, note-taking during meetings, and late-night/early morning Zoom calls. We used Slack, Notion, and When2Meet diligently in order to keep everyone organized.

Learning Webflow

During our time working as hired designers for our client, we did not initially think that we’d be working partly as web designers as well. Most of our group was unfamiliar with coding in CSS or flexbox and other web design principles so we spent a lot of our working time just learning more about it. Our client had us work with the web development tool Webflow, so there was a slight learning curve as well when moving forward with this project.

One technical constraint that we faced was that Figma only allowed for single-interaction prototypes during this time period, so many features on the prototype were stunted by that.

Outcomes and Lessons

This has been a great experience for our team as we learned to work together remotely, overcome challenges, and learn new technologies together. After the prototypes were delivered, we were rehired by our client to work alongside him and other developers to continue working on our idea and bring it to the public. We are thankful to Design Interactive for this experience, Tom Maiorana for the project, our back-end developers for bringing our ideas to life, and the judges who gave outstanding critiques of our prototypes at the Presentation Day.