KIDDOM

Gradebook

BACKGROUND

Kiddom is a web and mobile app that offers a free curriculum builder and digital gradebook for K-12 teachers. When Kiddom developed a partnership with a curriculum provider, it necessitated rethinking the gradebook.


I was the sole product designer working with a Product Manager, with some oversight from Head of Design in the beginning.

Important to note, this was during a transition time where we no longer had our Head of Design or PM mid-way through the project.

My Role

working in ambiguity, collaboration, complex workflow, digital tools

Illustration by Fahad Ahmed

PROJECT OBJECTIVE

As we were defining the project, I utilized our user feedback, interviews, and personas to understand how teachers grade. Some key understandings:

- Inputting grades is necessary but time-consuming
- Teachers are used to grid formats
- Teachers who do mastery-based grading need more tools and detailed reports

Support standards-based grading for question-level inputs to support the new curriculum partnership.

EMPATHY & RESEARCH

Current Kiddom gradebook

As a teacher, grading is time-consuming. I want to use a digital gradebook but sometimes I have to create more assignments to track individual standards which adds to my workload. I wish that I had something that eased my workflow and matched my grading method.

DEFINE PROBLEM & PRIORITIES

- How might we support standards-based grading, and more specifically, mastery-based grading for the curriculum partnership?
- How might we address UX debt?
- How might we enable quick, painless grading for a variety of grading methods?

There was not a formal design brief or PRD at the time, so I gathered our PMs in order to think through the problem and address product priorities.

From our conversation, I focused on developing questions and key goals that would incapsulate the problem.

HMW...

Teachers need an easy way to enter grades that matches their grading method.

Mural board for collaborating on priorities

DISCOVERY

- Grade books are usually grids.
- Mastery-based grading uses color to distinguish levels and can be very detailed but lacked context.
- No mastery-based grade book enabled question-level reporting

I set out to design something better than a traditional grid grade book.

I investigated the known research on our users and did comprehensive audits for student and grading experiences.

Additionally, I researched digital and print grade books in a variety of grading methods.

Results

DESIGN: ROUND 1

FEEDBACK

- Move away from legacy designs
- Enable horizontal, vertical inputs
- Solve for question-level grading

I used existing, legacy components to make some quick mock ups to get feedback from our CEO, Product, Engineering, and Design on our direction and bandwidth.

Phase 1 designs for gradebook

DESIGN: ROUND 2

I met with the PM to talk through the shifting landscape for our components. We decided that the trajectory was to support the curriculum builder design.

IDEATE SOLUTIONS

- Reflect curriculum builder style
- Explore question-level input
- Explore horizontal, vertical grading
- Explore ways to represent rubrics

SHARE SOLUTIONS

Teachers were looking for a grid-layout for workflow optimization. For example, teachers may want to grade a single student across for all questions or grade each question for each student down the line.

Design Idea: the vertical roster would enable workflow (who am I grading) the horizontal bar would support question level (what am I grading).

I shared my 4 options for feedback:

Option 1: Popover input
Option 2: Line input
Option 3: Toggle screens for workflow
Option 4: Modified grid for question level

Keeping in mind how mobile might support the options.

FEEDBACK

SUMMARY & LEARNINGS

When I was gathering the mock ups above for a prototype test it with users, the project was reassigned to the new Senior Product Designer for a fresh perspective.

Looking back, I also see this as an opportunity to learn about communication. While I did create a document for the Lead of Product to check in on the progress, I tend to design the most complicated view first, to test the complexity of the system, so I had not yet pared down the designs to show a less complicated use case. I was looking forward to user testing to validate the next design decisions for revision.

Without testing, I did a mock up of some revisions to see how I would address complexity challenges.
Take a look!

Owl by Oksana Latysheva from the Noun Project