Hand selected by the Core Engineering director as the sole interaction designer, bridging field research, IA, interaction design, accessibility, and implementation.
Field research informed task-oriented navigation, shared data views, flexible workflows, and a working front-end direction for the next-generation product.
High-stakes administration, state variation, radically different operating models, legacy complexity, and accessibility requirements.
PearsonAccess had grown around a large data and administration model, but coordinators experienced it through the work they needed to get done: find students, prepare tests, manage sessions, fix exceptions, and keep testing moving.
The challenge was to simplify the interface around those tasks without flattening the state, district, and role differences the product genuinely had to support.
Legacy PearsonAccess exposed a dense, system-oriented structure before coordinators could get to the task they actually needed to complete.
PearsonAccess managed an immense amount of student records, test data, sessions, users, and related information. Over time, that breadth had accumulated into navigation and page structures shaped by how the system stored and separated data.
Coordinators approached the job differently. They needed to find a student or session, understand its status, take the next action, and recover when something went wrong—often across several related records.
The disconnect made routine work harder to learn and created more opportunities to lose context during high-stakes administration.
One legacy failure state could require a coordinator to close the browser and start over—an unusually costly recovery path during test administration.
A new menu by itself would not solve the problem. The redesign had to clarify the underlying information model: where each type of data lived, what actions belonged with it, and how users moved between related work.
It also had to support state and district variation without turning every contractual difference into a new navigation branch or one-off workflow.
That made the work as much about product structure as screen design.
PearsonAccess served organizations with dramatically different scale and operating models. A small district might have one person doing nearly everything; a large district could distribute work across many coordinators, schools, and support roles.
Any credible solution had to reconcile:
The interface had to get simpler without pretending the underlying operation was simple.
We deliberately took the current product and next-generation Balsamiq prototype into Texas districts and Virginia divisions with very different operating models—from small generalist environments to large, specialized organizations—so we could see what was universal and what genuinely had to flex.
Seeing the same workflows across very small districts and some of the largest systems made the variability concrete: the design had to accommodate both common patterns and local operating differences.
Field research and domain interviews translated into concrete design goals: support multi-record work, flexible workflows, search-centric navigation, and a smaller set of reusable interactions.
Across field studies in Texas and Virginia, a cross-functional Pearson team interviewed district test coordinators and support staff, observed how they organized administration work, and compared the current product with the next-generation prototype.
The sites ranged from very small districts to some of the largest systems in each state. That range exposed differences in staffing, delegation, file handling, session setup, communication, and exception management that a lab study would have missed.
Several patterns became clear across the fieldwork:
The findings gave us a concrete basis for navigation, personas, use cases, and interaction priorities.
The research produced four primary district/division coordinator personas and two secondary semi-provisional archetypes for school/campus and IT coordination. They modeled responsibilities, organizational scale, staffing and delegation, technology comfort, data-file versus UI-heavy work, support dependencies, and state-policy differences—not decorative demographics.
The value was not the persona artifact itself. It was making those operating differences visible enough to design a shared platform model without assuming every customer worked the same way.
The research pointed toward a task-oriented information model: one place to find a data type, clear actions available from that context, and navigation categories that reflected how coordinators described their work.
Personas, content inventory, and navigation exercises helped separate common structure from the customer-specific variation the platform still needed to support.
Instead of building a new path for every task, the model emphasized shared data views and flexible workflows around them.
The strategy reorganized PearsonAccess around coordinator tasks while preserving the state-specific variation the platform genuinely needed.
Field research reinforced a simple but important direction: users needed to find data and perform tasks from that context, rather than navigate a hierarchy that mirrored internal system structure.
I combined content inventory, navigation design, persona findings, and use cases to define where data belonged, which actions should be available, and which concepts needed to stay consistent across states.
Navigation research grouped coordinator work into logical task categories instead of mirroring PearsonAccess’s underlying data structure.
The experience model treated common data views as stable anchors. From a student, session, or organization context, users could see status and perform the actions that made sense there.
Core principles included:
This was the bridge from research findings to interaction design.
The product needed to absorb contractual and state differences without multiplying one-off experiences.
We used personas, use cases, and context scenarios to separate true variation from differences that could share the same interaction pattern.
That distinction mattered for both usability and implementation: flexibility had to come from the model, not from adding more navigation.
Virginia and Florida registration processes differed enough that the shared model had to support meaningful variation without fragmenting into separate products.
I moved from Balsamiq wireframes into higher-fidelity interaction concepts and a working front-end prototype, using the same core patterns across student, session, and administration workflows.
Search, data grids, multi-record editing, task controls, and consistent page patterns made the model concrete enough to evaluate with coordinators and carry into implementation.
The goal was not visual novelty. It was a smaller set of predictable interactions that could carry a large amount of operational work.
The next-generation student workflow translated the research and information model into a working interaction pattern for day-to-day administration.
I started in Balsamiq, working through navigation, page hierarchy, data tables, search, selection, and task flows before investing in visual polish.
As patterns stabilized, I carried them into higher-fidelity concepts so we could evaluate not just individual screens, but whether the same interaction model held across students, groups, sessions, users, and administration work.
The model relied on a small set of repeatable behaviors rather than custom interaction for each feature.
Core behaviors included:
Consistency mattered because coordinators often moved rapidly between routine setup and exception handling.
The prototype included concrete flows for finding and editing students, assigning students to sessions, monitoring online testing, and handling multi-record tasks.
Those scenarios gave field participants something specific to react to and exposed details that abstract IA work could not: filters, IDs, session counts, bulk actions, warnings, and recovery states.
Annotated iterations worked through task progression, save behavior, cancellation, and unsaved-work recovery before those patterns were carried into the working prototype.
Once the interaction model was stable enough, I moved it into higher-fidelity visual design and a working front-end prototype.
My earlier Pearson work was hands-on front-end implementation, so inside Core Engineering I could work directly with XHTML, CSS, and jQuery and discuss implementation details with developers rather than stopping at static comps. I also audited PearsonAccess Next against Section 508/WCAG requirements, testing with screen readers and text-only browsing and delivering code-level recommendations to engineering. Accessibility was part of implementation quality, not a late retrofit.
The work produced:
The output was more than a set of screens; it was a coherent interaction system that Product and Engineering could reason about.
Texas and Virginia participants used both the current product and the next-generation prototype to work through common administration tasks while the team probed for mental models, friction, missing capabilities, and edge cases.
Participants consistently reacted positively to the prototype’s simpler layout and flow while also identifying specific refinements, missing capabilities, and operational edge cases.
Validation stayed grounded in real coordinator work, including student administration and the operational demands of managing online testing sessions.
Validation was built into the same Texas and Virginia field studies. Participants worked through common scenarios in both the current implementation and the next-generation prototype while we asked where the flow matched or broke from their real work.
We tested navigation, finding and editing records, online sessions, task workflow, and missing capabilities, then documented recommendations by scenario rather than treating positive reactions as proof that the design was finished.
Across both states, coordinators consistently saw the prototype as simpler and easier to move through than the current product.
The evidence was encouraging, but specific:
That combination mattered: the direction was validated, and the remaining work became more concrete.
The studies turned broad design principles into a prioritized refinement backlog.
They helped us:
Validation reduced uncertainty about the core model without pretending every edge case was solved.
Pearson’s planning materials included aggressive satisfaction and revenue targets for the redesign, but the artifacts I have do not show those targets being measured after launch.
So I treat the defensible outcome as a validated interaction direction and a more evidence-based implementation model—not a claimed business lift.
The strongest evidence from this work was not a before-and-after business metric. It was a validated product direction grounded in coordinator behavior and carried through from research to implementation.
The project created a clearer interaction model for PearsonAccess Next: task-oriented navigation, shared data views, flexible workflows, and reusable front-end patterns that could handle state and district variation.
It also shaped how I approached later EdTech work: preserve the real operational complexity, but do not make users carry the system’s complexity in their heads.
1. Mental models are architecture inputs. When navigation mirrors the system instead of the work, users pay the translation cost on every task.
2. “Edge cases” are often the real product. In high-stakes administration, transfers, mismatches, warnings, resumptions, bulk changes, and time-sensitive recovery are normal operating work.
3. Scale changes workflow, not just volume. A district serving hundreds of students and one serving 200,000 may use the same data, but staffing, delegation, batching, and checkpoints are fundamentally different.
4. Prototypes are most useful when they carry the model. The coded prototype let research, navigation rules, interaction patterns, and implementation constraints meet in something people could actually test.
5. Honest evidence is stronger than inherited metrics. The field studies gave us credible validation of the direction; the satisfaction and revenue figures in planning materials remained targets, not results.
6. Influence had to be earned through the work. UX was still establishing its role inside the organization, so research evidence, visible product improvements, and direct relationships with product and engineering created more traction than arguing for design authority.
