
“SSOR should integrate seamlessly with the [other products]. Having to switch between systems is inefficient and prone to errors.”
Challenge
Built by separate teams over many years, each of College Board’s K-12 educator tools had its own look, feel and interaction patterns.
For educators who used several of these tools, that meant lost time second-guessing simple tasks and frustration that pulled focus away from their students. Behind the scenes, College Board design teams were duplicating work.
Lead UI Designer · Product audit and Rostering Unified Component

The components audit, with opportunities for the design system
Process
College Board launched the K-12 Educator Experience initiative to unify key interaction patterns across the suite of products.
As Lead UI Designer, I audited every K-12 product and compared how each handled the same core tasks, from the dashboard to registration, ordering, rosters and getting help. I also compared the basic components that made up these core task flows, identifying pieces to be unified and incorporated into College Board's design system.
Select a product column to see its roster
Every product's roster side by side, from my roster task audit
The common task of finding a student showed the problem clearly. Each product had its own way of searching and filtering students. The initiative focused its first design phase on the Rostering Unified Component and student search flow.
We started with the three registration products, which shared the most users: AP Registration and Ordering (APRO), SAT Suite Registration and Ordering (SSOR) and the State Data Management System (SDMS). More than half of APRO’s users also worked in SSOR or SDMS.
Select a product column to see its roster.
Student Record Every piece of information each product holds about a student
| APRO | SSOR | SDMS |
|---|---|---|
| Core Content Essential information that defines the student | ||
| Student Name First, Last | Student Name Last, First, MI | Student Name Last, First, MI |
| SSD ID | SSD ID | SSD ID |
| Date of Birth | Date of Birth | Date of Birth |
| Grade | Grade | Grade |
| Not held | School Student ID | School Student ID |
| Not held | State Student ID | State Student ID |
| Not held | District Student ID | District Student ID |
| Gender | Gender | Gender |
| Race / Ethnicity | Not held | Race / Ethnicity |
| Not held | Not held | Testing School Code |
| Attending School Code | Attending School Code | Attending School Code |
| Accommodations | Accommodations | Accommodations |
| AP ID | Registration Number | Registration Number |
| Not held | Registration Status | Registration Status |
| Not held | Test Download Status | Testing Status |
| Secondary Content | ||
| Not held | Registration Timestamp | Not held |
| Dropped Student | Not held | Not held |
| Course Name | Not held | Not held |
| Exam Date | Not held | Not held |
| Order Exam (Y / N) | Not held | Not held |
| Order Status | Not held | Not held |
| Fees | Not held | Not held |
| Reduced Fee AP Fee Status | Not held | Not held |
| Special Material Status | Not held | Not held |
| Approval Status | Not held | Not held |
| Teachers | Not held | Not held |
| Section | Not held | Not held |
| Not held | Not held | Home School Indicator |
| Not held | Not held | Assessment Type |
| Not held | Not held | Test Mode |
| Not held | Not held | State Used Field State-specific |
| Not held | Not held | Modified User |
| Not held | Not held | State School Code State-specific |
| Not held | Not held | District Code |
| Not held | Not held | District Name |
Same information, different name or formatNot held
The next step involved mapping every type of student data held in each product. Some data types appeared in all three, though not always under the same name. Other attributes existed in only one. APRO’s AP ID, for example, was called the Registration Number in SSOR and SDMS, and the three products listed a student’s names in different orders.
Working with each product’s managers and the initiative’s leads, critical tasks were separated from occasional ones. From there, I explored layouts that kept core task content at the top and expanded to show details.
Student Registrations
- Students
- 22
- Enrollments
- 143
Exam Registrations
- Taking
- 290
- Not Taking
- 36
- Undecided
- 21
- Unused
- 41
Cost
- Total Cost
- $31,475
Orders
Unsubmitted ChangesYou must submit before your changes are applied.
Order SubmittedYour exam order is up to date.
Student Roster
Solution
As Lead UI Designer on a core team with a lead UX Designer and a Developer, we all collaborated on the card’s content model and feature scope, while I owned the visual design, responsive behavior and prototyping.
We moved the roster from a table to expandable cards. Unlike a table, where every field carries equal weight, cards let us group and prioritize information around how educators actually work.
Each product’s card had its own groups of information. The condensed state showed what educators needed to complete their tasks, and the expanded state showed the student’s full profile. In moderated testing, 84% of educators felt it was easier to find what they needed for their most frequent tasks.
Student Roster
The same student cards worked across APRO, SSOR and SDMS at desktop, tablet and phone widths. Core content kept the same labels and order everywhere. Each product chose which sections its roster displayed and could add its own, such as courses and fees in APRO or district and testing details in SDMS.
Search and filtering were unified with the design system’s search and filter component. We also added a table view of the roster for users who prefer scanning data that way.
Student Roster
Student Roster
Outcome
The Rostering Unified Component became one of the initiative’s models for unifying patterns across the product suite.
College Board used the project as a key proof point in its decision to bring all of its digital experiences for educators, students and administrators into a single platform. That platform is now in development, and the rostering experience is currently in beta testing.