Redesigning the SAT

A century of paper, three years to fix.

Before this overhaul, taking the SAT looked roughly the way it had since the Eisenhower administration: a paper test, a wait of several weeks, an envelope in the mail with a number in it. For schools, it was thick PDF binders of aggregated results delivered too late to inform anything. The system worked, in the sense that it did what it had been designed to do. It just hadn't been redesigned in a long time.

The brief was to bring the entire suite into a digital-first posture — not by skinning the existing reports and calling it a portal, but by rethinking what each audience actually needed from the data and shipping tools that delivered on it. Real-time scores for students. Interactive practice on the device they already carried. Dashboards for educators that surfaced trends instead of burying them. And underneath all of it, a system architecture that could survive being shipped to millions of users on tight academic deadlines.

The trick wasn't designing any single tool. It was designing the connective tissue between all of them while every one was being rebuilt simultaneously.

The exam content itself was being rewritten in parallel by a separate part of the organization. That meant our work had to anticipate decisions that hadn't been made yet, in some cases by people we couldn't yet talk to. A lot of the early effort was structural: mapping out where the dependencies lived, where they could be deferred, and where we had to make educated guesses and revisit later.

Mischa Williams was the lead UX architect and researcher, and most of what I learned about thinking at this scale, I learned watching Mischa work. Cross-service mapping, multi-application user flows, the way a research finding from one corner of the system has to ripple through the architecture of three others. Mischa made all of it look orderly. I'd been doing design for interaction for ten years at that point. He still raised the bar.

Four products, one system underneath.

Three related but separate initiatives, with a UI framework underneath that made the stitching possible.

The fifth thing.

Three related-but-separate initiatives, shipping on different cadences, needed a common visual and interaction language or they were going to drift apart on the way to launch. So we built one: a UI pattern library and design system, named Apricot. Mitra Schahir was the lead engineer and my counterpart on the project, and she still maintains it today. Apricot remains the UI framework at the College Board, which is the outcome you want from a design system: it outlived the project that produced it.

Map the system. Trust the team. Build a kit.

A team of sixty-five designers can move fast or it can move in circles. The difference is mostly how clearly the seams between people's work are defined. Most of my time, I came to realize, was best spent on those seams.

We started with journey maps. This work was led by Rose Kue, and the cross-service version of the student journey she produced became one of the foundational artifacts of the project, hung on a wall and referred to constantly. From there, the broader UX architecture work, the multi-application flows, the cross-product information model, got laid down by Mischa's team and became the substrate everything else got built on top of.

The design system came out of necessity. With four products shipping on different cadences, and with the visual language of the SAT itself being modernized in parallel, we needed a way to keep things coherent without bottlenecking through a single approver. So we built a kit — atomic in the Brad Frost sense, before that was a default — and gave the teams the authority to use it. It was the first design system I'd developed, and I learned by building it. Within eighteen months it was the most-cited reason internal stakeholders gave for why the work shipped on time and on budget.

The trust part was the hardest for me. I'd come up as a designer who got things done by drawing them. Now I was leading sixty-five people whose work I couldn't possibly review at that depth. The pattern I landed on was: get the parameters right — the system, the maps, the architecture — and then give the team the room to make decisions inside them. When it worked, it worked. When it didn't, the failures were almost always traceable to me having been unclear about the parameters, not the team having gotten it wrong.

Three moves we made repeatedly.

What it actually felt like, when it worked.

The Daily Practice App shipped, and then it kept shipping — over eight million downloads by the end of the program. Scan & Score did something I hadn't fully anticipated, which was that it changed the posture students took toward practice. Instead of practicing being a thing you did at a desk with a printed booklet, it became a thing you did on the bus, between classes, in the kitchen waiting for water to boil. The tool met students where they actually were.

Score reporting, both online and in print, started reading like a study guide instead of a verdict. Item-level analysis, weakness mapping, links into specific practice modules. The paper version — which we redesigned alongside the digital one because the College Board still mailed millions of reports — held its own as an artifact. I'm still proud of that one.

The K–12 dashboard replaced binders with a tool educators could actually steer with. The feedback that came back from districts in the first cycle was the thing that gave us the most institutional cover — once teachers and administrators were writing in to say please don't take this away, the project's standing inside the College Board changed.