From Silos to Systems: How ITVX Turned Complexity into Cross-Functional Alignment

Marianne Ashton-Booth at UXDX EMEA. Video: https://youtu.be/qpkvfP2JgDw

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Design systems as organizational complexity

[00:00:10] Is that okay for me? Just a quick disclaimer: I have a habit of heavy breathing when I'm holding a microphone. So if this starts to get a little bit Darth Vader, could you on the front just let me know? Thank you.

[00:00:23] Right, so I hope everyone's having a fab time. It's been a great conference so far, and I'm here to talk a bit more about design systems, but not in the way that people usually expect. It's not going to be a talk about components or design tokens. It's about the complexity of systems within organizations, and about what happens when organizations scale, teams fragment, priorities compete, and alignment starts to become harder and harder to maintain.

[00:00:56] The reason that I wanted to talk about the complexity of systems in organizations is because the perception of a design system is that you have... I love Lucille Ball, so there's a few of these. You have perfectly structured libraries, clear governance, smooth collaboration and shared standards, and everybody and every team is aligned around one source of truth or one process.

[00:01:25] But we all know that the reality is quite different to that, especially in enterprise environments or large organizations where teams scale very quickly and, as mentioned before, the priorities shift. Environments where the platforms tend to rapidly evolve. And it's also where we find that resourcing and budgets change drastically over time. The reality of a design system, similar to those GIFs that I've just shown, is something that's quite close to the heart for me.

[00:01:59] I joined ITV just over three years ago. For those who don't know, which seems like it's the majority of the room, ITV is a broadcast service in the UK, and it's been making television since 1955. Before my time at ITV, they launched ITV Hub in 2015, and that was their first attempt at a streaming platform. It wasn't great. So in 2022, due to the shift in how people were watching television, we launched ITVX. That was a significant rebuild: a new brand, a new proposition, new ambitions.

[00:02:45] We're operating a streaming platform at scale. We're competing with the likes of the BBC, BBC iPlayer, which might not be something that everybody's familiar with, and we're also competing with the streaming big fish like Netflix and Disney Plus. So the expectations for the product were and are high, and the complexity behind it is enormous.

[00:03:10] We operate across multiple product work streams with competing metrics, multiple platforms, which equates to serving thousands of device types, and we work with centralized and distributed engineering across those platforms. However, importantly, and the elephant in the room, is that the core design system team is teeny tiny. It's very small compared to the scale of the teams around it. So naturally we've had to grapple with many challenges to date.

Silos as a natural byproduct of scale

[00:03:43] I'm curious to know if anybody else resonates with these. Those challenges are things like fragmented workflows, duplicated patterns, inconsistent adoption, competing priorities, governance tension and reduced resourcing. What's become very clear throughout all of that is that most of these things, in fact all of these things, weren't necessarily a design system problem. They were an organizational problem, or an operational problem in how we worked.

[00:04:17] So we had silos. It happens, and they suck. Often we talk about them as evidence of failure, and honestly, silos are often just a natural byproduct of scale. Because when we have different teams with different incentives, different timelines, different success metrics, different pressures, and when an organization grows large enough, misalignment can just become the default state. That means that alignment has to become an intentional practice.

[00:04:53] This premise is what we really needed when we thought about the longevity of our design system. We had to get the business, firstly, to stop thinking about the design system as a design library, or just a design thing, and start thinking about it more as an organizational operating system. Because if teams can't collaborate effectively, if priorities aren't aligned, if communication breaks down, the quality of the components and the system just becomes irrelevant.

[00:05:28] Most design systems move through very similar phases. Initially there's excitement. People adopt it quickly because the value is obvious. Then comes optimization, then expansion, and then eventually maintenance. Often I find that the main bulk of friction can start to appear between these two phases. Teams start creating workarounds, governance starts feeling restrictive, adoption becomes inconsistent, and priorities become quite political.

[00:06:03] This is usually where things become quite difficult generally to work, because you're no longer solving a design problem, you're solving an organizational problem. And that can become really, really tough, especially when teams start to expand or disband and there's a whole lot of change going on around you.

[00:06:24] Every year, Zeroheight release their design system report that looks at the state of design systems and the main things that are impacting them. In 2025 we could see that there were various things that were impacting design systems, but the lack of resourcing and staffing was top. And compared to this year, unsurprisingly, lack of resourcing and staffing is still the number one challenge. In fact, it's become an even bigger one now.

