• Nick Dingle
  • Back
  • /
  • /
  • Portfolio
  • /
  • Peer Review

 

The Business Need

Peer Assessment is the umbrella term for a range of activities in which students evaluate and provide feedback on the work of their peers. The lack of a good way to set up a Peer Review activity in our product was leading to blocked sales in some of our key markets. I led the effort to design the Peer Review workflow for teachers and students.

Framing & Shaping the Initiative

Before you can start designing, you need to carefully narrow down the problem the team wants to tackle.

I led this effort by pulling insights out of past research and pedagogical literature and identifying common themes. In this case, there turned out to be two major goals for teachers:

  • Peer "Review": Teaching students how to give & receive feedback
  • Peer "Assessment": Conscripting kids to grade each other in large class sizes

Because the second scenario would involve a lot of technical refactoring, we recommended to leadership that we focus on the first scenario.

Conceptual Design & Testing

This scenario would touch many existing workflows inside the product across different personas. I identified a number of areas where we had questions, and put together an assumptive workflow which we could use to anchor some user research. Some of our questions were:

  • How are peer review activities scheduled & organized?
  • What type of feedback guidance did teachers want to provide students?
  • How should we handle anonymity?
  • And more...

I reviewed the concept with the design team, and then worked with our UXR team to create a research plan and put the concept in front of users. We spent a few weeks gathering insights, some of which resulted in major pivots in the workflow.

Story Mapping & Creating Milestones

Once I was confident that we had the right "big picture" workflow, I collaborated with my "trio" (myself, product management and senior engineering) to break the work down into milestones.

Story mapping is a great technique for defining milestones. I find it most useful to do it once you already have a sense of how the workflow needs to flow.

Estimating & Detailed Design

Once we had our milestones defined, I started collaborating with the dev team to come up with estimates and create the artifacts that the team would need. This is a very fluid process of working through technical constraints, brainstorming alternatives and discussing tradeoffs, or hammering the scope where needed.

As of today, the team is finishing up their previous project, and will be diving into the work for the first peer review milestone soon!

A snapshot of my obsidian vault where I gathered and synthesized research & business inputs (names redacted).
I wrote up an overview of the high-level scenarios that users care about, to share with leaders.
Some of the sketching (low and high fidelity) as I zeroed in on a concept to test.
Story mapping across product areas and different personas. The full story map is much larger :).
I will generate specs that are only as detailed as the team needs. The goal is not to slam down a thick waterfall-style document, but to provide enough clarity to move forward.
This is a slide I prepared for leaders, to summarize the major workflow steps we planned to build.

Some of the screens from the finished design are below.
An early version of the student evaluation view (with annotations & rubrics).
Back to Portfolio