An example of UX heavy Product Design
.:TV Scrubbing:.
Definitions
Before jumping into the process and designs, I want to set the guidelines for what and how we talk about Scrubbing & Seeking. There was never any defined terms about this specific interaction and was an ongoing point of confusion among all the various team members across a variety of teams. So. I defined them!
Once I had scrubbing defined I also defined seeking to make sure that there was absolutely no confusing the two. If a user was scrubbing, they weren’t seeking and vice versa.
The Problem
Looking at our current scrubbing/seeking behavior we found that depending on the code base (webOS, Lightning, Roku, tvOS) users were having inconstant experiences when it came to traversing through an assets timeline using either the mechanical D-Pad or dedicated FF and RW buttons.
Furthermore, none of our devices had a long press action to initiate scrubbing and instead prioritized a traditional FF and RW seeking behavior. This was likely a result of early development and as TV hardware evolves, a distinction is needed between traditional seeking, with dedicated buttons, and scrubbing. This was observed in our audits as well with 6 out of 7 of our competitors prioritizing scrubbing on the mechanical D-Pad.
This was setting an expectation from users broadly, and gave us enough data to feel this update was a table stake.
Finally it should be noted that Paramount and MAX, who can be seen as our main competitors, were prioritizing scrubbing but also had inconstancies and were devoid of any interactions or PVR window for linear assets. These distinctions gave us the opportunity to upgrade the brand and user experience.
Strategy
Our devs are already burdened with a ton of PTDs so it was crucial to develop a strategy that prioritized any designs that we were sending to the tech teams - we also needed to get buy in from both product and design leadership. After many working sessions and input from team members my PM and I landed on a three phase approach:
Phase 1, the MVP, sought to flatten the mechanical D-Pad experience while continue to push for native tvOS interactions.
Phase 2, the more complicated interaction, sought to introduce and A/B test progressive scrubbing speeds & static speeds (peacock has assets that range from 15 seconds to upwards of 8 hours!) along with further tvOS gesture refinements
Phase 3, the moonshot. I knew some of my colleagues were working on chaptering and were running into issues with that feature fitting in our current player UI, so phase 3 sought to refresh our thumbnail preview window and introduce a cascading interaction that would free the team up to pursue other avenues of VOD and SLE chaptering.
Getting Buy In
At Peacock, for an update of this size there are three stages of buy in. The design team works internally to align with design leadership, then heads to a workshop with product to get alignment with product leadership and finally a presentation with the CPO for final green light. This process can take several iterations where by the team is picking apart the design at every angle. I look think through all the use cases, test each remote, understand each asset type and iterate.
The Solution
After a few rounds, we get buy in from product and design. From here, my PM and I schedule a workstream call to walk through the user flows and purposed updates with the engineers to confirm feasibility, identify constraints and get overall consensus for all teams involved.
…always include the LG magic wand :P
One of the major challenges with this design was determining the speed for which users will travel. The MVP design needs to be a static speed that feels good and gives control that avoids any hesitation when a user wants to scrub to the end of an asset, which could be very long, and also gives users enough granularity to find a specific moment in time. For this, I do a ton of research and competitive auditing and work directly with the UX Engineering team to create a functional prototype that we can easily tune and test with.
With the prototype working, I run usability study dialing in the right speed. Even the CPO gets his hands on experience to understand how this new interaction was going to feel to our millions of users.
Here is the resulting static scrub speed design complete with video examples, links to the prototype and a github repo!
One part of this process I am exceptionally proud of is the phase 2 design for progressive scrub speeds. Though it wasn’t needed for initial delivery, the tech teams expressed concern that it was missing so I went to work deducing a way forward.
To find the math of our competitors, I recorded myself scrubbing from beginning to end in slo-mo and counted the change in ticks as the speed ramped up. Netflix at the time was statically scrubbing at 10 seconds every 350ms, so no ramping there. But Hulu and Disney has some very interesting and tricky bits of math!
Disney was using sections of time ramps, essentially doubling the tick time scrubbed depending on how long the user held the long press. This results in a somewhat jerky feel and caps the top speed at ticks of 1m11s @ 350ms.
Hulu however has what we all agree is a far superior speed ramp by which they compound ticks by adding 2s every 350ms of real time. This results in a subtle exponential curve and feeling of gradual forward motion that gives users freedom to scrub short distances and long distances based on the implied context of the user input (a shorter long press implies a user is looking for a certain spot in the asset while a longer long press implies the user is trying to reach the end faster).
Me and the UXE Matt go hard on this, we both love this kind of stuff and get real into the weeds with how this could work :P
We add our math into the prototype
The final design for phase 2 is ready for A/B testing, the devs are thrilled and we setup for the phase 2.
I always make sure to collect all my links and work and keep my team informed and collaborative throughout
Focusing again on the main MVP delivery, I make sure to outline any changes to UI from provided clear research documentation
The final piece is a simpler one. AppleTV uses its own native behavior and the team agrees that leaning into tvOS’s native options will lighten the load on devs and comport with user expectation on those devices. I audit and log any bugs or strange interactions and update the seek speeds to match the current native standards.
After a work stream meeting and direct communication with our backend teams - in no time at all, we have our build in proton for tvOS.
Phase 3, the moonshot, doesn’t need to be fleshed out presently but with design and product already aligned, we are ready to jump in whenever we are ready to update the platform!
I am incredibly proud of the work I got to do on this project and cannot wait to see it in action later this year. This particular project gave me the opportunity to get really hands on with engineers and product and allowing me to dive deep into the UX, keeping our users in mind every step of the way!