[00:06:55] Honestly, that probably reflects the wider industry climate at the moment. Across product and technology organizations, we're seeing increasing pressure around efficiency, delivery and short-term commercial priorities. Design system teams can become particularly vulnerable in these environments, not because they lack value, but because that impact is harder to measure as immediate commercial value. The irony, of course, is that the very systems that we work on, that are designed to create long-term consistency, are often the first thing that organizations deprioritize under short-term pressure. Which is partly why alignment and organizational buy-in matter so much.

Stafford Beer and the viable system model

[00:07:47] I'm a big fan of Stafford Beer. He was a big gun in the world of cybernetics, which means that he spent his entire career studying how organizations survive in complex environments. In 1985 he wrote that an organization is viable if it can survive in a particular sort of environment. For although its existence is separate, so that it can enjoy some kind of autonomy, it cannot survive in a vacuum.

[00:08:17] This quote has really stuck with me, because I find it so interesting how directly it applies to design systems. When we think about it, a design system might have its own team, its own governance, its roadmap, but it cannot survive in isolation. It has to stay connected to the organization around it: connected to the business, the teams, the technology, the changing pressures and priorities around it. Because the moment that a design system becomes disconnected from the organization it serves, it slowly stops feeling useful. And once that happens, that's when you'll start to see the alignment breaking down.

[00:09:06] One of the things that Stafford Beer created was the viable system model. It's a framework for creating organizations that can self-regulate, adapt and remain resilient in changing environments. It does look quite complex, and it was definitely not designed in Figma, but it breaks down into quite interesting pieces. It's a large system of effectively five interlinking mini systems, which sounds like a bit of a riddle.

[00:09:36] System one is what's classed as core operations, and this is about getting the actual work done: teams directly responsible for delivering outputs. System two handles coordination and communication: making sure that teams talk to each other effectively, preventing conflicts, and ensuring that everybody stays aligned. System three is about control and governance. This is essentially managing the here and now of internal operations: ensuring that resources are allocated efficiently. It monitors performance and it keeps everything running effectively.

[00:10:18] System four acts as the eyes and ears. It's looking out to the future, scanning the environment for trends, threats and opportunities, ensuring the organization adapts proactively to changing conditions. And finally, at the top, system five focuses on the big picture. It sets policy, and defines purpose, identity and overall direction.

[00:10:43] So can we apply the viable system model to design systems? Yes, we can. System one is essentially the foundational parts of the design system: components, tokens, guidelines, the core outputs that we deliver to teams across the business. System two, which wraps around everything, is our communication channels: the documentation, the office hours, the information that flows between systems and teams and people. System three is the governance: the rules, the contribution models. System four is the strategic future thinking: your roadmap, your research, your ability to evolve the system in response to where the business is going. System five is identity and purpose: stakeholder relationships and executive buy-in, the shared belief that this thing actually matters.

[00:11:35] What you can see with all these pieces is that when a design system is failing, it's almost never just system one. The components are usually fine. You might not think that they are, because they're the visible output, the part that everybody sees. But underneath that are all the invisible pieces that actually determine whether adoption succeeds: things like trust, communication, prioritization, relationships and shared belief. So the question becomes: how do we better support those invisible layers? How do we plan differently, learn differently, communicate differently? At ITVX, focusing on those five systems separately became really useful to us.

Treating the design system like a product

[00:12:23] One thing that really helped us was starting to treat the design system more like a product. Instead of only measuring usage or adoption, we started to gather data on the wider health of the system through three layers. The first was awareness and perception. Do people actually understand the value of the system? Do they trust it? Do they feel it's useful? Or is it slowly just getting a bad rap across all the teams?

[00:12:52] Second is usability and discoverability. Can people actually find what they need? Does the system support day-to-day workflows? Where is the friction showing up? And then thirdly, adoption and contribution. Who's using the system? Who's contributing back into it? And importantly, who isn't? Because those gaps often reveal organizational issues much earlier than component issues.

[00:13:20] By looking into these things, what changed for us was the quality of the conversations that we started to have. Decisions became less opinion-led and much more evidence-informed, based on the needs of the teams.

