HMH Education

01 — Overview

One tool, whether you are issuing a code for a single student or for eleven thousand.

NSCAS is Nebraska’s statewide assessment, and a family cannot see their own child’s results without an access code. Someone at the district has to create those codes, hand them out, reissue the ones that go astray and retire the ones that should no longer work. This dashboard is that job, given an interface.

The difficulty is the range. The platform is used by four tiers of administrator — state, district, school and teacher — so the same screen serves someone dealing with one student whose code never arrived, and someone generating codes for every third, fourth and fifth grader across ten districts at once, eleven thousand of them in a single action. Those are not the same task, and treating them as one is how tools like this usually go wrong.

So the flow forks early and openly. You are asked how you want to find people before you are asked anything else, and each route is labelled with what it will need from you. Nothing irreversible happens until the exact scope of it has been written out, and you have had the chance to open it up and read it.

What I did

End-to-end UX and product design for the access-code dashboard and its flows
A two-path model — search for students, or select by organization
Search that tolerates partial knowledge, with a list you assemble as you go
Confirmation screens that state scope in full before anything is committed
Status kept on the record: active, inactive, expired, regenerated
Empty, error and disabled states written as part of the design, not after it

02 — Opportunities

The questions the work had to answer.

01How might one tool serve a single student and an entire district without becoming two different products?
02How might we let someone find a student when they only remember part of a name?
03How might we make the true scope of a bulk action legible before it is committed?
04How might we keep thousands of codes current — reissued, retired, still valid — and keep which is which obvious at a glance?
05How might we make a twice-a-year administrative chore learnable each time it comes round, rather than relearned from scratch?

03 — Approach

Six areas of design work.

01

Fork the path, and say why

The first question is how you want to find people, not what you want to do to them
Each route states what it will ask for — name and student ID, or organization, grade, program and group
Choosing wrongly costs one step back, not a restarted task

02

Search that forgives

A last name and a single initial is enough to return the three Smiths it could be
Student State ID offered as its own tab, for whoever has the number to hand
Results state where each student sits — district, school, grade — so the right one can be told apart from the near-miss

03

A list you build, then check

Students are added one at a time to a list that stays visible while you keep searching
The list is the thing that gets acted on, so it can be reviewed and pruned first
Nothing advances until there is at least one person on it

04

Scope stated before it is committed

The confirmation names the number — eleven thousand two hundred and twenty-six — above the button that would create them
Organizations, programs and grades are summarised as counts, then expand to the actual schools, programs and grades behind those counts
Progressive disclosure, so the summary stays readable and the detail is still there for anyone who wants to check it

05

A record that says where it stands

Every code carries a status — active, inactive, expired or regenerated — rather than only a date
Regenerate, download and deactivate stay disabled until something is selected, so the toolbar reflects what is actually possible
The code itself is copyable from the row, because that is what the row is for

06

The states nobody demos

Empty search results say what to change, not just that nothing was found
Required fields are marked and named at the top of the group selector, rather than discovered on submit
The download confirmation lists the people it covers by name, so a wrong selection is visible before it becomes a wrong file

04 — Outcomes

What the design settles.

The two audiences share one tool. The single-student case and the whole-district case run through the same screens, diverging only at the point where they genuinely differ — how you name the people you mean.

Scale is never implicit. The count, the organizations, the programs and the grades are all written out before a bulk action, and can be opened and read line by line. Nobody has to infer what eleven thousand codes covers.

The record answers the question it actually gets asked. “Is this code still good?” is a status on the row rather than a date to interpret — which is the question a district fields when a family calls.

05 — Walkthrough