I turned a crowded article page into a shared product system

Section 1 · The problem

One page. Many owners.

The article page is AP's real front door: 60% of visits land directly on an article, compared with 5% on the homepage.

But the experience had grown module by module. Every team had a valid goal; no one owned how those goals composed into a single read.

Section 2 · Research

Listen before layout.

I separated reader needs from organizational needs, then looked for the tension they shared. Six user interviews showed how the page felt. Ten stakeholder interviews explained why it had become that way.

Section 3 · Designing the collaboration

I built the room a design tool.

For two 90-minute workshops, I created a kit of reusable article components in Figma. Participants could build a desktop article, translate it to mobile, and feel the cost of every decision.

The wireframes made abstract priorities concrete: if a team moved an ask up, something else had to move down.

Section 4 · Design decisions

Measured, not styled.

Three decisions carried the reading experience: how long a line of text runs, how much air sits around anything that is not text, and where the Primis player lives, the video advertising and recirculation unit that runs on every article. Each was settled by comparison and measurement rather than by preference, then verified in the build.

The same values went to Ad Ops, because a placement rule written in paragraph counts drifts the moment paragraphs get taller.

Section 5 · Prototype, refine, build

Prototyped in code. Finished in Figma. Built for real.

I built every part of the article page in code first, as a working prototype, using OpenCode. That let us judge each component with real content and real behavior before committing to a design.

From there I refined and finalized the designs in Figma and committed them to the system. Now they are being built into AP’s codebase, each one a fully functional component in Storybook, which becomes our coded library.

Section 6 · From code to prototype

Code became an early design tool.

With the components built, assembling a whole article was composition rather than construction. Instead of waiting for a final handoff, I could put hierarchy, responsive behavior, modules and real article length in front of someone in a browser.

What we landed on is the visual system, measured against the live site. The two prototypes below are not a decision. They are the next round of tests, built so the questions the workshops left open can be answered against something real.

Section 7 · From prototype to product

The prototype became the system.

The coded directions were not disposable demos. Working with Development, we translated the patterns into reusable Storybook components for AP's new headless front end.

Designers could now work with the same building blocks the product would use, making later experiments faster, more consistent, and easier to implement.

Section 8 · Testing and outcome

Test the direction, not the taste.

I first tested preference to choose a direction, then used a live experiment to learn whether the new hierarchy changed behavior without damaging the business around it.

Both preference studies set a variant against the same control: the article page as it was live at the time of testing, not as it stands today. Eleven participants across the two.

Preference tells you which page people say they would rather read. It does not tell you what they do. Both results below are directional, which is why the prototypes in section 5 are still queued tests rather than a decision.

What this project changed in my practice

Design the collaboration. Then design the page.