Back to work

Giving counselors a way to assign, track, and nudge across a 380-student caseload.

RoleLead Product Designer
CompanyScoir
Team1 designer, 3 engineers, 1 PM
PlatformsWeb · Mobile
User Research Counselor Interviews Journey Mapping Information Architecture Wireframing Interaction Design Design Systems Cross-functional Collaboration Product Strategy
The counselor Assignments view in Scoir

Scoir held everything about a student's college journey but couldn't answer the one question a counselor lives by: who still needs to do what? Counselors were running their caseloads out of spreadsheets and email. I designed Assignments — author a task once, push it to a whole filtered cohort, watch completion at a glance, nudge the stragglers in a click. The decision that shaped everything was deceptively simple: a task is a thing you make; assigning is a thing you do to it. That split is what later let single tasks grow into reusable, year-over-year Plans. In the first year, counselors created over 600,000 assignments.

A platform full of data that couldn't tell you what to do.

Scoir is a college and career readiness platform used by thousands of high schools. Students discover colleges, build lists, request recommendations, and send documents. Counselors sit on top of all of it. But for a counselor, the platform behaved like a library, not a workflow. It could show everything about a student except what they most needed to act on.

That gap collides with a hard number. The national student-to-counselor ratio is 372:1 (ASCA, 2024–25), well above the recommended 250:1. At that caseload, checking in with each student individually isn't a plan. It's the thing that never happens. So counselors coped the way busy people do: spreadsheets, email blasts, printed checklists. The actual guidance work lived outside the product built to support it. Students would log into a genuinely capable platform and find no answer to the only question that mattered: what should I be doing right now?

Dual-lane journey map showing counselor and student experience before Assignments

The before: mapping where the work was actually happening (everywhere but Scoir) and where counselors and students lost sight of each other

Two users, one feature, opposite needs.

Before drawing anything, I spent time understanding how counselors actually drive a caseload. The grade-level checklists they rebuild every fall, the reminder emails, the spreadsheet columns standing in for a status field. One word came up over and over: track. They didn't need a fancier way to communicate. They needed to know where everyone was.

Counselor interviews
Watched real caseload management in the wild. The recurring pain wasn't sending work. It was manually checking, one student at a time, who had actually done it.
The two-audience problem
The same feature had to serve a power user authoring at scale and a reluctant teenager who needed exactly one clear thing to do. Same feature, opposite ergonomics. That tension drove most of the decisions.
Map the model first
I wireframed the data model before touching screens: what a task is, what assignment does, how status flows. Getting the nouns right early saved a lot of redesigns.
Design for real constraints
An already-crowded student dashboard, a design system built for discovery rather than task management, and a teenage audience one bad week of notifications away from muting us permanently.
Lo-fi wireframes: Tasks library, New Task modal, assigning from the roster, student My Assignments view

First-pass wireframes. The annotations are the actual arguments — "create ≠ assign," "142 at once, not 1×142," "one clear next."

A task is a thing you make. Assigning is a thing you do to it.

The fastest version of this feature is "write a note, pick some students, hit send." I argued against it. If creating and assigning are the same action, every task is single-use. Every September becomes a from-scratch rebuild of work the counselor already did last year.

So I split them. A Task is authored once into a school-wide library with no audience attached. Assigning is a separate action that pushes that task to any number of recipients, any number of times: a filtered cohort, a single student, a set of parents. It cost more up front and it was the most important call in the project.

Core model diagram: Task authored once, assigned many times to cohorts, individuals, or parents

The core model. Authoring and assigning are deliberately separate verbs. The architecture decision the rest of the product would lean on.

"Design the atom so the molecule is obvious later." The quick version ships a week sooner and dead-ends. This one kept paying. It's the exact seam Plans grew out of.

Built around the roster they already lived in.

The counselor side had to feel like power tools without feeling like a database. Four things carried it.