[00:13:36] One of the biggest shifts that we had to make was moving away from reactive fulfillment. Previously, the design systems team operated a little bit more like a service desk. A request would come in, a common component would get built, the cycle would repeat. Over time that became the expectation. But what we slowly realized was that that wasn't really helping the organization move forward in a meaningful way. We also didn't have the capacity to support that type of model. We were optimizing for individual requests rather than helping create long-term alignment around where the business was actually trying to go.

Tactical, strategic and normative planning

[00:14:17] So we had to start thinking about the now, the next and the future. One framework that I used that became useful for this was planet [?]. For this, we were separating our roadmap into three layers: tactical planning, strategic planning and normative planning. Let me explain a little bit more about what those themes entailed.

[00:14:38] Tactical planning became really important for us, because we realized that we had to get better at keeping things moving operationally. We'd become quite reactive. Requests kept coming in, and teams needed support quickly across all of the different work streams. For us, that wasn't really about governance. It was about responsiveness and reliability, and helping teams feel supported rather than blocked.

[00:15:06] One thing that we introduced in this area was something called expansion kit libraries. These were spaces for experimental components and early discovery work that our work streams maintained. We noticed that teams were often exploring or A/B-testing very similar ideas, but nobody knew. The work was hidden away in branches, isolated files or local experiments. This gave us a lightweight way to increase visibility, reduce duplicated effort, and create more connected thinking across teams. I think an important question to reflect on in your own organizations is: are your systems and processes genuinely helping teams move faster, or unintentionally slowing them down?

[00:15:59] Strategic planning became the point where we stopped thinking about delivery and started thinking much more seriously about direction and alignment. We began asking: where are we trying to go? What actually matters to the business right now? One of the biggest lessons for us was recognizing that design system work can't operate separately from organizational priorities. Because if the system isn't helping the business move towards its goals in the immediate term, eventually it will become very difficult to justify investment and support around it. So this layer became much more about balancing ambition with reality.

[00:16:42] A good example of this was when revenue priorities started shifting across the business. Rather than focusing on foundational UI work, we started prioritizing areas connected to things like payment flows, forms and conversion patterns, because they were becoming much more strategically important to the organization. So when we shifted into that revenue-focused roadmap stream, we were ready to go.

[00:17:10] And finally, there's a layer that I think people often underestimate the most, and that's normative planning, which is about belief in a shared purpose, the vision, and where you want to get to. Because long-term adoption rarely happens through governance alone. Excuse me. People don't constantly engage with systems just because they're told to. They engage with them when they trust the value they create and they feel connected to the direction behind them. This is where relationships become incredibly important: the conversations, the transparency, the collaboration across teams. Because ultimately this layer is about keeping the system aligned with where the organization is trying to go next.

[00:17:58] A good example of this right now for us is the growing shift towards AI-supported ways of working. Across leadership, there's a very prominent conversation at the moment about increasing pressures around speed, efficiency and delivery velocity. So rather than treating AI as a separate innovation conversation, we've started asking: well, what does that mean for the design system? How should our processes evolve? How do we support faster experimentation without reducing quality or consistency? So right now we're working across design, engineering and product, and with our Figma partners, to rethink parts of that process together, to make sure that the system evolves alongside the organization.

The why, the what and the how

[00:18:48] Silos happen when we lose alignment and connectivity. It really is essential to stay abreast of where the business is going and what's important to it now and next. A couple of years ago I created a framework that was an adaptation of the Lean UX framework. It was an attempt to simplify the complexity we were dealing with at the time. It focuses on three big questions: the why, the what and the how.

[00:19:15] The framework breaks these questions down into 11 areas. The middle section is aligned with the Lean UX canvas, and I basically sandwiched bits onto it. It's not particularly revolutionary, but that's kind of the point. The value wasn't in making something new. It was about creating a shared structure for better conversations and better decisions.

[00:19:41] The why section focuses on organizational understanding. What problems are we actually solving? What matters to the business right now? And where does the system actually fit within that? The what section focuses more on the users, the behaviors and the outcomes. Who are we deciding for, and what do they actually need? And how do we know if things are improving?

[00:20:05] And then the how is grounded in everything operational, because ambition without feasibility will just create so much frustration for everybody. How is the team structured? What are the risks? How can we realistically achieve this? In a world where we're under-resourced, thinking carefully about how you can share and distribute the work out, to maintain the system for the future, has been really beneficial for us.

