ACES Program Explorer

Students needed an interest-first way to navigate a growing catalog

New online courses could stack into certificates and graduate programs, and the catalog kept growing. The only way in was an alphabetical list of departments. Admissions kept hearing the same thing, and so did we at in-person recruiting events: prospective students described what they cared about, not which department owned it.

I tested whether interest categories matched how students searched

I treated the Admissions signal as a hypothesis, not a conclusion. Four inputs, and each one settled a different decision.

• Admissions conversations and recruiting eventsSettled the shape of the whole thing: an interest-first structure, not a cleaner version of the department list.
• Card sorting and tree testingChecked whether the interest categories were ones a prospective student could actually navigate. They became the ten interest areas the filters ship with.
• The related-programs workshopTurned assumed connections into the related-program associations that ship on every detail page.
• Competitive review of peer institutions, online-learning leaders, and the business college inside the universityShowed what a student needs to compare two programs at a glance. That decided what belongs on a card and what waits for the full program page.

I mapped every major against every interest area

I settled the filtering behavior before anyone built it

The filter rail, the result count and the card anatomy were decided in wireframes, in a shared Illinois component library, at mobile and desktop side by side.

• Filters go in a left rail, grouped by the question a student is actually askingType, format, topic, department. Topic sits third because a prospective student can answer it without knowing the college. Department sits last because in the old site it came first.
• The result count sits above the grid, not beside the filtersIt is the answer to the filter you just changed, so it belongs where your eye lands next, not off to the side with the controls.
• The card is one link, not fivePhotograph, name, degree type, one line of description, format. A screen reader announces one program per card instead of walking every element inside it.
• At mobile the rail collapses above the results and the grid goes to one columnBoth breakpoints were drawn at the same time, which is why the card keeps the same five parts at every width.
• Filtering to zero is a designed stateOver-filtering ends on clear all filters and browse all programs. A result set of zero still has to go somewhere.

The final list only needed the degree names

The Explorer page was for students who did not yet know what ACES offered, so it needed filters and cards with enough information to compare programs. The campaign page above used a selected set of the same cards without filters. The main degree pages did a different job. They paired a list of programs with application information, dates and other page content.

I explored three treatments for that list view to see how much information each row needed.

We built a simpler final version than any of these: a bulleted list of linked degree names, without department or format. The list pulled from the same program records as the Explorer. Staff could change a degree once instead of updating a second list by hand.

Keyboard and screen-reader users had to keep their place

Accessibility was in the interaction requirements from the start, targeting WCAG 2.1 AA. A design review by the Website Implementation Guidelines Group, the cross-campus web community I co-chaired, caught a filtering defect: every selection reloaded the page and sent keyboard and screen-reader users back to the top. I owned the fix. I specified AJAX filtering and directed the engineers who built it, tested it myself, and took it back to the group to test again. Results update without a page reload, focus is preserved, selections persist through browser back and forward, and the result count is announced.

Walk the five discovery flows