Translating Chaos: How I Bridge Ambiguity and Bureaucracy

Now I know it's all it's lunchtime. Everyone's tired. We're gonna hang in there. One last talk before we get a break. Thank you all so much for being here today. I usually work out of a linen cupboard in my house in the Southwest Of Western Australia, so it's an extra special treat for me to be like IRL with so many actual human beings that I can see their entire bodies.

This is pretty new for me since COVID. This is exciting. I'm a strategic designer. I work primarily with public service. And in the last few years, I worked primarily with government, and right at that federal level. So I wanna start with a story, and I wanna bring you all along the story.

Now I'm not sure what kind of designers we've got in the room today. My guess is we've got a bit of a mix, but I think everyone here understands the value of design when it looks at reforming some of our public systems. So let's start with a hypothetical situation where we've all just been hired into a federal system.

Now, we've got the brief. It's pretty vague. They know they wanna change stuff. They're not quite sure what. They know there's issues they don't necessarily want to admit to them, and they know they wanna make change happen, but they might not quite have the authority required to do so.

That's alright. We're strategic designers. We're pretty used to this. We understand this challenge. When we get in the room with our public servant counterparts, it's looking good. They're excited to have design in the room. They know enough about human centered design that they're really excited that someone gave them the budget to do this project.

We're gonna help them solve all their problems. We're gonna help them do research, and we're trying to temper their expectations around design and its ability to be a magic bullet, but we're also trying to keep that excitement going with us. They eventually give us access to data after we sign a lot of paperwork, and we wait many weeks for that authority to take place. We get access to really good people.

We're looking at internal systems here, so we get access to the teams that use the systems, we get access to the policymakers, and then we get a bit of access to even some of their data where they've done customer research at the other end of actual service users. This is pretty good. So we run workshops, and we run interviews, and together, we're talking, and we're working alongside our public service team.

Throughout research, the insights become alarmingly clear very quickly. The system is built for compliance, not for care. The system expects a lot of its people, but it is not wired with the kind of evaluative thinking required to actually track or measure outcomes, not within the system and not outside of the system.

In fact, the people who own the data of the outcomes outside the system are not the system itself. The system doesn't even have access to that data, so they don't have any idea about the impact that they're making, and how it's filtering down. It's alright. A little stressful, it's alright. We've done this before. So we work really closely with our public service team.

We help them to see the challenges, and we help to shape insights that bring a lot of value to this work. We work through a set of methodologies. We build metrics. We build systems. We build frameworks, and together, we envision the future. We build them a super sexy future state map. This is where you could be.

The project's coming to an end. It's time for our public service showcase. We get the leaders in the room. We make sure it's at a time everyone's there. We try and make sure nobody's emailing at the same time, and we we try and get a bit of energy in the space. And we show them the insights, and we show them the current state map, and we show them the templates, and we show them the future state map, and we're gonna do this every time.

They love it. They're so excited. You hear from the back of the room, it's so validating to see my pain like this. The leaders say, I actually think we could make this work. We could actually do this. How good would it be if our system looked like this? The energy's awesome. You feel really, really comfortable.

We did a great job. Good job, team. We did a great job. But the project's over. And there is no room in that contract to support the public service team in implementation. So if there's talks, of course, I'm here supporting you guys, talking to the leader of the public service team saying, hey.

It would be really good if they had some support for implementation. You'll get a lot further here. But over time, nothing. Now it's not nothing because the work wasn't good. The work was great. But it's nothing because the leader, she moved to a different team.

They renamed the branch. They have a new focus now, and you feel the sting. Has anyone in this room felt that pain of a design project before? Yeah. Oh, it's my people. Me too. Now this thing in your projects are not necessary.

I'll give you all the benefit of the doubt. The work was great. The insights were real. The public service team were just as into it as they seemed. But systems are tricky, and they are bigger and more complicated than us. And sometimes, even really good work doesn't land.

So I work with a lot of design teams, never as big as you guys, but a lot of design teams. And I work with a lot of public service teams. And I spend a lot of time bringing those two groups together. And when it doesn't work, I hear two things. Firstly, from the system, I hear design didn't really understand what it was that we have to work with.

Design doesn't understand our constraints. They don't understand this machine. They didn't get leadership on board. We've got no funding. Fair. Sorry. I have a sip of water. Now from design from design, I hear, the system is the problem. The system is slow.

