The problem
Turner Broadcasting had a content management system that was showing its age. The legacy software — a Windows-only application built on an unsupported codebase — had to be installed on individual machines and required planners to manage complex tasks manually, episode by episode. It combined functions that didn't belong together and separated things that did, forcing users to jump between disparate screens to do their jobs.
As the first project I worked on at Turner, I was brought in as the sole UX person to help replace it with a modern, web-based system.
Getting close to the users
The user base was small and highly specialized — broadcast TV planners who knew their workflows in granular detail. That was actually an advantage. With a small, engaged group, I could go deep rather than broad.
I started with contextual inquiry, observing planners in their actual work environment to understand how they used the legacy system, where they got stuck, and what they'd built around its limitations. One observation stood out immediately: planners were manually adding TV series to the schedule one episode at a time. Plotting a full season in the desired order and timeframe was tedious and error-prone — a limitation the legacy system had simply never solved.
The design jam approach
Rather than disappearing and returning with wireframes, I brought users and engineers into the design process together through a technique I'd developed called a Design Jam — an abbreviated, focused design studio with a one-hour time commitment.
The format was deliberately tight: after a brief introduction to the problem, participants had 15-20 minutes to sketch their own solutions independently, then 25-30 minutes to present and critique each other's ideas. Including both users and engineers in the same room had a specific purpose — users brought domain expertise, engineers brought technical reality, and the combination produced ideas neither group would have arrived at alone.
The Design Jam approach also had a practical benefit for adoption: when engineers have contributed to a solution, they're more invested in building it well.
I later presented the Design Jam methodology at Chicago Camps.
What we built
The resulting system unified content from disparate legacy tools into a single interface, giving planners the information they needed to make decisions without switching between screens.
The most impactful feature was the automated series scheduling tool — a direct response to what I'd observed planners doing manually. Instead of adding episodes one by one, a planner could now select the network, start and end dates, season, and episode range, and the system would automatically slot the series into the schedule. What had been a painstaking manual process became a few fields and a button.
The result
Scheduling time for TV series dropped by 50%. The people who used the system every day were part of building it — and they noticed.
The video below features Cindy Powell, the primary user, Eric Garber, the product manager, and Lance Cranford, the lead engineer, reflecting on the process and what the new system meant for how they worked.
What I learned
Bringing users and engineers into the same room changes things. It's easy for engineers to deprioritize a usability issue they've never seen. It's harder when a user has just sketched the same frustration from three different angles in front of them.
The Design Jam format works because it's bounded. One hour, a specific problem, pencil and paper. People who would resist a longer workshop will show up for an hour. And once they've contributed an idea that made it into the product, they tend to show up for the next one too.
The 50% time reduction wasn't the result of a clever technical solution — it was the result of watching someone do something tedious and asking why it had to work that way. That question is usually worth more than any methodology.