PearsonAccess Next

Project detail

• Core workflow challenge: Navigation and task structure reflected Pearson’s system more than coordinator mental models.
• Operational reality: Student records, sessions, users, files, reporting, and exception handling had to work together under time pressure.
• Constraints: State rules, district scale, staffing, roles, and bulk-data practices varied widely.
• Design challenge: Make navigation and decision-making easier while keeping the operational complexity coordinators still needed visible.

Navigation followed the product structure

PearsonAccess handled student records, test data, sessions, users, organizations, and state-specific administration rules. The interface exposed that structure directly, so routine work often started by figuring out where the right data lived.

The bigger pain surfaced during testing windows. Coordinators often needed to make the same change across a group of students, prepare a session, fix transfers, order materials, or move through several related tasks in sequence.

Too much of that work was linear. They found a student, completed an action, then repeated the process for the next student or the next task.

The Texas home screen surfaced system structure, alerts, and administration controls before coordinators reached the work they needed to complete.

One recovery state required a coordinator to close the browser and start over. During test administration, the redesign offered an opportunity to make recovery much more direct.

Designing around the coordinator workflow

Cleaner navigation was only part of the answer. We also needed a way to keep selected students together while the coordinator moved through related work.

State and district differences still had to fit within one product, with contractual variation handled through configuration and shared patterns.

That made the redesign as much about the interaction model as the navigation.

Designing for the full context

PearsonAccess served organizations with dramatically different scale and ways of working. A small district might have one person doing nearly everything; a large district could distribute work across many coordinators, schools, and support roles.

The redesign had to support:

The interface needed to be easier to use while still supporting all of that operational variation. Business goals for the redesign included a 25% increase in user satisfaction and 30% revenue growth through retention and new contract wins.

• Common interaction patterns with state-specific requirements
• Single-record work with bulk uploads and multi-record actions
• Simple day-to-day tasks with high-stakes exception handling
• A more intuitive model with the realities of existing data and implementation constraints

Researching the work in context

The personas made the operating differences concrete. Colby represented a smaller Texas district where one coordinator carried most of the testing work. Julia represented a more team-based, data-heavy district. Barb represented a larger Virginia division where coordinators needed to work across multiple students and related tasks.

That range helped us see where the product needed flexibility. The same testing task could be handled by one person in one district and split across several people in another, while the underlying workflow still needed to feel familiar.

Colby represented a smaller Texas district where one coordinator handled most testing work directly in the UI.

Julia represented a more team-based Texas district with heavier data work, delegation, and faster movement across tasks.

Barb represented a larger Virginia division where coordinators needed to manage multiple students across related tasks and custom workflows.

What we learned

I started with Pearson’s state-program SMEs and coordinator surveys to map policies, recurring tasks, edge cases, technology comfort, and workarounds. That gave me enough to build the first prototype. Then I took it into field studies in Texas and Virginia, where we watched coordinators work through real scenarios and compared the prototype with the current system.

The field work showed two things that shaped the redesign: coordinators needed to work across multiple students at once, and the same job looked very different depending on staffing, delegation, state policy, and technology.

• District size changed who performed work, how responsibilities were delegated, and how much bulk processing mattered.
• Common workflows were recognizable across sites, but state and local rules created meaningful variation.
• The next-generation prototype generally matched common scenarios and was consistently perceived as simpler than the current product.

Personas captured different operating contexts

The research produced four primary district and division coordinator personas plus two supporting role archetypes. The useful differences were staffing and delegation, state rules, technology comfort, file-heavy versus UI-heavy work, and how much support each coordinator had.

The same task could be a one-person job in one district and split across several people in another. The personas helped us decide which differences needed product flexibility and which could share the same interaction.

From research to navigation rules

Field research gave the interaction model a simple rule: coordinators should be able to find the students or sessions they needed, select the records involved, and keep working from that context.

I used the content inventory, navigation work, personas, and use cases to define a smaller set of stable places in the product: students, groups, sessions, users, organizations, and test setup.

The navigation grouped work around the tasks coordinators came to complete. The data views became the place to select records and act on them.

• Goal: Make the right data and actions easy to find through coordinator tasks and language.
• Inputs: Student, organization, test, session, user, and reporting data; state and role context.
• Core interactions: Search, filter, select, edit, assign, upload, monitor, resolve, and report.
• Rules: Collect like information and tasks together; avoid multiple representations of the same data.
• Scale challenge: Keep one understandable model while allowing contractual and state requirements to vary.

Designing around data + tasks

From a student, group, or session view, coordinators could see status, select multiple records, apply actions in bulk, and continue into the next related task.