[00:20:31] Eventually all of those pieces combine into a much clearer hypothesis. A large one that you would probably never verbalize in one go, but one that connects all the priorities, and something that you can then have in your back pocket when it comes to communicating the value of what you're doing. This framework is available in the Figma community files, so feel free to grab a copy if you'd like to. If you do use it, let me know how you get on.

Stakeholders and tailoring the story

[00:20:59] I mentioned having all that context in your back pocket, but alongside the planning, you need to understand the work that's involved in the relationships, because that's the final piece of the puzzle. Who do you need to convince? I found that this matters just as much as the frameworks and the libraries and all the smaller bits and pieces.

[00:21:22] You have different stakeholders that care about complexity, and they'll care about completely different things. They'll have different levels of influence as well, or knowledge of the system. Because somebody using the system every single day needs a very different response, or will have a very different relationship with it, than someone that's only reviewing it once a quarter, or just reviewing it on the output.

[00:21:49] So we started to map people. Because executives care about impact, product cares about delivery and outcomes, teams care about usability and speed. But design systems often communicate to everybody in exactly the same way. This changed how we communicated. We stopped talking only about components and consistency, and started speaking much more intentionally about impact, outcomes, delivery, scalability and trust, depending on who we were speaking to.

[00:22:24] Simon Sinek's golden circle is incredibly well known. His premise, start with the why, became really important to us at that time for communication. Because if people only understood what the system was but never why it mattered, long-term adoption became very, very difficult. So over time we started tailoring our communication differently depending on the audience. Primary users and teams closer to delivery often only needed clarity around process and output, whereas leadership conversations needed to focus much more on the why: the impact, the strategy, the organizational value. I think one of the biggest mistakes you can make is assuming that every audience needs the same story.

[00:23:13] A previous boss once gave me a really terrible analogy, which I'm going to share with you and probably massively regret later. It's very weird, but it's really stuck with me for a long time. I'd be curious if anybody understands it. She said: you don't need to tell them how the sausage is made, just give them the sausage. It's very weird. But because it's so weird, it's always stuck in my mind, and I think it's true. That level of communication, not having to tell everybody everything all the time, is something that's really important to remember. What's useful to the person receiving the information?

Key learnings

[00:23:53] So, to quickly wrap up, here are some key learnings. Design systems can shape behavior. If you can understand your organization and operations, then you can shape how teams collaborate, how decisions get made, and how priorities are aligned. Don't just focus on the visible layer, the components themselves, or you will miss the deeper organizational dynamics underneath. Because ultimately, the success of a system is rarely determined by the quality of the UI alone. It's determined by whether people can work together effectively.

[00:24:32] The second learning is that alignment isn't a milestone. How many people have heard a stakeholder say, isn't the design system finished now? Organizations don't stand still. Teams change, priorities shift, leadership changes, pressures change. So alignment isn't a one-time activity. It's continuous maintenance, and something that needs to be prioritized.

[00:24:57] Learn to speak the language of the business more clearly, because stakeholders don't really care about components and naming conventions. A huge part of the job is to translate the value of the system into a language that other people can understand.

[00:25:14] And finally, the most important lesson to me: the systems that survive are rarely the most rigid. They're the ones that are capable of adapting, because businesses evolve. If a system becomes too focused on protecting itself instead of supporting the organization around it, eventually it will create friction instead of reducing it. So relax with it. Don't sweat the small stuff. If a team stops using it, just lean in and understand why that's happening. Honestly, it's about those relationships, and understanding people is how you'll make movements to go forward.

[00:25:52] So I think ultimately the goal isn't to eliminate complexity, because complex organizations will always exist. The goal is to build a system and a process capable of adapting to complexity: systems that create clarity without rigidity, consistency without limitation, and alignment without silos. And that's me. Thank you for listening.

Q&A

[00:26:23] Host: Thank you very much. It's always a challenge. I love the framing of a design system as a product, because I think it's the exact same thing. You have to understand your users, do the research, promote it. So, brilliant. Okay, first question: is the Mosaic design system published to the Figma community to be checked out?

[00:26:47] Marianne: Unfortunately it's not, no. It's something that we're talking about at the moment, to see whether we can open source it, but not right now. But if you do want to find out more and you want to reach out to me on LinkedIn, I can give you some more information about it.

