
Streamotion Design System
Project completed
In house, Streamotion/Foxtel Group.
Role
Design, Design Direction.
THE PROBLEM
Each streamotion product built upon the foundations of its predecessor, incorporating improvements as timelines permitted. However, this approach consistently inherited existing issues and faced documentation challenges.
Designer turnover brought constantly shifting approaches to documentation and design system application. This resulted in the absence of a reliable source of truth for our design team. Meanwhile, development maintained their own separate documentation with entirely different terminology.
Streamotion’s relentless pace never allowed for reflection. We would launch a product and begin a new one just six weeks later, never creating space to take stock, consolidate our learnings, or redefine our system properly.
WHERE IT STARTED
When I joined, we had a disjointed documentation system consisting of a font matrix, a spreadsheet of atoms, molecules, and organisms that listed component names and references without indicating whether they were in use, and a series of ‘component boards’ documenting states, styling, and interaction principles. Unfortunately, these boards lacked consistent rules, structure, or styling.
Only the spreadsheet of atoms, molecules, and organisms was product agnostic. Everything else existed as separate documentation for each product.

During the Binge project, it became evident that development had progressed too far (and the timeline was too aggressive) to properly address the design system. I redirected our team’s efforts toward reducing ambiguity and merging our documentation with terminology development was already creating.
This consisted of:
Ensuring accurate naming of components in design files;
Removing and updating any text styling that wasn’t documented in the font matrix;
Advocating strongly for consistency in design rules and component reuse across features.
Challenges I faced included:
Stakeholders insisting on bespoke components rather than accepting minor design compromises;
Basic components like buttons changing so frequently that maintaining consistent design files became impossible;
Developers bypassing new documentation and defaulting to Kayo components despite their incorrect implementation or poor fit for purpose.
‘UNIFICATION’
Soon after Binge launched and moved into business-as-usual operations, we began conceptual work for Flash, our news streaming product. This time, things unfolded differently. During early technical consultations, I discovered a push for a unified approach to front-end development. The team wanted a single code base to apply across all products, treating branding as merely a ‘theme.’ This approach meant our products could finally share features and receive updates faster, but internally it required a massive shift in thinking.
One of my major stakeholders fundamentally disagreed with this approach, but we decided to forge ahead with it - more as a cost-saving measure than as best practice.
I began by negotiating with the front-end team for a specific set of elements that could be ‘customised’ per brand. I created rapid documentation demonstrating how these elements could be switched between products while maintaining the unified codebase. The customisable elements included:
Fonts;
Colours;
Borders;
Rounded corners.

I decided we needed to change our current approach to design. With ‘unification’ there was no way we could maintain changes to 3 products with the headcount we had.
My challenge was significant: we were now expected to be across Kayo Sports, Binge and Flash. My manager wouldn’t allow us to move away from Sketch for design or Zeplin for delivery. Due to previous issues with library usage, she was resistant to us using library files. Adding to our constraints, the office wifi couldn’t handle Sketch Cloud effectively (a post-COVID reality of reduced office space and fewer amenities).
This time, we embraced symbols much more extensively (unlike Binge, which barely used barely any). We built symbols with global use in mind, tightened our naming conventions, created tidier and visually consistent files, and output component boards with consistent formatting—though they weren’t quite as robust as I had hoped.

OPERATIONAL EFFECIENCY
2021 came around and parts of our front-end teams implemented unification, but we were still working with both systems. Our resources were more stretched than before when we learned we needed to cater for yet another new product. An aggregated streaming service was coming, and the top-down message was that we needed to deliver a larger product with more platforms (at the time, the project scope included existing Foxtel device support plus the new Comcast devices). Our team was directed to apply a ‘templated’ approach to design. We would no longer re-document existing functionality as in previous years, focusing only on new features and platforms, with fewer breakpoints being produced.
However, we still needed to spin up mocks when required, make design decisions for breakpoints we weren’t addressing, and advise developers how to build those breakpoints without actually ‘delivering the work’.
Still prohibited from moving to Figma, in 2022 I pivoted our approach in Sketch from file-based symbols to external libraries. I divided these libraries into two categories: global elements and branded elements.
Buttons and icons remained as branded elements, while carousels, tiles, navigation, and content all became global elements. Colours were managed and applied with variables.
The vision was to create libraries that could scale across all brands, as the move toward aggregation on all platforms finally forced front-end teams to fully embrace unification and rebuild their codebases. At last, we would have a single source of truth.
THE ‘BREAK UP’
During my maternity leave in 2023, significant changes occurred. The aggregation product, now officially branded as ‘Hubbl’, underwent scope reduction, while the design team split into separate Hubbl and OTT divisions. The design system I had spent years advocating for and incrementally improving came to a standstill. With the long-anticipated unification no longer moving forward, the library files didn’t progress according to my plans. Instead, focus shifted to maintaining our legacy system alongside Comcast’s aggregation platform.
When I returned in 2024, I was disappointed to find the design team had essentially regressed to where we were when I first joined. We faced all the familiar problems: inconsistent use of symbols and libraries, conflicting sources of truth, and a substantial amount of cleanup work ahead of us.
As soon as I returned the majority of my team were unfortunately made redundant. My focus shifted to upskilling a junior designer and re-assessing what scope we had with reduced resources.
2025
This year, between initiatives, I’ve been proactively building out a slimmed-down design system for Hubbl.
Despite our limited resources, we’re making several meaningful improvements with our recent transition to Figma:
Figma Libraries with tokens, components, and patterns
Colour Styles with consistent opacity standards
Variable modes enabling smoother transitions between UX and UI
Design documentation with practical examples (clear do’s and don’ts)
Status tracking system showing which elements are in exploration versus approved
Consistent UX styling with improved visual hierarchy
Utilising ‘Ready for Dev’ functionality to fully replace Zeplin