3SS: Designing an EPG across seven platform types

An EPG naturally encourages density. Showing more channels and more time at once can make the schedule appear more informative.

That density becomes difficult on a phone. Program cards, navigation controls, and channel rows still need large enough touch targets to remain usable and accessible.

I reduced the number of visible channels on mobile rather than compressing the TV grid into a smaller screen. This gave each interactive element enough space and kept the schedule readable.

I did not create a denser mobile alternative because it would have required touch targets below the minimum size I was prepared to use. Users could browse additional channels through vertical scrolling. The design exposed less of the schedule at once, but each visible item remained readable and actionable.

Decision: Reduce visible schedule density on mobile. Rejected direction: Preserve TV-level density by shrinking program cards and touch targets. Reason: Smaller controls would weaken accessibility and make the grid harder to use. Tradeoff: Viewers saw fewer channels at once and needed to scroll more.

On touch devices, users can select any visible control directly. A TV interface works differently. One element must always hold focus, and every D-pad input needs a predictable result.

This changed how I treated primary actions. On TV, the action that receives focus when a page opens appears primary. Once the viewer moves elsewhere, the focus moves with them and the original action should no longer retain the same visual emphasis.

The interface therefore could not depend on a permanently styled primary button. Visual priority needed to follow the active focus state.

The EPG also required predictable directional movement: left and right moved through the schedule, up and down moved between channels, focus states made the selected program visible from viewing distance, selecting a currently available program could start playback, and selecting a past or future program opened its details without immediately playing it.

Decision: Make visual priority and action state respond to TV focus. Reason: Remote navigation changes which action is currently available to the viewer. Tradeoff: The design required more states and documentation than a static hierarchy.

The EPG needed to load a large amount of schedule data. Automatically loading and switching days as viewers reached the edge of the timeline would have created a smoother interaction, but it also increased the amount of data the product needed to manage.

My preferred direction was continuous scrolling with automatic transitions between days. Performance took priority.

We added explicit Previous Day and Next Day controls. When viewers reached the current day’s boundary, they could choose to load another day rather than causing the interface to fetch and manage the next schedule automatically.

The extra action made the transition less seamless, but it gave the system a clearer boundary for loading data.

Decision: Require viewers to select Previous Day or Next Day. Rejected direction: Automatically move between days through continuous schedule scrolling. Reason: The explicit controls reduced the performance cost of loading and managing large schedules. Tradeoff: Moving between days required an additional action and interrupted continuous browsing.

This decision taught me to treat performance as part of the user experience. A smoother interaction has little value if it creates slow loading or unstable behavior across lower-powered devices.

Program data does not arrive in uniform blocks.

Some broadcasts last only a few minutes. Others continue for hours. Some channels stop broadcasting overnight. Content can be unavailable, missing, or locked.

The timeline needed to work across those conditions without losing the program name or making the viewer’s position unclear.

Long broadcasts created a specific problem. A program card could extend beyond the visible timeline, causing its title to disappear as the viewer navigated through time. The design needed to preserve enough identifying information even when the full program block did not fit within the viewport.

The feature also needed to distinguish between different content states: a current program could begin playing when selected, a past or future program opened its details, locked content needed a distinct state, missing schedule content could not break the timeline, and channels without overnight broadcasts needed to remain understandable.

These edge cases became reusable additions to the internal design system after the first implementation.

Decision: Treat unusual schedule data and content states as core component behavior. Reason: The EPG had to remain understandable regardless of program length, availability, or access. Tradeoff: Supporting the full range of states increased the component system’s complexity.

I used existing foundations from the internal design system, then added new EPG components and states after the first implementation exposed the required edge cases.

I documented the components in Figma and Confluence, including their properties, variables, interaction states, and platform-specific behavior.

This documentation helped distinguish three layers: shared EPG concepts and components, platform-specific interaction behavior, and provider-specific branding and content.

The separation made later implementations more efficient. Teams could reuse the underlying logic without treating every provider as a copy of the first one.

The QA team tested the EPG across physical devices. I also conducted design QA on each platform.

Mobile and web builds were accessible from my laptop. TV platforms required a more deliberate workflow.

I installed builds directly on my television and used a capture card to bring the implemented interface back into Figma. I could then compare the build with the design, examine focus states and spacing, and document discrepancies for developers.

Set-top box and Android TV required the most attention because they relied on native components and platform-specific behavior.

This process helped me evaluate the experience under the conditions in which viewers would use it: on a physical television, with a remote, at living-room distance. Reviewing TV work only through desktop mockups would have missed important differences in focus visibility, scale, and navigation.