[00:27:02] Host: Excellent. So feel free to reach out. How do you respond to stakeholders who say, why do we need our own design system? Why don't we use MUI? There are lots of published ones out there.

[00:27:18] Marianne: This one's quite a challenging problem to solve, because again it's all down to communicating the value. Often those types of things are problematic long-term when you want to evolve. So thinking more about how you frame and build that narrative around the longer-term value, as opposed to using something that's readily available, and trying to weigh up those pros and cons, I think is something that really helps with those types of conversations. You'll feel like a broken record, but it's something that you just have to do: weigh up the value, communicate the value, but talk about it from a longer-term perspective, not just the here and now.

[00:28:03] Host: Yeah. We ran our US conference two weeks ago, and somebody was saying, isn't the problem with all these AI designs that they're so generic, and everybody is going to end up looking identical, with no differentiation? I think it's similar: if you pick an off-the-shelf design system, you're buying into them, and you're going to end up level with a lot of other designs.

[00:28:25] Marianne: Exactly, and that's really damaging for brand perception as well. So I think that part of it plays into it too. Thinking about the impact on the brand and where you want to evolve is really important.

[00:28:37] Host: Excellent. Not a question: "Such a pretty and smart presentation." So yeah, I'm glad I didn't have to show my slides after those fancy graphics and animations. Do designers from outside of the core team actively contribute to creating the design system, or are they just pulling from it?

[00:28:56] Marianne: Yes. As mentioned in the beginning, we're a very, very small team, so we just wouldn't be able to cope or survive if we didn't have active contributions from the other work streams. That's something that's really helped with adoption, actually, because they contribute to it, so the teams are more invested. We work with the teams and everybody contributes into it, and that's where expansion kits work nicely, because they create that buffer before anything goes back into the master libraries. So the long and short is yes, they do.

[00:29:31] Host: And then, touching on the highest problem being staffing, and reviewing: is that a challenge then, reviewing these buffers?

[00:29:40] Marianne: It is, and it's something that we've had to adapt quite a lot over the last three years that I've been at ITV: that contribution model, and things like reviewing and changing those responsibilities. We work in a very distributed model. We call them design system reps, and we have them in design and engineering. They tend to be the go-to people that have a little bit more prominence and involvement in things like final decisions and stuff like that. It just means that things can keep moving, rather than becoming a bit of a bottleneck.

[00:30:16] Host: Excellent. Design system reps, I haven't heard of that one. It's good. Will the slides be shared? For all of the sessions, if you go to the website afterwards, there'll be a watch now button about two or three days after, once we've sliced it, and if you click into the session there'll be a slides button. So all the slides that we can share will be there. Just give us a day or two to update the website. Okay. What do you do when something is not part of the design system but solves a pressing user issue in a feature?

[00:30:51] Marianne: When it comes to things like that and it becomes a conflict of priority, one of the things that we do that can sometimes help with things like that is leadership-level blueprinting sessions, with heads of and directors, where we'll look at the roadmap and we'll look at the end-to-end experience. We weigh up whether this pressing feature will impact another, and we call the shots then and there in the room. So getting everybody together to understand the implications, and then we can escalate up so that those decisions can be made, to press the green light and move that forward. For us, that type of thing is more about prioritization: when and how will it affect another part of the experience? Have we got any experiments that it will clash with? We have to weigh up those types of things.

[00:31:43] Host: And I guess with that it's like platform engineering. There's the trade-off: if you put too much in the platform, it slows down innovation, and you just have to try and find the best balance.

[00:31:53] Marianne: Exactly, yeah.

[00:31:56] Host: Are you adopting AI in the design system team, and if yes, how?

[00:32:01] Marianne: We are, yes. We're adopting AI across the board, widely within the business. I've recently set up what I call an ideation lab. We do vibe coding sessions and design jams where we look at how we can use the design system to vibe code things, to stress test things at the minute. It's very early days, but it's all stress testing, to see whether the design system will fit with these things. That's why we're working closely with Figma at the moment, to see how that looks long-term: how can we get this stuff that's just in solution ideation over into delivery? So we are, in different forms and different ways. If anybody wants to chat more about that, just feel free to grab me, or like I said, reach out and we can get geeky.

[00:32:55] Host: Excellent. That actually brings us to time, so thank you very much.

[00:32:59] Marianne: Thank you.