Authoring
The create form opens with just the essentials: a title and optional dates. A "More details" drawer holds everything else (topic tags, embeddable forms, PDFs, inline video). Depth on demand, not up front.
Assigning at scale
Rather than invent a new picker, I anchored assignment to the Student Roster's existing filters. Narrow to "Class of '27, no FAFSA on file," select all, Manage Assignments. A hundred-plus students in three clicks, not a hundred repetitions.
Tracking and the nudge
Each task opens a preview drawer with overall completion and a student-by-student breakdown. Reminders go to everyone still outstanding from the same place. The tracking work that used to happen in a spreadsheet is now the default view.
Reusing what worked
Roster columns for incomplete, overdue, and complete counts let a counselor sort their whole caseload by who's behind. The spreadsheet they were keeping by hand, now built in and live.
Creating a task from the Assignments page
Adding task details — description, dates, topic, attachments and video

Authoring a task. The first screen stays light; everything optional lives behind "More details."

Bulk-assigning a task to a filtered group of students
Managing the students assigned to a single task

Assigning from the roster the counselor already knows — filter, select, assign. Managing recipients after the fact.

Filtering and managing assignments by date, topic, and status
Sending a reminder to students who haven't completed a task

Filter by status, export a view, send a reminder to everyone still outstanding. One motion.

For the student, one clear next thing.

Everything on the counselor side optimizes for scale. The student side optimizes for the opposite: a single, unmissable answer to "what now?" I carved out a My Assignments space on the dashboard. Incomplete by default, each task shows its due date, title, and an optional topic tag, with completed work one toggle away.

Completion is a deliberate tap, never inferred. Even after a student submits an attached form, they come back and mark the task done themselves. It would have been easy to auto-complete on form submission. I chose not to. The status is the student's to own, and that keeps the dashboard honest.

My Assignments on the student dashboard
A student viewing assignment details including video

The student's view. Due date, title, topic. The full detail when the counselor attached a video, PDF, or form.

Underneath both views is a shared vocabulary. Five status words (Pending, Active, Overdue, Complete, Archived) had to read correctly from three different seats: a counselor scanning hundreds of students, a student getting a nudge, and reporting that still counts archived work so history isn't lost.

State diagram of the five task statuses across three audiences

One status model, three audiences. The wording was a design decision: "Overdue," not "You failed to…"

The last piece was the quietest and nearly the most important: notifications. Assign five tasks to a junior class and the naive system fires five emails to three hundred teenagers who promptly mute the sender, taking the feature down with them. We made the cadence a product decision: new assignments batch into a single hourly digest, future-dated tasks notify at 8am local on the day they open, and reminders send immediately because they carry a counselor's intent.

Whiteboard working out notification batching

Working the notification problem out with engineering. The principle: frequency follows intent, not events.

The same task, every August — until it wasn't.

Once counselors were authoring tasks, a pattern showed up within weeks: they were rebuilding the same sets every year. The junior brag-sheet push. The senior FAFSA sequence. The freshman onboarding checklist. The work was recurring. The tool treated each task as a one-off.

Because a task was already something you author once and assign many times, the next move was almost drawn for me. Bundle tasks into a Plan that publishes to a cohort, auto-assigns the whole set, and rolls over to next year's class untouched. Then Scoir-Created Plans: expert-built, fully customizable templates, so a counselor starts from a proven sequence instead of a blank screen.

Evolution from Task to Plan to Scoir-Created Plan templates

Tasks → Plans → Scoir-built templates. Each step only made sense because of the one before it.

The Plans management interface in Scoir
Scoir-Created Plans — pre-built, customizable plans

Plans in the product and the Scoir-Created Plan templates that followed. The feature grown up.

None of it required re-architecting. The shape was right from the first sketch. The product just kept filling it in.

It changed what Scoir is for a counselor.

Before Assignments, Scoir was a place a counselor went to look things up. After, it became a place they run their year from. Author the work, assign it to the right cohort, see who's behind, close the loop. The work that used to live in spreadsheets and inboxes came home.

The clearest signal isn't a usage number. It's that the model held. The author/assign split shipped once and carried two further product generations (Plans and Scoir-Created Plans) without a rewrite. The components it introduced (status pills, the assignment drawer, roster bulk-actions, progressive-disclosure forms) were adopted across the rest of the platform.

600k+
Assignments in year 1
1k+
Custom plans created
372:1
Caseload it was built for
3
Product generations, one model
600,000+ assignments created in year 1. Over 1,000 custom plans built to date. The author/assign model shipped once and carried Tasks, Plans, and Scoir-Created Plan templates. No rewrite needed.
Next project
Apply with Scoir: A free college application for students who need it most