For work that naturally came as a sequence, the selected students could carry forward into related tasks, such as building groups and preparing test sessions.

That reduced the need to repeatedly search for the same students as the coordinator moved through a testing workflow.

• Orient coordinators with dashboard and status summaries, then organize navigation around their mental models and common task groupings
• Provide a single, consistent representation of each data type
• Make high-frequency actions available where users were already working
• Support bulk and single-record work with the same underlying patterns
• Keep state-specific behavior configurable within one shared product model

Planning for state and contract variation

The product needed a shared model that could absorb contractual and state differences across deployments.

We used personas, use cases, and context scenarios to separate true variation from differences that could share the same interaction pattern.

The interaction model had to handle that variation while keeping navigation stable.

Virginia and Florida registration processes differed enough that the shared model had to support meaningful variation without fragmenting into separate products.

From wireframes to a working interaction model

I started the interaction work in Balsamiq so we could test structure and workflow quickly before spending time on visual polish.

The higher-fidelity prototype then connected students, groups, sessions, users, and organizations through the same interaction model.

Reusable interaction patterns

The goal was consistency: find the records, select one or many, take an action, and keep enough context to move into the next task.

Core behaviors included:

Consistency mattered because coordinators often moved rapidly between routine setup and exception handling.

• Find the right data quickly through search, filtering, and clear navigation
• Use the same interaction model for one record or many
• Keep status, context, and available actions visible together
• Use consistent task patterns across students, groups, sessions, and users
• Surface warnings and exceptions where users could resolve them

Testing the model in real workflows

The prototype covered the work coordinators actually had to do, including finding and editing students, creating groups, preparing sessions, monitoring testing, and handling changes across multiple records.

Those scenarios exposed details a simple happy path would miss, including selection state, bulk actions, save behavior, power failures, fire drills, suspected cheating, incomplete student statuses, and recovery when work was interrupted.

Annotated iterations worked through task progression, save behavior, cancellation, and unsaved-work recovery before those patterns were carried into the working prototype.

From visual concept to coded 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 development, so I could work directly with XHTML, CSS, and jQuery and talk through implementation details with engineers. I also ran a full Section 508/WCAG audit, tested with screen readers and text-only browsing, and gave engineering code-level fixes. Accessibility stayed part of implementation quality throughout the redesign.

What the design made concrete

The work produced:

The screens, interaction rules, and working prototype gave Product and Engineering a concrete reference for implementation.

• A task-oriented navigation model grounded in coordinator mental models
• Reusable patterns for search, filtering, grids, selection, and multi-record tasks
• Concrete workflows for student, session, user, and online-testing administration
• A higher-fidelity visual direction that could be evaluated in context
• A working front-end prototype connecting interaction decisions to implementation

Validating in the field

Validation happened in the same Texas and Virginia field studies. Coordinators worked through common scenarios in the current system and the prototype, and we asked where the new model matched or broke from their real work.

Once coordinators started working through realistic scenarios, the task-based model made sense quickly.

What the field studies showed

They could see how multi-student actions, clearer navigation, and carrying context across related tasks could save time during the testing window.

The feedback was positive, and the sessions sharpened the workflow before implementation.

That gave us something useful to take back into the Agile team: a direction people understood, plus specific interaction details to refine before implementation.

The studies turned broad design principles into a prioritized refinement backlog.

They helped us:

Validation strengthened the core model and clarified the highest-value refinements before implementation.

Online-session monitoring was one of the workflows field studies helped refine, including status visibility, student counts, and recovery needs during active testing.

• Texas participants described the prototype as “intuitive,” “so easy to use,” and “10 times better” than the current product.
• Virginia participants described the direction as “clean and uncluttered” and responded positively to the streamlined interaction model.
• The prototype generally matched regularly performed scenarios across both studies.
• Participants still identified missing filters, data details, session behaviors, warnings, and state-specific needs.
• Confirm task-oriented navigation was understandable to both frequent and less-frequent users
• Refine search, filters, IDs, counts, and multi-record actions around real coordinator needs
• Strengthen online-session monitoring and recovery patterns
• Separate universal workflow needs from state-specific requirements
• Carry field evidence directly into subsequent prototype iterations

What I took from the work

1. Design around the unit of work. Coordinators rarely worked one student and one task at a time. During a testing window, they moved across groups of students and clusters of related tasks.

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. Small and large districts may use the same data, but staffing, delegation, batching, and checkpoints can be completely 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. Let people experience the model. Coordinators who were hesitant about another system change quickly saw the value once they could work through realistic scenarios in the prototype.

6. Build influence through evidence and partnership. Research, visible product improvements, and direct collaboration with engineering gave the redesign momentum across the team.