Browser-1-hrd 1.png

I designed a digital product that helps editors create interactive stories for (almost) any sport.

Company: ESPN Product: Internal Publication Tool - “Lineup Picker Tool” Duration: March — July 2024 Role: Lead Product Designer, on contract Responsibilities: content strategy, ****user workflow + problem definition, solution discovery and product strategy; changes to user flow; high-fidelity UI documentation.

Background 📋

www.espn 1.png

www.espn 3.png

www.espn 9.png

ESPN’s Visual Storytelling team produces highly original, interactive, and data-focused stories from the sports world. One of the most successful story types are “lineup pickers”, where readers play coach by deciding which athletes to play in a hypothetical game-like scenario. These stories reliably led to high engagement from their audience and the team was looking for a way to produce more of them.

Business Problem

The production of these lineup picker stories, however popular, was limited by a highly manual process and development resources needed to execute them. If the team were to produce more, they needed a way to reduce or eliminate the need to build them from scratch.

“Unfortunately, the one-off versions we have built were extremely taxing on the team and impossible to repurpose.” Stakeholder comment

Solution

A three-part system of content models for standardizing athlete data, UI components with variants for each story element, and a set of story modules defined as markup objects in the CMS. To contend with the reality that editor and data needs can’t fully be anticipated, the best solution was a one using common tools that could be used by anyone, at any time. So we designed the “product” in tools like Microsoft Excel, Figma, and ArchieML.

Frame 9079.png

My Role: Lead Product Designer (contract)

As the product lead I was responsible for identifying content, data, UX, and visual needs of the intended product and creating the project plan. I led two discovery workshops to better understand project goals and user workflows. I also worked with our data editor to establish a model for athlete statistical data that was agnostic to sport. I was responsible for informing and guiding all aspects of the UX and UI work, specifically the publishing user flows, data modeling, wireframing, and prototyping.

—

Team: Art Director, Creative Director, Data Editor, Developer, and Product Designer (me)

Insights & Learnings 💡

<aside> 💡

Here are a few things I learned:

Sometimes avoiding complexing is the best way to solve for complexity. Okay, that’s not exactly what I mean. But I did find myself in a situation where the team’s engineers were suddenly unavailable due to unforeseen circumstances — and current development work on the project needed to wait. The design and content work would continue however, as those stakeholders were unaffected and had time to guide decisions. I was still in the weeds of the product architecture and knew I needed some engineering thought partner to help me make informed decisions. So I reached out to a developer who had worked on a similar story and asked if he would help me think through product concepts on a weekly basis. While not perfect, this arrangement helped me identify tradeoffs that I otherwise would have missed. Ultimately I decided the tool needed to be “lightweight”, have separate pipelines for content and development, and be architected in such a way that developers address complexity in their own way as they have time. This is why the product runs on ArchieML, JSON, and Excel for now — until we can replace those with proper CMS patterns and data objects.
You can ‘component-ize’ more than UI elements. One of my more satisfying a-ha moments came about when trying to design a re-useable, predictable results component that could work for any kind of story, for any kind of sport. After a reader is finished picking their lineup, they receive an editorialized score, or result, that tells them how well their lineup would perform. The rub is, if every sport uses different player stats and benchmarks (i.e. batting average vs passing yards), and every story is contextualized to its sport, how could I design a result component that works across all these different contexts? The answer was to treat the calculation of the result — the mathematical operation, number of inputs, and possible acceptable outcomes — as a component. Once I saw this, I ended up with a “result component” with 5 potential variants and two possible modes: summation and multiplication. This established a repeatable structure that future story editors could understand while affording them enough variability to accommodate whatever sport they’re writing for. </aside>

<aside> 🚧