The system is calling out for innovation, but it is unwilling and unable to move in response to it. Also fair. I understand the duality here, but what it is is not helpful. We don't have a systems problem. Though, yes, systems are not perfect.

We don't have a design problem either, though design is still flawed too. What we have is a translation problem. Design and public systems may use a lot of the same words, but they speak a completely different language.

Now I've never been a career public servant, but I do happen to be married to one. And I can tell you, whilst our goals are often the same, our instincts are extraordinarily different. As a designer, I'm comfortable in ambiguity. I'm looking for patterns. I can see between the lines. I can see how we can improve, and I can envision the positive future. Our public service counterparts are wired differently.

They are wired for compliance. They are wired for accountability. Their job is to deliver within constraints. And they do all of this under immense pressure from politics and public scrutiny. It's hard work. So what we have here is a gap.

One large gap. When design says empathy, public service hears risk of media fallout. When design says opportunity, public service hears legislation changes. When design says future vision outcomes, public service says, yeah, absolutely.

Us too. But by when, By who? And in which financial cycle are we getting this done? This gap is actually not a problem. In design, we often look at this binary, and we think, if only the system was more like us. But the system plays a really important role.

And as designers, our job is to translate. We are perfectly positioned to be translators here. We are agile. We're ethnographic. We can hear the words the system says. We can bend in a way that our public service counterparts cannot. So let's look at a a highly oversimplified version of the designer and the public servant.

So when I say designer as translator, what I mean is a designer who is able to work between two logics, the logic of design and the logic of public systems, and is able to carry across that gap ideas, problems, challenges, futures, back and forward without losing its meaning. It's not about oversimplifying, though there is part of that in design.

Translation is actually about accuracy. How do we translate the ideas of design and the needs of public service, so these two different ideologies are able to talk to each other? So now I'll show you the oversimplification. The anatomy of a designer. Now many of you in this room will feel this way.

We are led by a brain that is led on creativity. It's run on pattern recognition, and it lives for human experience. We work with a heart that is empathetic, curious, and looking for opportunity, looking to flip a challenge into an opportunity space.

And we work with two hands that are very good at learning through doing, testing, and iterating. We're not afraid to get our hands dirty, but there isn't a lot of risk for us in that case. Our public service counterpart, however, is a little different. Their brains are wired for logic, for risk, and for accountability.

They have to be. In their heart, it's duty, equity, and public interest. These are not bad things. They're good things. And their hands, they learn through process, approvals, and governance. So let's compare them side by side.

The design logic tells us to expand the frame, whereas public servants are tasked with narrowing it. The designer is rewarded for exploring. The public servant is accountable to delivery. The designer is tasked with reading between the lines where its public servant counterpart, their job is to align to policy.

It's really important to note these are not personality traits. They're not personas. They're not archetypes. They're structural defaults. They're a kind of cultural conditioning that is given to us because of the work that we do, the constraints that we live with, and the structures in which we exist. These are also not binaries.

They are not in opposition to each other. And if we learn to translate well, they can actually be very complementary. Now, the show of hands I saw before makes me think that some of you have worked in these systems before, and I can hear you say it. Isn't it the system that's the problem? I get it. Systems are frustrating.

They are frustrating for designers. They are equally frustrating for public servants. They are frustrating for everyone. Systems are slow. They are hierarchical. They are risk averse. They don't share information. They're built on silos. I have worked with teams who work across the hallway from each other and have never spoken to each other before about work.

It's wild. However, you'll hear a lot of rhetoric in design, especially around public system design, that the system is broken. Systems aren't broken. Our society actually functions pretty well compared to lots of parts of the world. The system themselves aren't broken.

Outdated perhaps, but not broken. Systems are built on a foundation of legacy design choices that, yeah, are no longer fit for purpose. However, when we try to change them, they push back. Systems are bigger than you or I.

They are also bigger than their director. They're bigger than their CEO. They're bigger than everyone in that hierarchy. The reality is within a system, we are all completely replaceable. The system will continue moving along that train track with or without us. So how do we shift it? One small translation step at a time.

Throughout my years of working between design and public systems, I have realised that translating design within a public system framework does not happen by accident. It happens through habit, and careful conscious decision around the way that we talk about design, and the way that we communicate what design has to offer, and the way that we hear the constraints of the system.

