;

Y21 Nº014 GRID Mag – Managing 5 Product Teams

Featured Image

Dear (none)Designer,

Welcome back to the fourteenth Design at Scale™ Newsletter – focusing on innovation and how design drives change in a large organisation or an agency.

Today, we will focus on how Design at Scale helps manage multiple product teams with a single backlog and deliver the high-quality software that defines the Sky Q and Sky Glass.

While joining the Sky as an Experience Design professional, I have the great pleasure of serving 17 product owners. Each one of them has driven a specific feature that was a part of the ecosystem called SkyQ. As the majority of the UX professionals can imagine, all of my product owners asked me, "can you please do me a wireframe for this flow?" or "can you please do me a user journey for that?" or "can you please do me some research for this specific feature?".

In less than three weeks, it became obvious that serving 17 masters is quite impossible and time-consuming. What also became obvious was the monotony of repetition that has been replicated across different features. The majority of question lied in navigation and behavioural model, research and analysis and mapping a user journey.

I've therefore created a User journey model that can be easily adjusted and quickly exported to PDF at first. Fast forward three months, and I have found out that all my PDFs were shared with an engineering team that has been redrawing them in something called Lucidchart and then assigned to Jira. Over coffee, we discussed the time wasted and the amount of changes we prevented from being in live format, and decided to synchronise our approach to mapping.

Within less than two months, all diagrams and journeys were in a native format available to the entire team. More importantly, designers actually create and maintain them, which freed up our development time.

With the permission of a Group Design Director, I have requested permission to stop documenting in design files and start documenting in Confluence. All my questions for all product owners get centralised. Once, there was a simple difference from the previous engagement strategy. Instead of drafting and replying to 17 emails, I have written a couple of pages on Confluence that receive regular updates (Watch Page) and reduce email communication to a minimum. On the other hand, I began collecting feedback in the context of the feature, with an appropriate representative – the CPO. In many ways, all features share the same structure, including HLR, UAC, FR & NFR and NFR, as well as user journeys and wireframes. Joining them with real-life design from our UI team was pure magic.

While asking questions, I was also documenting these design decisions in one single place. Instead of sending hundreds of emails to different product owners, scrum masters or business analysts, I have always referred to the page that I created in Confluence. Soon enough, this became a standard way of working, where the majority of them referred to these pages in their product presentations. This eventually led to a focus on a single, knowledge-based core, which we referred to as the core.

Fundamentally, our small initiative has evolved from a 3-month exercise into a 12-month solid product design documentation, which we later developed into Sky OS. The foundation refers to all buttons, colours, primitives, sizes, spacing, as well as the definition of the component in React, HTML, and CSS code that has been driven across TV, desktop, tablet, mobile, and wearables. We all referred to it as a knowledge base.

This allowed our colleagues from sports, news, creative, and other departments and lines of business to tap in and tap out for the features they required for the specific event, whether we were designing for cricket, rugby, tennis, or Formula One broadcast. The components, such as maps, data visualisation, infographics, text blocks, and someone has been constantly available to simply plug and play, and get the advantage of a customised UI ina time sensitive proposition.

Time passes, and Sky OS has grown into a solid proposition that drives business decisions across the majority of even-based broadcasts, allowing program producers to customise the E2E interface by choosing from an extensive white-label library of components that drive the quality of journalism from Sky.

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Product Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to define teams of 01, 10, and 100, and 1% is supported by Grid Magazine and Supply section, where we bring more insights weekly on how to become a design leader in your Agentic Organisation

Jiri Mocicka

AVATAR

inResearch

21

inWriting

45

Released

260
EMT

Related.

Featured Image
Empathy as Infrastructure: The Internal User Experience of Scaled Systems The ultimate metric of any enterprise system is a deceptively simple question: Does it …
February 16, 2026
 · 
4 min read
Featured Image
Organisations trimming entry-level positions in pursuit of AI-driven efficiencies are engaging in a calculation that appears eminently rational when viewed through the lens of …
April 3, 2026
 · 
7 min read
Featured Image
Aligning Human Senses and Technical Communication to Unlock Enterprise Scale In a quickly evolving global corporate environment, cross-functional alignment is the ultimate metric of …
April 6, 2026
 · 
4 min read
Featured Image
Yes, let's begin. Where shall we start? The newsletter, articles, posts and many other forms of content are generated in order to scale your …
January 30, 2020
 · 
2 min read
Featured Image
Write the Press Release Before You Write a Line of Code Most teams write documentation to justify what they’ve already decided to build. Amazon’s …
February 15, 2023
 · 
5 min read
Featured Image
Build Down From Why, Or You’re Just Building Features Most product visions get written backwards: the feature list comes first, and a mission statement …
February 8, 2023
 · 
5 min read
Featured Image
Build the Fit Before You Build Anything Else A product doesn’t usually fail because the build was bad. It fails because nobody has proved …
January 11, 2023
 · 
5 min read
Featured Image
Make the Old New, Then Prove Which Idea Earns Its Build Most brainstorming sessions don't fail for lack of ideas. They fail because nobody …
February 1, 2023
 · 
5 min read
Featured Image
Make the Old New, Then Prove Which Idea Earns Its Build Most brainstorming sessions don't fail for lack of ideas. They fail because nobody …
January 25, 2023
 · 
5 min read

GRID Magazine

Explore OUR 
Articles

Every week we bring set of stories reflecting on communication, operation and technology.

Newsletter

Subscribe.

We share our 20 years of experience in creating, managing and scaling products and services that allow individuals to shape organisations through design.

Design at Scale™

LINE_MAGENTA_050_301

Categories

LINE_MAGENTA_050_301

Data

LINE_MAGENTA_050_301

Share

Internal

Collaborate

Resources

IBM PlexSan
Regular
Charcoal

Design at Scale™ is defined by three models, which form the Method. Each model operates in a different part of the business and collects and informs parties on design and engineering decisions that have a direct impact on the delivery.

All brands and trademarks presented on the Design at Scale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners. Do not copy or publish any of the projects shown here without written approval from Design at Scale™ (alternatively GIVE™, 9V™) and/or relevant companies and agencies.

SOC_Twitter
SON_LinkedIn
SON_Instagram
SOC_-Medium
View