Category Landing Pages
A reader finds a Northeastern story through Google, likes it, and wants more like it. They click the section name at the top. What loads is twenty four stories at exactly the same size, with nothing to say which one matters and no way to narrow down to the part of the subject they came for. Arts and Entertainment holds ninety seven film stories and eighty seven music stories. The page offered no route to either.
I led this end to end. I ran the heuristic audit that set the brief, designed six rounds in three weeks, built every prototype as working front end code, and QA'd my own work in a real browser before handing it to development. It is now being built in WordPress.
Client
Northeastern Global News
Type
Product Design · UX Engineering · Design Systems
Year
2026
Role
Product Designer & UX Engineer
Process
The audit came before the design.
I did not start with a layout. I started by putting the existing page in front of the digital team and asking them to mark it up. I ran it in Pastel, so every comment was pinned to the live page at the exact spot it referred to, not written in a document next to a screenshot.
Seven reviewers left twenty seven comments on the live category page, a heuristic pass across hierarchy, navigation, spacing and wayfinding. Those comments became the brief. Four senior reviewers then went through every round that followed in the same Pastel review, comment by comment, with sixteen coming back on a single round.
When two layout directions both had merit, I merged them rather than defending mine.
The template was the problem, not the page.
Nine categories. One template. Every story at the same size, no featured story, no hierarchy, no way to narrow down inside a subject.
I measured before I designed. Twenty four story images at identical dimensions. Headlines running one hundred and thirty one characters per line against the fifty to seventy five that Nielsen Norman recommends. Zero subtopic navigation anywhere on the page.
The brief I was handed was that the section front felt weak. I turned that into numbers, because a number can be designed against and a feeling cannot.
I sketched before I prompted.
Three structurally different directions on paper first. The Lead, built around one dominant story. Magazine Grid, equal weight across the page. Reading List, strictly chronological.
Paper is faster than any tool for deciding whether a structure holds, and it kept the thinking mine before software had a chance to shape it. Round one then shipped with grey placeholder blocks instead of photographs, so the structure was judged on its own before imagery could flatter it.
Method
Six rounds in three weeks.
I photographed the sketches and used Claude Code to turn them into functional, responsive prototypes. Not mockups. Real pages, running on live newsroom content, that stakeholders opened on their own phones.
That changed the review. Instead of describing how something would behave, I sent a link. Feedback came back specific because people were reacting to the real thing. Six complete rounds, one hundred and forty commits, and not a single engineering ticket.
What I rejected.
The tooling was fast. It was not right by default, and the judgment is the job.
It built the photo carousel by copying a component already on our site, and inherited a real defect along with it. Under certain widths the transform silently failed and the carousel stopped moving. I found it by testing the output rather than trusting it, fixed it, and flagged the original for the team.
It proposed a comparison showing two different parts of two pages side by side. Nothing was actually comparable, so a reader could not see the difference the slide claimed. I replaced it with a plain list of what sections each page carries, where the absence reads instantly.
It wrote dense, explanatory copy by default. I cut it back every round.
Every design decision was mine. Every output was verified in a real browser at real widths before it counted as done.
Design System
I used the library's own configurations, not lookalikes.
The newsroom runs a component library in Storybook: eighteen components, five foundations, one hundred and fifty eight stories.
The App Bar ships three configurations. I used logo and date, which is why the date sits beside the wordmark on every page. The class on my page reads is-config-logo-and-date, the same name the library gives it, so a developer opening the prototype knows exactly which variant to reach for.
The newsletter signup came across whole, real markup and real modifiers rather than a redrawn panel.
Colour was the discipline underneath all of it. Twenty nine tokens, and picking one means choosing a semantic role that already carries its contrast pair, not a hex value. I found five that had drifted from the specification and corrected them.
Three things the library did not have, I built: the ranked Most Read strip, the subtopic archive card, and the campus photo carousel. Each one designed to sit inside the system rather than beside it, so it can be contributed back.
One card, built for seven doors.
Seven subtopics each needed a link to their own archive. The obvious move is to design seven links. I designed one card instead, with two variants resolved from a single lookup: a campaign variant carrying a real logo, and a type variant setting the topic name in the display serif.
Commencement ships the campaign variant today, because it is the only subtopic with a genuine destination behind it. The rest are built and wired, held back until each one has somewhere worth sending a reader. Shipping a door to an empty room is worse than no door.
Adding the next one is a lookup entry, not a design request.
Decisions
A number settled it.
A reviewer said The Latest felt too wide. I measured it: one hundred and thirty one characters per line, against a comfortable range of fifty to seventy five. I restructured the column to forty four.
The same pass caught five separate links that all announced themselves as See All to a screen reader, with no way to tell them apart. Each one now names its own destination. Every new surface was measured for contrast: 4.56 to 1 and 13.28 to 1, both passing WCAG AA.
Two buttons that promised the same thing.
A tester clicked the topic archive expecting more stories on the page. It took them somewhere else entirely. The archive link sat directly beneath Load More, both styled as buttons, with nothing to say one stayed and one left.
I moved the archive up into the sidebar beside the newsletter and gave it a bordered card with an arrow instead of a filled pill. Load More now sits alone at the end of the list with nothing competing beside it. One button, one job.
One build, three devices.
Most readers arrive on a phone. So the page was designed for a phone, a tablet and a desktop as three real targets, not as one layout with breakpoints bolted on afterwards.
On desktop the featured story runs beside a secondary column and the topic nav sits on one line. On tablet the nav wraps to two lines and the stories stack into a single reading column. On a phone the masthead drops to the lettermark, the nav becomes a swipeable row, and the newsletter moves from the rail to the flow.
Every round was checked on all three before it was called done.
Same component, three different shapes.
The campus photo module shows five images on desktop in a graduated cascade, each narrower than the last. At tablet width the same five tighten. On a phone it shows one full image plus a peek at the next, so it still reads as a set. The archive link moves from a small pill to a full width button sized for a thumb.
The content never changes. Only the frame does. That is the difference between a responsive component and a page that has been squeezed.
The whole page holds the same way. I verified at 1440, 1024, 768 and 390 rather than designing at one width and hoping.
Not everything good ships.
Not every category gets the same page.
The campus photo module belongs to University News. Arts and Entertainment does not carry it, because that category does not produce the photography to sustain it. Same skeleton, different sections.
I kept that module when it was flagged for removal. Our photographers produce high volume and had recently lost one of their main placements, so the module was doing real work for real people. That one was a judgment call about the newsroom, not about the layout.
I built both pages rather than describing the difference, so it is something you can click between.
Craft
Some of it took three tries.
The carousel did not land first time. The first build left dead space on the right of a full width section. The second cropped every photo, because the frame was close to 2:1 while every photo in the module is 3:2. The third showed six columns, and the last four were too narrow to read as photographs.
What finally worked: the frame height derives from the photo ratio so nothing is ever cropped, five columns instead of six with each step narrower than the last by a constant ratio, and the open photo stretching to fill whatever the collapsed ones leave so the row always reaches the edge of the section.
Three tries, and the third one is the one I would defend.
Nothing was overwritten.
Six rounds, each frozen at its own public URL before the next began. Every decision written down alongside the reasoning behind it, not only the change. A handoff document detailed enough that a developer who attended none of the reviews can build it correctly.
The system outlives me on it. That was the point.
Outcome
Headlines went from one hundred and thirty one characters per line to forty four, a sixty six percent reduction, landing inside the published readability range. Five ambiguous links became five named destinations. Contrast measured and passing AA on every new surface. One live production defect found and fixed.
One card component now serves the subtopic archive pattern, and the next one will take a lookup entry rather than a design cycle.
Six rounds remain live at their own links, every decision is written down, and the WordPress build started without needing me in the room.
These are design and quality results. Reader engagement after launch has not been measured yet, so I am not claiming traffic gains.
Research helped me identify the problem. Hand sketches helped me explore the possibilities. AI accelerated implementation. UX engineering made the ideas interactive. Testing and human judgment determined what worked.
