Athena Routing

Overview

A single transportation decision can connect a student, stop, run, school, bell time, and the map beneath them.

Athena Routing is used by school transportation teams to manage the relationships between students, stops, runs, schools and bell times.

The system was powerful. But years of accumulated functionality meant a router had to understand not just transportation planning, but where each piece of functionality lived inside the software.

The redesign turned Routing from an entity-driven mapping tool into an issue-driven workspace. Instead of asking which module contains what you need, it starts with what needs your attention.

Problems

The Routing tools existed. The workflow was broken and fragmented, and users felt it.

The legacy Routing experience had grown around individual system entities. Bell times, runs, stops, selected runs, selected stops, and students each occupied their own persistent areas of the workspace. The map was surrounded by specialized controls, repeated actions, and panels that remained visible even when they contained no useful information.

The deeper issue was not simply visual clutter.

To resolve one transportation problem, users could have to move between multiple areas of the product, repeatedly rebuild their context, and remember how different pieces of information related to the task they originally started. The interface reflected the structure of the system more than the structure of the router's work.

Research

Talking to routers made us understand they think in transportation problems, not database entities.

To understand these workflows, we interviewed over 10 routing professionals across 20 school districts about how they plan and manage student transportation day to day.

Routers have been working under unnecessary pressure because the product's architecture does not fully reflect the journeys they follow to complete daily tasks. Workflows have not been structured to reduce effort, save time, and help them operate more efficiently.

Many routine activities require routers to move between separate modules, creating fragmented workflows and increasing the risk of operational errors. For example, "Student needs a stop" may appear to be a student-related issue, but resolving it involves several operational functions. Treating it as a student-only task fails to account for the complete workflow and the teams involved. It immediately raises questions about the student's school, bell time, program, geography, walking limits, nearby stops, compatible runs, capacity, and service requirements.

Research and product feedback revealed another important pattern: many records presented as separate items in the system were closely related and could be managed together. The opportunity was therefore not simply to improve how information was displayed, but to help Athena recognise the relationships between tasks, streamline workflows, and make routers' daily activities more efficient.

Explorations

Before refining the interface, I used working prototypes to test how issues, records, and map context could behave as one continuous workspace.

The challenge was not simply to rearrange screens. It was to decide which parts of the routing workflow should remain connected, and where complexity needed clearer boundaries.

My company is big on AI acceleration to test and visualise ideas. I used AI to build a functional HTML prototype quickly, then worked through representative routing scenarios to evaluate the architecture, expose gaps, and compare alternatives. Some ideas established the final direction. Others needed to become more contextual or move into a separate mode.

01 Exploration

From entities to issues

An early concept replaced separate Students, Stops, and Runs starting points with a prioritised Queue. This made operational problems visible without removing a Browse path for experienced routers who needed to leave the recommended workflow.

Scrapped, design was not complete

02 Exploration

From map layers to contextual data

I explored replacing scattered map-layer controls with one Load Data entry point that could be opened without leaving the active issue. The concept centralised the choice, but it also exposed a limitation: a broad catalogue still treated every dataset as equally relevant.

Scrapped, did not fully solve the problems

03 Exploration

Temporary drawers to stable context

The next exploration tested whether a router could inspect an individual student without abandoning the task that brought them there. The active issue, map position, selection, and related student information remained available together. Tabs changed the information being viewed.

Scrapped, did not group the users as we intended

04 Actual Design Exploration

Bringing the system together

After exploring responsibility, workload grouping, and contextual data separately, I brought the strongest ideas together in one complete Routing workspace.

The goal was to test whether a router could move from understanding what needed attention to investigating an individual record without leaving the workspace or reconstructing the task. Each layer of information needed to appear in response to the work while preserving everything that came before it.

01Starting with the work that needs attention

The redesigned workspace begins with operational issues instead of separate student, stop, and run modules. The Queue organises work into Needs Attention, Review, and To Do, giving routers a clear starting point for understanding what requires action.

The map remains intentionally quiet until an issue is selected. This protects geographic space and prevents unrelated information from competing for attention before the router has chosen a task, with toolboxes giving access to the right actions, named on hover.

02From one shared queue to My Queue

Not every router is responsible for the same schools, programs, bell times, or operational issues. I explored a customisable queue that allows each user to define their regular responsibilities once and quickly return to the work most relevant to them.

Users retain access to the Full Queue, while My Queue reduces repeated filtering and helps priority issues surface faster.

03A workspace that adapts to the task

