Contextual Inquiry and Collaborative Design to Replace Turner Broadcasting's Legacy TV Program Planning System with a Web App

The problem

Planners had to jump between screens and schedule series one episode at a time in a 21-year-old Windows application.

Turner Broadcasting System was an Atlanta-based Time Warner subsidiary behind CNN, TBS, TNT and Cartoon Network. Program Planning was the application broadcast TV planners used to decide how many times content would run each month. Its output set what Turner paid rights holders. It was one of five legacy applications, then 21 years old, that Turner planned to replace over about five years.

The software was Windows-only, built on an unsupported codebase and installed on each planner's machine. It combined functions that did not belong together and separated ones that did, so planners jumped between disparate screens to get the information they needed to make decisions. It also made them add TV series to the schedule one episode at a time, which was tedious and error-prone. Turner wanted a modern, web-based system with room to support digital efforts later.

My role and the team

I was the only UX person, and I worked as both UX lead and business analyst for the product manager and the engineers.

The product manager directed my work. I worked with the lead engineer, the other engineers and the primary user, one of a small group of highly specialized planners. I led contextual inquiry, facilitated the Design Jams, produced the paper prototypes and wireframes and carried the planners' answers back to the team. My official title was Expert Interaction Designer.

The planner team was three people: two planners and their manager. The manager took part in the design reviews but not the Design Jams, and the two planners did the timing.

This was one of two applications that shipped in a planned five-year, five-application replacement. Titles shipped first and Program Planning second; work on a later scheduling application was paused before it shipped. The team was agile, with stand-ups and iterations, and the planners were a short walk away.

How the work ran

I watched planners work, designed with them and the engineers in one-hour Design Jams and kept a stand-up to approval loop so answers never sat for weeks.

1. Step 1ObserveContextual inquiry at the planners' desks
2. Step 2JamOne-hour Design Jams with users and engineers
3. Step 3WireframeReviews and testing with the planners
4. Step 4EmbedStand-up questions answered and approved fast

Step 1: Observe the planners

Watching planners add a series one episode at a time pointed straight at the feature that mattered most.

The user group was small and highly specialized, and they knew their workflows in granular detail. With an engaged group, I could go deep rather than broad. I started with contextual inquiry, observing planners at their desks to see how they used the legacy system, where they got stuck and what they had built around its limits.

One observation stood out immediately: planners were 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, and the legacy system had never solved it. The biggest improvement in the project came from watching someone do something tedious and asking why it had to work that way.

Step 2: Design with users and engineers

One-hour Design Jams put users and engineers in a room, and the users said they could contribute, even though they were not designers.

I brought users and engineers into the design process together through Design Jams, an abbreviated, focused design studio that I adapted from the studio method and ran with a one-hour time commitment. After a brief introduction to the problem, participants had 15 to 20 minutes to sketch their own solutions independently, then 25 to 30 minutes to present and critique each other's ideas. I followed with paper prototyping. I used Design Jams for the bigger features, not for every decision.

Users brought domain expertise and engineers brought technical reality, and the combination produced ideas neither group would have reached alone. When engineers contribute to a solution they are more invested in building it well. I could not get a team to commit to a week-long design studio, but I could get them for an hour.

The primary user said on camera that she was nervous at first because she was "not a designer," but that after seeing what others drew she felt she could draw and contribute. The lead engineer described the jam sessions as something the team had not worked with before, getting in a room with the users to sketch out a use case, and said the result was "no surprises" because the users helped build the system from the ground up.

I later presented the Design Jam approach at Chicago Camps.

Step 3: Check shared understanding

Wireframes gave planners and the team a shared language, so both sides could check they understood each other.

Each time something was ready, I reviewed it with the two planners, taking them from sketches to polished designs. I tested prototypes and the live build with them, and I did the research and testing myself. I took wireframes to the planners, a short walk away, and they reviewed them there. The wireframes also carried interaction patterns that used color and layout, so the screens needed less text.

The primary user said the wireframes were what let her tell whether I understood what she was saying and whether she understood what I was drawing. She said the team was "speaking the same language," which she called very difficult to do. The lead engineer said I helped fill gaps in interaction patterns that developers sometimes need help bridging.

In review, planners showed me the design needed to change

My first sketch of the series scheduler assumed planners would schedule a full season at a time. In review, the planners told me they sometimes scheduled half a season, or placed seasons in different time slots during the day. I changed the design to match, and the shipped tool handles full seasons, partial seasons and split time slots.

Step 4: Work embedded in the team

A stand-up to approval loop let me answer engineering questions with planners the same week instead of weeks later.

I worked inside the agile team. When an engineer had a question, it came up at stand-up. I walked over to the planners, sketched a quick UI, brought it back and got approval so it landed in the next iteration. When there were more detailed questions, planners also came to sit with the team and answer them. As the lead engineer put it, contact with users went both ways and it worked great.

The product manager had worked with the lead engineer on earlier projects with nobody in this role, and the team had waited a week or two for a customer answer, then had to rehash what the question was. He called this experience the opposite of that. Fast answers protect momentum: the cost of a question sitting for two weeks is not only the delay but the lost train of thought.

In the video, recorded in October 2012 while the project was still underway, the product manager said the constant customer involvement "propelled our velocity" and that the team was on or under budget at that point. He said that without it he expected the timeline to slip and the budget to suffer. That is his view at the time, not a final result, and I did not manage the budget. The lead engineer said a UX designer is vital on big projects like this one.

What we built

The system put everything planners needed in one interface and could schedule a whole series from a few fields.

The resulting web-based system unified content from the 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 had observed planners doing by hand. Instead of adding episodes one by one, a planner could select the network, start and end dates, season and episode range, and the system would slot the series into the schedule.

Outcome

Planners timed series scheduling at about half the old time, and the team credited constant customer involvement for its pace.

The two planners who used the software did the timing themselves, so this is an anecdotal result, not a controlled measurement.

The video below was recorded in October 2012, while the project was still underway. Cindy Powell (the primary user), Eric Garber (the product manager) and Lance Cranford (the lead engineer) describe how the team was working together. It is a mid-project testimonial, not a look back at a finished system.

What I learned

Bring users and engineers into the same room.

• One room changes what engineers prioritize. It is easy to deprioritize a usability issue you have never seen. It is harder when a user has just sketched the same frustration in front of you.
• A bounded format wins participation. People who would resist a long workshop will show up for an hour, and once they have contributed an idea that reaches the product they come back for the next one.
• Ask why it has to work that way. The biggest gain did not come from a clever technical solution. It came from watching someone do something tedious and asking why.