And there are these key opportunities that I've discovered to help us to translate design for impact. The first is when we pitch design. The second is at our kickoff. The third is around our problem framing. The fourth is across the whole project, when we're making choices about the kinds of language that we use.

And the fifth is really important. It's what we do as design when things go wrong. In a perfect world, it would be a smooth ship, but anyone who has ever worked with public service, or really any design project, things go wrong, they're supposed to. That's how we learn, that's how we get better. But what we do in that moment really matters.

So let's look at the first one. Let's look at the pitch. At the pitch. So our first job in translation happens before the work is won. It happens in our pitch. It happens in our first conversation with our client. It happens when we first get that RFQ in our hand, and we're deciding how we respond to it.

Clarity in what design has to offer is our first act of translation. It is so important that we communicate what design can and cannot do. Focus on what design has to offer, and not what it might build. So I'm a consultant. I work for myself, and I'm brought in to lead design teams in public systems pretty regularly.

Which means I end up in the room with a project that has already been won. I am working on a proposal that has been written without me, so I get to see with baby fresh eyes proposals all the time that I think, what were we thinking when we promised we could do that? When we focus on what design has to will build, the artifacts of design, we limit the scope for exploration.

A lot of design proposals promise design is a magic bullet to public systems. This is problematic for a lot of reasons, but it's really problematic when we're trying to get design and public systems to speak the same language. A lot of the things we promise public systems are ambitious at best, and in reality, probably too big for the complexity that we're actually dealing with. Our job is to move the needle, not transform the system. One small change after another over time will lead to that translation.

So pitch what design truly has to offer. And be careful, because quite often in a proposal, you don't know what the problem is yet. And so if you've defined what those outputs are going to be, you are boxing your designers in going forward, and you might be limiting the actual impact of the project itself. The second is at the kickoff.

Now we all do kickoff meetings of some kind or another. I run all of mine digitally because I live in the middle of nowhere. And I've seen it time and time again. We get really excited about our process, and we present to our client team, this is the process of design. We're gonna do this discovery, and then see how the diamond comes in. Then we're gonna define stuff, and see how it goes out again. Now we're gonna explore more.

Public systems love it. Right? They're so excited. They're like, yeah. This is so different to how we usually work. And that difference is the problem. That difference is this really big gap. And in that gap, there is all this space for misunderstanding, miscommunication, misaligned expectations. Because whilst they love the idea of the process, it's actually not how they work.

So they're still looking for particular stage gates. They're looking for particular outcomes. They're looking for that thing you promised in the proposal that you'll do. Where is it? Because it's all attached to public money. So at kickoff, instead of leading with the process, I suggest you lead with a set of questions. Understanding the context that your project needs to work in is much more important than them understanding the process that you will use.

The process of design is not what we do. It's how we do it. What's more important at kickoff is understanding what does success look like here? What kind of outputs are tied to the funding of this project? What are nonnegotiable deliverables? Where is there flexibility to move?

Is your leadership on board? It's a really good question. Answer's not always yes. Understanding the risks that a system has when you're working within it is crucial. Because then what we can do is we can design our process to the rhythm of the system.

We can design it with a good understanding of what the pressures and the requirements are, and we can avoid a lot of stress and heartache in that client design relationship down the road. The third get all the way back here. Should probably just put that clicker down. Is in discovery. So this is around framing the problem. In design, we talk about problem framing all the time.

Right? This is a thing that we're all pretty good at. The problem is in public systems, when you work in the project, when you get there, the problem has already been framed. It's right there in the RFQ. They've already decided what the problem is, and now they have hired you to do the project based on the problem, and that problem was sometimes written by a procurement team who's 10 steps away from the problem itself. The problem often doesn't reflect what's actually happening within the system. This quote from the UK Policy Lab from one of their most recent reports is fabulous.

There is no greater waste of public money than to have the best solution to the wrong problem. We can build really beautiful artifacts. We can build great sets of insights. But if they are responding to a problem that doesn't really exist or a problem that isn't what we're really working with, we're gonna end up with those crickets from before, that tumbleweed, because they're not gonna be able to implement it.

So it's really important that during discovery, when we are writing research questions and we are working with our public service team, we look at that RFQ, and we ask, who framed this problem? Whose voice is missing? And what is at risk if we solve the wrong thing?

