Benchmarks.

To understand how districts were using Benchmarks and where the existing product was falling short, we ran a research effort that included a feature audit, admin interviews, a competitive analysis, and a pedagogical review. Across these sources, a consistent picture emerged: districts were looking for a writing-anchored diagnostic that could support planning, intervention, and instructional decision-making.

Administrators described two primary goals: getting a reliable snapshot of where students stand relative to grade-level expectations, and using those insights to guide coaching and targeted support. However, the current experience didn't deliver enough instructional value to justify the time required. Results didn't lead to clear next steps, rubrics didn't map cleanly to state expectations, and district leaders couldn't quickly identify patterns in the data.

What this translated to at a feature level was surfacing trends at the district and school levels, supporting the writing process rather than just the final submission, and laying the groundwork for targeted instructional recommendations.

That's a lot to bite off, so we determined to focus first on addressing fundamental issues with the views that admins used to track progress and view Benchmark results. This would provide the foundation the feature would need for future enhancements while giving admins more data in a more usable format in the short term.

The existing version of Benchmarks gave admins a Dashboard to view their active assessments, and a Results page to view detailed data on how students performed on them. The Dashboard lists each individual Benchmark grouped together by Series, meaning the same assignment given at different times so that growth can be tracked.

The Results page allows admins to view results for all students, per school, per teacher, per class, and per student. Together, these pages offered the rudiments of the data admins needed, but not much more, and not in the most helpful format.

One big theme from our research was that districts would benefit from viewing aggregate participation and performance data by grade and school, providing a bird's eye view on trends within their districts, independent of any given assessment.

In sketching different options for incorporating this data into the Dashboard, I found myself making compromises that would result in a poor user experience. Because a single grade level or school can have multiple unrelated Benchmark Series assigned to it, there's no clean way to aggregate their data: results would span differing start and end dates, content, and student bodies.

I showed my efforts and relayed my concerns to the team. After discussion and consultation with our data analyst, we decided there was no real way to square this circle. The grade and school-level report feature was dropped.

Though we eliminated aggregate reports, there was still an opportunity to provide users with more visible data. Our research had turned up the fact that users felt like they had poor visibility into their Benchmark results; the Dashboard was essentially opaque and offered few clues as to the status of their Benchmarks.

To address this, I added student participation data to each individual Benchmark alongside the existing teacher participation data, which I made easier to understand through a new tabular layout. I also bubbled performance data up out of the Results page into the Dashboard, giving admins a window into their results without having to click into each Benchmark Series.

These additions gave users the bird's eye view of data they were looking for while also making the Dashboard more useful, and resulted in a more streamlined Dashboard since we no longer needed a separate data view for the abandoned aggregate reports.

During our research, Customer Success Managers told us that the distinction between individual Benchmarks and a Series wasn't conveyed clearly enough in the product. Relatedly, the distinction between creating a new Benchmark Series and adding another Benchmark to an existing Series was confusing, causing admins to create one when they meant the other.

This feedback dovetailed with the incorporation of new data to produce a new layout that brings data to the forefront and makes the page and its parts easier to scan and understand. The new design placed more emphasis on each Series rather than its constituent Benchmarks, gave a clearer sense of sequence, and included copy adjustments to button labels to make user actions clearer.

Once we had a design that addressed customer needs, we brought it to our Customer Success team members, who we used as proxy users since we didn't have access to admins directly at the time.

Overall they were happy with the design and appreciated the new data, which they thought would make the page more valuable to admins immediately. Their feedback allowed us to add an extra touch of polish: better affordances for status column numbers, numbering each Benchmark in a Series, and updating performance charts to look less like progress bars.

The final design also included alerts specifically calling out low participation, so that if admins took nothing else away from the page, they would see which Benchmarks were not on track. The importance of this came from our research, which showed that actionable data was vital to admins. After my suggestion, we opted to provide these alerts via email as well.

As we were finalizing the design, I wrote a spec to guide our engineers on the changes we were making and define the exact behaviors for each interaction. This allowed them to quickly make stories in Linear that described the project in whole.

I also prepared the Figma file to make each component and state available for inspection by engineers. Together with interactive prototypes, this gave them a full picture of the feature's interactions and visuals. The design used our accessible component library to ensure properly labeled and keyboard-operable regions and components.

To complete the design phase, I wrote the email for alerting users of low participation, ensuring that admins would be aware of problematic Benchmarks even if they never logged in, which was crucial since admins often logged in only irregularly.

As engineering started on the Dashboard, we turned to the Results page. We knew from customers that it was important to compare how schools were doing relative to each other. Some admins didn't realize we already had a way to compare school-level results; the design was not serving its function. The data admins needed was there, but not in a form that was obvious or easily digestible.

I initially tried modifying the existing layout to keep scope small, adding bar charts to the existing list of schools. Realizing that wasn't prominent enough, I moved them above the results table, then adjusted their orientation to make comparisons easy and the data prominent. This met customers' gaze rather than making them squint and interpret.

During our research phase, Customer Success told us that we were putting too much emphasis on individual scores at the expense of an overall score. In some cases, users didn't notice overall scores were even available because they were subordinate to the skills. We were providing data but not telling a good story with it.

Research had also revealed that admins needed to view Benchmark data filtered to count only students who had taken both Benchmarks in a comparison view. NoRedInk itself also wanted admins to see data only from students who had completed relevant activities to demonstrate efficacy.

After experimentation, I arrived at a design that offered more prominent overall performance data alongside the required filters. The layout told a clearer story of the results, offered additional data, and provided control over filtering. I also designed the page in a modular way so that the efficacy data and filter could be easily shown or hidden based on future decisions.

This time around, feedback from our proxy users led me to improve how the page handled many bar charts at once. I was also inspired by feedback from users to level up our tooltips to display more information. After those changes, it was time to spec out the page for engineers.

Since results can come in a variety of states (one, two, and three or more Benchmarks, with data pending and missing, and with grammar or writing skills), it was important to account for each scenario. The Figma prototypes I prepared reflected this with several different flows. Development kicked off with a presentation by me to the team, with additional edge cases fielded on Slack and in Github as they arose.

To increase the likelihood that these new views would actually be used, we also aimed to improve the flow whereby Benchmarks are created. In auditing the creation flow, I found a huge amount of content that simply wasn't appropriate to use for a Benchmark assessment. I recommended eliminating this content to reduce cognitive load and improve outcomes. I also found that AI-graded assignments weren't clearly labeled, that editing an assignment wasn't consistent with the rest of the site, and that selecting dates was buggy, and suggested solutions for all of these.

Working with our Customer Success and Curriculum team members, I also discovered that a number of parameters were potentially causing less than ideal outcomes. By tightening the rules around these parameters, including requiring enough time between Benchmarks in a series, ensuring grade levels match the content chosen, and that the same classes are assigned all Benchmarks in a Series, we increased the chances of good results.

Year over year, in part due to these flow enhancements and the increased confidence CSMs had in the feature, we saw a 72% increase in Benchmarks using our Grading Assistant feature and a 17% increase in teacher adoption of Benchmarks sent out by their admins.