Once a router selects a group or students, the workspace adapts around the task: the navigation can collapse to create more map space, Load Data surfaces relevant runs and transportation information, and detailed student or group context can be opened without losing the active selection, loaded routes, or map position. This allows the router to move from issue to resolution within one continuous workspace.

Trade-offs

Athena needed less simultaneous complexity, not less operational depth.

School transportation is inherently dense. Routers need detailed records, geographic accuracy, operational flexibility, and room for district-specific judgement. Simply removing information would have made the interface appear cleaner while making the work harder.

The redesign therefore focused on when complexity should appear, how recommendations should be explained, and which decisions needed to remain reversible. Although it comes at the cost of consuming a lot of screen space, it still gives users the option to close what they are not currently using.

Expert routers need dense tables, records and maps, but not all at once, so secondary details are revealed progressively as the active task calls for them rather than competing for attention from the start. The system suggests groups, relevant map data and compatible runs, but every recommendation stays inspectable and can be modified, ignored or overridden. Stripping out every panel would return map space at the cost of forcing routers to rebuild their task each time, so the active issue and working set persist while secondary panels collapse when they aren't needed. Students, stops, runs, schools and bell times remain the familiar concepts they always were; what changed is how they connect, with the workflow starting from an operational problem instead of the product's underlying data structure. And while the Queue and its recommendations offer a clear path through the work, Full Queue, All Students, Browse and manual selection stay available for the routers who need a different one.

Solution

One issue, all connected workflows

The final direction brings responsibility, operational issues, records and geographic information into a single continuous workspace. A router no longer moves between separate student, stop and run modules. They start with the work that needs attention, and a student can go from an unresolved record to an assigned transportation plan without leaving Routing.

The Queue surfaces issues like "Students need a stop assigned" with counts and priority, so the scale of the work is clear before anything is opened. Suggested Groups then identify students who can be handled together, with the rationale inspectable and All Students always one step away. Once a working set exists, Load Data brings in only what the decision needs (eligible stops, school destinations, walking limits, compatible runs) and the assignment is resolved in place, with student details beside the map, an existing stop reused or a new one created, and nothing rebuilt along the way.

Design system

Density without noise

To create consistency across Athena's complex interface, I built the design system on a token-based foundation rather than styling each screen independently. I created a reusable variables library in Figma for colour, spacing, sizing, radii, and interaction states, then connected those variables to the components used across the Queue, tables, panels, forms, and map controls. Keeping these decisions in one shared source allowed updates to flow throughout the file, reduced visual inconsistencies, and made the system easier to maintain and scale as new Routing workflows were introduced.

AI in my workflow

AI helped explore ideas faster, but it did not replace thinking about user-centred design.

I started with the customer problem, the existing workflow and a hypothesis about how Routing could operate, then used AI to turn that hypothesis into an interactive HTML prototype I could explore far earlier than a polished design. Walking representative routing scenarios through it exposed assumptions that static screens would have hidden.

The grouping work is the clearest example. The first exploration made large issues visible but left the router with a long flat list. Testing the interaction produced Suggested Groups, which raised a harder question: how does a router trust a group the system made? That critique produced Group Details and an explanation of why those records belong together. AI accelerated prototyping, alternatives, edge cases and early copy. Problem framing, workflow architecture, trade-offs and final decisions stayed with me.

Impact

Reducing the work around the work

While testing, the time to complete assignments and routing got significantly shorter, because the system does more of the work and routers simply review and correct as they see fit.

Reflection

The architecture followed the system, not the people using it.

Athena's original structure made sense for the system it was built around, but over time things change. I don't think the right questions were asked. If the roles had been looked at properly, the workflows that make those roles' work easier would have been factored into the architecture of the product itself. Instead the architecture followed the data, and routers were left to bridge the difference.

Using AI to demonstrate the alternative made the proof of concept quick, and made it far easier to explain to other people how the product should actually be structured and where the efficiency was hiding.

The bigger lesson for me is that feature completeness doesn't mean a product is working well. Athena already had the capabilities routers needed, but a routine task still took far too long, and routers were doing work the system could have done a large part of for them. That changed how I think about enterprise products. A product isn't finished because every feature exists: it's finished when someone can complete the job without having to assemble the workflow themselves.

The beta is now with districts, so the numbers in this case study are still based on testing rather than production. What I'm most interested in next is whether the Queue holds at real district scale, and whether Suggested Groups becomes something routers trust enough to use without constantly second-guessing it.