That'll help us to get closer to the problem. And then we can run discovery just the same way as we always would. In delivery. So all the way across a project, we're making language choices. Right? We are choosing how we talk about design, and we are choosing how the sis how we talk about the system, and we are choosing how we bridge the gap between the two.

Now public system language can be really confusing. The amount of times I've walked into a new project and thought, oh my god. I have no idea what anybody is talking about. I didn't even know date data for freight was a thing. Okay. You've gotta learn the language. You've gotta understand what they're talking about, and you've got to lose the design jargon that we all kind of lean on as a crutch. It makes us kind of sexy and exciting.

We've got these cool things. We're gonna build this cool map. We can still do the really important work of design, but translation only works if we really become part of the system. Keeping a gap between what design does and what the system does creates a big problem. When our designers are part of the public system team, we get to experience their challenges, we get to experience their pain, we get to experience their siloed ways of working.

We're in a much better position to be able to translate and use the right language across that gap. Andre's an amazing designer. He's a Dutch designer. He writes an incredible book that's called Designing With in Public Organizations. It's very, very good. He does many, many chapters on this, around how you can't create change in a system until you become part of it.

We need to reduce that gap between design and public systems so that we're speaking the same language. Now, the fourth and final one is when things go wrong. So things go wrong in design all the time. It's important to pivot with purpose. And this is kind of a callback to the first one around how we pitch design.

Leave space for pivoting and moving. Because if we're already designed what it is we're gonna deliver, and we don't understand the problem yet, we're gonna come up with a problem. And so good translation requires strong relationships. Always pivot towards impact and meaning, not towards the shiny output. Not very long ago, I was working in a big project in federal government with a strategic design capability.

So they have strategic design teams within some of these branches. They wanted me to come in to redesign their operating model. Fine. They wanted me to turn them into a center of excellence that would be the guiding shining beacon of light of strategic design throughout their particular arm of the government.

Look, on paper, super sexy, super exciting. That sounds fun. In reality, in discovery, I realized there was a lot of smoke and mirrors. The team wasn't perhaps doing strategic design the way they needed to. The team wasn't ready to be a center of excellence. The team didn't have an autonomous arm.

The team wasn't getting hired by other branches for these services. They wanted us to build a design front door, but we couldn't, because there's a very good chance that door would never have been opened. So instead, halfway through the project, I had to have some pretty tough conversations with the client team around potentially their view of themselves and what they were capable of right now were two different things. And we could design them the output that they wanted, and they might never get to use it.

Or we could design them the kind of team structure, and frameworks, and operating model, and principles, and mindsets, and ways of working, and and everything, cadence, the whole lot, that would allow them over time to learn the skills required to be able to scale and to work towards that end goal. It was a much smaller win.

It probably looked a lot worse on their annual report, to be fair. However, that team today is still using that operating model. They're using that framework. They are building on top of it, and they are becoming stronger and more capable and more valuable to the system that they're designed to serve. Small wins on paper are huge wins in practice, and our job as design is to translate the difference and to lead the way.

So maybe the anatomy of a designer in a public system maybe looks a little more like this. A brain that is wired for creative possibilities, that are grounded in the reality of what the system can and cannot do. A heart that is empathy matched with duty and responsibility, and hands that structure the path, not just the final destination.

So I wanna bring you back to that sting we talked about earlier, that failed project, that project that sat on a shelf. I want you to reframe it. We're good at that in design too. Let's reframe it. Maybe it's not a failure. Maybe it's a very clear sign that there was a gap. And that's a great opportunity, because as designers, we are perfectly positioned to build a bridge over that gap.

Because our real value in design isn't in our methods or our workshops. It isn't in the outputs that we deliver, though those are great, and we should definitely keep doing them. But it's actually in our ability to translate, to help a system take another step forward, not by being above it, but by being alongside it. It's not about bureaucracy versus design or design versus bureaucracy.

It's actually about how we can bring them closer together so that we're all part of the same unit working for the same purpose. Mike Montero, who I saw present at this conference about ten years ago, says the role of the designer isn't to make things pretty. Our job is to make things work ethically and responsibly.

And in public systems, that's to translate, to get everyone speaking the same language, and that is how we're able to translate. Chaos? Thank you.