Hello.

How has the product design obsession with frameworks and process led to everyone

working on autopilot, churning out bland monoculture of design?

When are they useful and when do they simply become a crutch?

Have we hit peak framework? Welcome to Power of Ten,

a show about design operating at many levels of zoom from thoughtful detail

through to transformation in organizations, society and the world.

My name's Andy Polaine. I'm a design leadership coach,

service design and innovation consultant, educator and writer.

My guest is Jaimes Nel, founder of path,

a consultancy that helps transformation organizations play the long game through

design edge strategy.

James was head of insight for pioneering service design agency live work in the

early years of service design practice, which is where we met.

He worked on service transformation for brands such as the N-H-S-B-B-C,

Aviva Johnson and Johnson, eBay gov uk. Hm RC,

that's the customs people and revenue tax office, right?

And LED transformation design team at Westpac in Australia where he joins us now

delivering their digital mortgage services. James, welcome to Pav 10.

Hi Andy. Thank you.

So first of all, tell us, I've got a little bit of a bio there,

but tell us a little bit about your background and work before we get onto the

framework question.

So I'm what I guess I call a design-led strategist.

My background is in research,

I'm a sociologist, that's what I studied,

and I got involved in early days of service design

from the research side.

And over time my practice grew to incorporate

more strategy. So as I added more design in, I guess I've become more

what I would call a strategist or describe myself as a strategist.

And I describe what I do as design led strategy rather than

necessarily design strategy because it incorporates a lot of different elements

of a strategic practice,

but always bringing some of the elements of design that

I think are a powerful ways of

working and thinking that you don't necessarily get with a very kind of analytic

approach.

And so when you say it's design led,

what is particularly designerly about,

I guess about it when you say those things add a different edge

to a normal strategy practice?

Yeah, I mean it's interesting.

We're probably getting quite quickly into what we've been

talking about speaking about today because I think what design adds

is the ability to make leaps,

to synthesize things and make jumps that don't necessarily follow a linear path,

that don't necessarily go A to B or one plus two equals

three.

Design is quite powerful at allowing you to bring things together and find

patterns or synthesize things in a way which can be

quite unique or different.

And also to work quite quickly at synthesizing patterns,

I think design's got something to offer

massively in terms of bringing things together in a slightly different way

around a problem that you don't necessarily get when you're following something

in a purely analytic framework.

We are indeed getting close to what we're going to talk about.

I guess there's one of these things, there's a phrase,

I think I've heard it from Steven Johnson,

but I'm pretty sure I've heard it from,

I think it might have come from somewhere else of the idea of an intermediate

impossible or impossible intermediate outcome or what it's,

but this idea of when thinking through say something like a strategy or thinking

through how you might tackle a problem or the beginnings of a solution,

there's a bit in the middle that you are not really very sure about.

We don't even know if it's going to work.

But the idea of this intermediate impossible is that we assume,

let's assume that's going to work.

Let's assume we can solve that and then jump ahead and also work on the thinking

after that and then move back.

Is that the kind of thing you're talking about with that non-linear path as

well?

Yeah, I think we've developed

a kind of comfort with that level of ambiguity in design

and caveat all of this.

There's crossover everywhere everything we're talking about.

And so when I talk about the role

or the extra thing that design adds,

it's a little bit of freedom to play with these boots kind of strict boundaries

that I think unlocks a whole lot of possibilities that you lose when you're

trying to follow very,

very strictly from one step to the other. And in a way I,

I guess the risk that we're kind of talking about here by becoming very,

very process focused,

design tends to mitigate that

what can be its superpower.

Yeah. And so what are you seeing going on?

I think this conversation about frameworks started in the

comments about something like that I think.

And talking about frameworks, I was complaining,

I think about this idea that I see frameworks as

they're very useful. I mean I teach them,

so I'm an educator and I train people in service design and other things

and obviously and teach at university. And so I'm teaching frameworks.

I'm well aware that I do that and particularly around research,

I talk about it and synthesis, they're very useful,

but we may need to go as they say in sound of music

back to the very beginning of what we mean by a framework actually.

And before we get onto the sort of crutch aspect of it,

but the thing I was complaining about in the comments was this idea that I think

I see everyone from students, the people working commercially, professionally,

sometimes use frameworks

without the depth or critical thought behind those frameworks I guess.

And they can become a crutch. And I think when we work at speed,

which is obviously there's this kind of massive pressure,

always we end up just skimming those things and using those things without

much thought. Let's go back to the beginning.

You also wrote a piece about this, but I want to just define our terms.

What is the framework in your book?

I was thinking about it a little bit actually.

Actually I'm quite glad that I came up with a bit of a

categorization for this because when I thought this through,

it helped me a lot with some of,

I have some of that same kind of discomfort with I guess throwing

the baby out with the bathwater I've worked with frameworks

for,

and they've almost been the core elements of a strategic output for a long

time. A lot of the time when you work in strategy,

what you're doing is breaking down ideas and recompiling them in a different

way. The outputs are sort of irrelevant.

It starts with the core of the idea and how that's shift something.

So I've always thought of frameworks as the engine of

my practice,

but then over the last few years I've been getting more uncomfortable

because I've been seeing frameworks become more and more

driving what people are doing and almost driving a kind of

completionist type attitude to things.

And I think it's taken a lot of the focus of the work.

So what I've been trying to do with teams that I've been working with is to say,

we need to bring the focus away from the structure of the information that

you're working with and actually look at the work.

What's the quality of the work? How fit for purpose is it?

What is it doing in the job that we're trying to accomplish?

So what I've been thinking about is

actually the framework is different to a topology or taxonomy.

And I think a lot of what, when we are saying framework,

a lot of what we're actually talking about is kind of a process or a taxonomy,

a kind of a structure for information, but not the information itself.

So if you go to, I'm going to pick on jobs to be done.

If you look at jobs to be done a milkshake, the framework would be commute,

slow, cold,

a certain viscosity. So it's slow to drink,

that's the actual content of the framework that tells you something about the

thing, but

the structure of how you write an empty templated jobs to

be done, that's not a framework necessarily in this model.

That's just a taxonomy.

And so I started to think there's a distinction there with an epistemology,

how you do something, a process,

and in ontology what is the actual thing that you're designing?

And that distinction helps me massively because I start to think,

well actually I'm really focused in thinking about the meaning side of it.

And that's useful to have a structure and useful to have a model that describes

things,

but it's not necessarily the same thing as you should fill out this

canvas and then you're going to get to a quality outcome.

There's a subtle distinction between them that I think is really helpful.

And so obviously everyone loves a canvas it seems,

or at least us people who write things like a canvas. And as you know,

so the way I think about frameworks,

the primary two that come to mind for me in service design are things like

Job down is obviously one, but things like I journey maps and blueprints,

also framework keep trying to emphasize to my students that they're a

framework for synthesis, right?

They're not really a kind of thing that you are just filling in

and it's done. And I kind of hate hearing, I know there's a reason for it,

but I hate hearing, my boss has asked me to design,

or the client has asked us to design three journey maps or five,

six journey maps, whatever. And that's often procurement driven too,

but with this idea of there's just a bunch of these things you can design as

artifacts and that's the kind of end result.

And obviously those things are a means to an end anyway.

And I think that's probably another thing to remember about frameworks is that

there're a means to an end, but they're a way of taking a lot of messy stuff,

say multiple peoples,

the research of multiple people's journeys through something and simplifying it

and synthesizing it into some kind of structure that aligns and matches up.

I mean, I dunno if you agree with that,

with those as frameworks or if are they just simply

artifacts of methods? Yeah.

Interesting.

I mean I think in this kind of process template

topology versus framework kind of

distinction that I'm using the journey map on its own,

it is just a grid and that's a template.

And so then got to be careful with the dangers of that,

which is drives a sort of completion is so everybody that's done this kind of

work will be familiar. Well, there's blank spaces there. Well okay,

we need to come up with something maybe not.

And so you get more focused on filling out every cell in the canvas

then you do in actually thinking about what the content is and is it the right

thing for the problem.

So the framework would be, well,

the actual content of a particular problems journey that it's useful.

This is incredibly useful.

The other bit where I think thinking this through a framework is really useful

is when,

and again this is kind of framework as embodied knowledge is when it's an

accelerator to understanding a new space.

So you come to a problem,

whatever it might be,

and you download a previous kind of piece of work or

theory or literature that has already thought through the problem and created a

structured framework around the knowledge in that space

or that if you haven't ever dealt with that space before,

that's a massive accelerator to understanding a new space.

And it might also be things that other people are building off that same

theoretical knowledge.

And so you're able to kind of collaborate with people better around that space,

but that's the knowledge,

not the kind of boxes in which we put the knowledge. And so I think

when you make this distinction, I've almost been in my notes,

I've been writing process and template and framework almost

interchangeably because I think what we're talking about,

a lot of it is if you follow this set formula,

you're going to get to a quality outcome. And that's sort of,

I guess the heart of my problem with this whole space is that we've removed

ourselves a little bit from examining the work and thinking critically about

the work and trying to think about what is needed,

what is actually the next thing that you need to do to improve the output of

whatever it is that you're trying to do.

Yeah, I mean I've always felt and said that it's the conversations in front of

a journey map or a B,

you said it in this article actually you said this thing about

it's a useful way to audio thinking.

And I think that one of the things that happens before I keep coming back to

that sort of synthesis analysis synthesis stage because probably sort of the

really messy stage, there's kind of ideation end of things too, I think,

and what should we be doing?

We've got a million ideas where they often come in and I guess that also comes

in at the strategic level too, where

you are thinking things through and a framework helps give you some order

through which you are thinking.

And arguably that's what the business model Canvas does.

It's also just a grid,

but it does a thing where it forces you to think it's not sort of good

housekeeping forces you to think around all the facets of a particular area in a

way that your habit might not get you to and it can help you.

Any of many of those product frameworks are a way to look at that.

Some of them kind of take a zoom level up, like safe scaled,

agile framework for enterprise, which yeah,

I could just leave that there. But there's a thing with those.

There are not only beloved of product here,

the beloved of management consultants for whom I've worked,

I've seen so many frameworks on slides,

which seem to consist of a lot of boxes surrounded by some other boxes

and arrows from each box pointing through every other box. And I kind of think,

okay, in what way does that help? What's that communicating to me?

And you're just telling me stuff's complicated and everything's related to

everything else.

And so there's a point where the framework seems to become

detached from the actual work itself and it sort of seems to

become a thing that helps us to vaguely talk about stuff where

actually the work on the ground really departs from what that framework is

supposed to be doing. Have you seen that going?

I see that going on all the time.

Look,

the distinction that I make around that is probably

actually it's useful to have a good and a bad understanding of just quality or

not quality. And that's really, I guess what I'm trying to build.

We're in this idea of judgment or evaluation,

is actually looking at the work and going, where does it need to go next?

It's largely a matter of going, is it good enough for the purpose that we need

and that's the driver.

So rather than the category itself being good or bad in itself,

it's the same thing with process. You run a process.

It doesn't mean the output is good, right?

You still have to operate it well to get a good quality outcome and you can look

at it and go, did we get a good quality outcome? No, throw it out, start again.

Or whatever the case might be.

I was looking at some of Lauren Tan's

PhD work earlier

because just thinking about that idea of process, not process,

and I remember she wrote this PhD on dots oh seven,

so this is dating me quite a bit,

but talking about ideas,

and I hadn't clocked this kind of reference as much, but kiss, dos, work on,

we rely and have come to rely too much on process.

And again, we can talk about is this a framework or a taxonomy or what is it?

But he's talking about the objects of the work,

the context of the work and actors involved in the work rather than necessarily

just the process.

And so maybe it's a rebalancing of these kind of priorities and thinking about,

well actually if we've lost a little bit of the focus on the work because we've

been concentrating on removing ourselves as designers from the work

and almost kind of anonymizing the design, anybody can do it.

It's a capability that anybody can learn

that's all kind of really noble,

but it loses something around how you actually do work.

Work happens, a particular piece of work happens by somebody,

whether it's a designer or not is kind of irrelevant,

but the outcome of the work has a certain quality and I think

it's sad in a way to lose the expertise of saying somebody that

has put a lot of time and effort into growing a practice around achieving

quality outcomes is

anonymous or decent.

It's not the right terms to talk about decentering or not,

but incorporated in the work or the thinking.

Yeah,

I mean I have done my bit of teaching training design teams and

it's been often under the guise of,

or not non-designers under the guise of design thinking,

which I've always slightly felt uncomfortable about,

felt a bit queasy about. But one of the things I've noticed,

and again I noticed it with students too

partly because at that stage of their careers that they sort of dunno any better

in some respects too and they're just learning those things.

But I'd certainly say it with professionals and I guess the thing about design

thinking is you can skim the surface. I noticed in coaching too,

there's lots of coaching frameworks and things like that and whenever I've

experienced them as a coachee, I've always felt like you can ski,

you can go through the steps but not actually do the work and not really get

into the depth. So personally the way I coach is

it follows much more of a style that's similar to psychoanalyst style

where there are some tools and activities but there to get us somewhere rather

than to fill the fill in the boxes or check the boxes.

One of the things that comes up quite often is this idea of how

do you know when the framework or the method or the process,

and I use those as one bucket more or less to mean

a thing I'm borrowing from someone else or that someone else has done and I'm

applying to my work roughly to say someone else has done this,

someone else has come up with this framework, this method, this methodology,

this is a process and we are going to use it for our work.

And I feel like there's always this question is

it's not working for some reason if we're not getting the results we're after.

And how do you develop the critical thinking or the ability to say,

you know what,

this is the wrong method or the wrong framework to be using for this problem at

hand versus we are doing it wrong.

I mean it's interesting.

I almost think it doesn't come up in my practice that the problem doesn't come

up in my practice because always treating the framework as the

output, not the input.

So you're always working on it and so you might borrow a piece from something or

piece from something else,

but your focus is continuously on the outcome.

And so

it's like this piece of the puzzle comes from here and it's working and that

piece isn't working,

so let's get rid of it and we'll bring in something else from somewhere else.

And that might be completely new,

it might be from another piece of work or understanding,

but the critical thing is always the question, is it working?

And I dunno, I feel like maybe it's a glib answer

because it seems to kind of skirt the question,

but actually I think it's quite critical to this idea of,

well actually that is your role as the

developer of this piece of work is to be critically assessing it.

I've been thinking, I use software metaphors quite a lot in my thinking.

I've been thinking about what a stack might look like where you've got a library

that you're using for a particular piece of the puzzle and then another thing

that you're using for something else and you're kind of trying to,

I guess to have a little bit of material honesty about how those pieces all fit

together.

And then also knowing that as you're building that stack up,

you're kind of relying on relying on things and being

clear about where they do and don't work.

It sort of gets to another one of the tricky

bits when you do this and maybe go back to the scaled agile example

without trying to open without.

Banking it out too much.

Without opening a.

Box of I don't think anyone.

Box of frogs. What that's trying to do is,

and other framings trying to do that same thing is they're trying to add kind of

collaboration around a common reference points and that's incredibly valuable,

particularly at scale.

So you need to be able to work on multiple pieces of

the same problem when you're working at multiple teams.

And so there is a call therefore,

well let's build some standardization around a particular piece.

The tricky bit comes when you are then kind of reliant on a piece of

framework that's not working but is a part of the collaborative

engineering. So

how do you be critical about the framings that you're using and how you're using

them and how do you build in a bit of interoperability

without holding things, holding things back?

You still need to have a bleeding edge.

And so maybe there's this kind of idea of a framework stack and some teams are

running the bleeding edge and other people are running the stable one.

And depending on your ability to navigate the kind

of edge cases that might come up from using the framework that you're using,

you select the stack that you can operate.

Connor just made this comment about there's a delicate line between using a

framework to help build understanding and around a focus area and overly

abstracting it, the information that's actually important.

And I kind of feel like there is a relationship here obviously between what

we're just saying at the strategic level of things,

as you zoom out,

you start to look at organizational frameworks and look at this.

So we've got this framework,

so this is how we're going to then structure teams and who's going to be in

these teams and then who is going to be managing those teams?

And they were kind of power structures that start to creep in with those

frameworks. And again,

I feel like those things start to get abstracted from the real work on the

ground,

how those teams actually work versus the idealized model of it.

And I guess the more strategic you go,

the more that's happening too where you're getting that kind abstraction of this

seems like nice idea but in practice it doesn't work.

Is that a problem in the strategic end of things?

Partly maybe.

I'm wondering if there's something to do with the feedback loop is longer too

of knowing by which,

I mean here's our thought about here's a hypothesis about something and then

we're going to try and do it and then we get some data in return once we do

it strategic work, there's a longer kind of feedback loop there.

I think sometimes with the strategic work actually,

I mean there's an output of that strategic work and an impact in a broader

ecosystem that is on a slower cycle,

but a lot of the time you get feedback really,

really quickly in terms of the cognition of the idea that you're working with.

So is it resonating with the team around you?

And I think if you shift your idea of

strategy from an idea of this is purely an

idea based thing about something in the future and this kind of romantic idea of

strategy too.

Well actually strategy is the work on the ground to get people to understand

what you're even saying or shift the context in which they're trying to think

about something. You actually, I dunno,

you have a strategic focus which is about preparing the ground a lot of the time

more than necessarily,

and there might be more of a meso strategic kind of ground that really

covers in the far off strategy world

a lot of the time are actually freer, the stakes aren't the same.

And then in the more near term where you're trying to translate that abstraction

into something that teams can actually work with the practicalities of making it

understandable, incredibly critical.

So a lot of the time what I am trying to do

and the framework is it's an ontological exercise of trying to reframe the way

that people are thinking about something.

A lot of the time what I'm trying to do is isolate the bit of the framework that

needs to change

and leave the rest unchanged if possible so that you're reducing

the burden of

new understanding and thinking that other people have to do.

Just make that really practical. It might be thinking through

a

new kind of type of way of working for a business unit

and just trying to figure out what's the one bit that actually shifts the

dialing what they're able to do and particularly in the near term

that then opens up their ability to actually consume higher orders of

abstraction. So use the rest of their structure,

don't change the whole structure,

change one piece of it which opens up a new way of thinking or looking or a

new kind of practice. You relying on that practice,

that next step to be the unlocker for the subsequent steps. So

rather than trying to reframe everything in one go,

which I think when you're starting out in strategic work, that's what

the design.

The temptation is.

You.

Trying to do that everything's a nail and you've got the strategy hammer.

A hundred percent and you've solved the whole world and everything.

But I think over time you start to try to actually do less and just

figure out how you can plug everything in without that shifting that much

because you're just trying to unlock,

unlock the possibilities of the next step.

If you don't get that first step,

the whole future thing is kind of pointless anyway.

I definitely to see that

it's the achilles heel of service design is that wanting to kind save the world

and see everything's connected to everything else.

So we have to change the entire system and for those you people who know

systems thinking Don Donella Meadows had this list of the,

I think it's 14 levers of where to intervene in a system and

increasing order of effectiveness but also difficulty in the bottom line is that

change the system and I notice it with students all the time, sorry,

I feel like I'm picking on my students today.

Their projects are make the world use less plastic and things like that and it's

so massive.

I think once you get maybe a bit older and more experienced and jaded,

you're like,

I just want to make this tiny bit of the service a bit less rubbish and that

would be a win. I want to talk.

I mean I'll pick on that a little bit because I think sometimes the piece that

you're looking for is the lever point,

so it's not necessarily just a tiny piece,

it's that one little bit of unlock that allows momentum or flow or whatever it

is. So yeah, not to get trapped in the,

I just want to make the change I can make actually sometimes the one

small bit is the bit that's actually the critical

elements of a larger change.

I mean I think from a stakeholder management point of view and from design

leadership,

it's a really crucial thing that particularly if you're coming into something

completely new, it's clearly needs change,

but everyone's a little bit stuck on how to do it.

I think often changing one or two things that are quite small,

but constant irritants like things that people have been irritated about for

ages and approaching and they've been locked up in some way or

some of the reasons why they don't change is because the existing framework

actually doesn't consider them a priority or important.

Sometimes it's one of those gap things where two different departments usually

feel like the other is responsible for it and so there's a little gap in the

middle where no one really takes care of it. I see that all the time.

I think that's a particular kind of lens of service design to look at those sort

of cross channel things and see the moments where a customer moves from either

one step to the next or between channels.

There's always these little kind of cracks I call 'em sort of crevasses, right?

This little crack.

It doesn't seem like much to the organization from the outside,

but if you fall down as a customer, it's a nightmare. And those kinds of things.

Always the handover.

Yeah, it's always the hand transitions.

I mean transitions I think are always the biggest problem

in whatever direction.

And in fact partly it's because I think the things themselves get taken care of.

This sort of

that exercise that you do in design school sometimes,

which is to draw the negative space that the spaces between

letters or spaces between objects in order to trick your brain into seeing them

differently. That's actually quite a good metaphor for a framework.

And looking at those gaps in between is often really important.

Which maybe brings me onto this idea of the autopilot thing because I think one

of the things that design has become very,

I think design has become a bit process obsessed or had become become process

obsessed and now it's made its way into product design and design systems too.

Obviously another way of operating a little bit on autopilot. I think

they're obviously incredibly useful.

I understand the reason for them particular scale and they create great

consistency and speed things up an awful lot.

Do you feel like there is a kind of aspect though there where you mentioned

this kind of monoculture idea that,

and I slightly clicked bait in the title of this said it leads

to boring products and services.

I posted a thing on Mastodon a little while ago where I had all the, I dunno,

I had a bunch of different apps and they were all some kind of social media

thing,

whether they were sort a Twitter based thing or a mastodon based thing and they

all just looked the same.

They all have that same kind of four or five things along the bottom,

perhaps a kind of ribbon up the side of I'm looking at one right now which has

got the same kind of structure. Do you think that that kind of

increased process focus on design means that

it actually creates kind of things that are pretty bland and boring that

everything starts to look the same? That's such a leading question.

It's a terrible research question. Do you think I'm right about this thing?

It's what everybody wants to hear us. So

I think these things are cyclical and so

if you think about it as increasing layers

and then black boxes and then those are recombined in different ways to get

new things,

you are always going to reach points of peak something and

then they get recombined in a different way.

There's a new thing that gets unlocked.

So I dunno that I necessarily,

maybe it's an inflection point.

I feel like we're at an inflection point for design where if you

look back 10, 20 years,

there wasn't good design in every app that you used to.

I mean there weren't apps for.

Instance. No, there weren't apps in my day.

There weren't apps in the way that you think of apps now,

but there was software and there were services and the bar was pretty low.

And that bar has risen and

it's become I guess hygiene to have relatively good design

in packaging or software design or whatever it is.

And so that's resulted in a kind of plateau and

that's kind of where my thinking is with that.

And so part of this kind of okay process has got us this far,

it's helped us to push the boundaries of what we're doing wider

and more people are consuming good design

than maybe in the past.

And actually the volume of things that we're consuming has also gone up,

but we maybe need something different for the next step.

There's something else that's needed.

We always have conscious kind of breaks in order to have

and have we got boring things? Yeah,

I feel pretty bored with a lot of what we deal with.

I think we sort of run the end of clean

simple convenience.

These kind of ideas have maybe reached

not necessarily like a limit because I think there's a lot in those

ideas and they're not necessarily easy to achieve,

but you can look at almost any category and you'll find two or three that are

fairly similar.

I did an exercise recently doing a scan for

financial services clients.

You are always looking for something interesting.

And then it was quite interesting looking for the not so interesting things and

actually looking at some of the copycat things in secondary markets was really

interesting. They were all the same message over and over again.

And it was like,

is this somebody that's cleaning up in this context across the whole world by

copying and pasting across different markets?

Or is it just that these ideas have become so formulaic that if you want to be

successful you have a simple easy marketing message. And

I guess the interesting thing, if you then think about,

well what do you do with that that I don't necessarily have an answer for?

So I think that's where we need to now start thinking about,

well if we start reintroducing that kind of idea of good and what is the kind of

quality output and go beyond simple and convenience as

the only markers of that, how do we start thinking about distinction again,

maybe that allows a little bit more friction

possibility for distinctiveness in again.

And I guess if I'm right and we are right and we're at this kind of inflection

point, maybe our clients need to start looking for that as well because they

also going to have to

look different to the next thing for it to be a competitive advantage,

it's not an advantage anymore.

And so that's the thing with process,

I guess that's the kind of culturally strategy for breakfast thing,

but it's this idea that process is kind of easy to copy and everyone seems to be

doing it too,

but it's the execution on it that makes the big difference.

And you see that all the time with copycat things. Jason, Jason,

hi said,

it feels that safe is a great example of something seductive to people that

frameworks can be seductive to people for providing a fo simplicity on a complex

world.

And it kind of feels like that's really where we are with a lot of those things.

There's this constant desire to try and

linearize and make something complex into something that's

complicated as in a complicated thing,

we can kind of take it apart and into its component parts,

work on each bit and put it back together again with obviously complexity.

Everything is connected to everything else.

And if you pull it apart within then you kind of just break the whole ecosystem,

which I think has been service designs kind of mantra for forever,

which is to think of the ecosystem.

I think businesses really struggle with that because stuck in an industrial

mindset of the way they organize and

Nicole just said, hi Nicole,

this thing about if they're useless,

they describe how people actually work,

but they can often be prescriptive and taken as rules rather than the kind of

inspiration. And it seems to me that the real struggle with

I guess sustainability and climate change is the biggest one where everything

really is connected to everything else, which is for businesses to

spend the time, I would suggest on considering the complexity of the problem.

And I think frameworks can be very, very useful. They help you

explore a complex problem from different ways. They help you force your

brains to look in different directions and consider different

aspects of things that you might inhabit and in speed not always do,

but it does feel also that there's a,

I'm thinking of the canvas of some kind.

There needs to be the box there that's like, what's the maddest version of this?

Or what's the thing that kind of completely blows this up or turns us upside

down?

It thing that Mark Curtis is one of the co-founders of Fjord often used to say

is that, oh,

you know what this project needs is a moment of madness where we really kind

just get out of

that sort of process and that routine. But I think that takes time.

I think that takes an investment in time to want to do that.

I don't think it's a thing that you can kind of do quickly

because you necessarily make

the work you're doing really messy. Again,

you sort of force yourself back into that messy middle I think when you do that

or do you disagree or have a different view?

No, I mean

I guess where an example of where they are comfortable,

and I can say again,

I'm completely uncomfortable with dismissing them because they're such a kind of

intrinsic part of the way we work, but how we work with them is critical.

So if you are insisting that you do this

as an exercise at the end of every workshop that you flip it,

I worked with somebody years ago who was had this great

make the evil version of it,

it just as a way of reframing it or what's the dark version or

it is a lovely mental flip, but it doesn't work if you do it every single time.

And so I think how do we keep things

alive means that we've got to fight against things being stayed.

And if your framework is contributing to, again, it's focusing on the work,

if the output that you're getting is feeling dull and boring,

maybe you need to inject something else into it.

But you've got to be looking at the work to understand whether that's the case

or not.

So it's the kind of uncritical use of frameworks that's more

problematic.

I dunno if that means that it's the frameworks problem with the operator's

problem,

but we have a responsibility to make our processes work

for us rather work for them.

I mean it's always the operators,

it's always a problem between chair and keyboard. There's always

the human aspect of it. I think that where it goes wrong,

and I kind of feel like that comes back to this idea of,

so I'm going to make a yoga reference here.

My wife and I have done ayenga yoga for a long time.

She's a teacher as well actually.

And Ayenga yoga uses props and the idea being that it's better to use a block or

a chair or something to maintain the integrity of the kind of alignment rather

than bend yourself out of shape.

But there's also this idea that when the teacher calls a certain

pose, everyone grabs their props automatically.

And often a good teacher will go just get rid of the props for a second and see

what it feels like without them. Because you used a prop as a beginning,

that's fine, but after you've been practicing for five or 10 years,

why are you still reaching for that without thought? And it feels to me like

that's a kind very, really good sort of analogy for this idea of

reaching for the prop and not really thinking and not really reflecting on

what is this achieving for us.

And if there's a sort of thing I guess to come out of this conversation is this

idea of really pleading,

I guess I keep going back to this idea of speed and time for some time and some

part in the process actually for reflection and thinking and critical kind of

thought rather than, well that seems good enough,

bang it out and we'll fix it later.

Which is I guess digital main a kid's heels that you can just release

something and then fix it up later if it didn't turn out very well.

And I think with say other products and services and I'm interested in maybe the

government work you've done, you kind of can't do that, right?

Certainly with the physical products you actually have to do a lot more testing,

but you also have to do a lot more critical thinking about what's happening.

It might kill someone. Is this true in the government work you've done too?

I'm just trying to think if that's necessarily.

Is that true? I dunno if it's true.

Well, I mean it depends on what it is, right? So yeah,

that does have that safety. I'm not sure I can, it maps

directly because usually the work that I've done has been perhaps a little bit

upstream of an actual medical outcome

and that will need to be there.

But actually you've kind of focused on figuring out the work.

And so the feedback loop is more about trying to figure out what's working

then necessarily

what's the kind of implemented outcome at a medical

level. The service level tends to have slightly different,

slightly different parameters than the medical.

I guess I'm thinking people go back and listen to the podcast I did with

Kate Taring actually about,

we've talked about policy quite a lot and policy as an act of design and this

idea of

actually really thinking through what's the intent here,

what might be, because policy is also framework.

If you hear about policy frameworks all the time,

this is an intent of what we're trying to achieve here and then how it actually

pans out on the ground and spending the time to really rigorously critically

reflect and analyze that because the debt scandal in

Australia is a really good example of how something like that can go wrong.

People can Google that. We don't have time,

but it's where this idea of a kind idea up here gets just pushed

through almost like a Play-Doh,

one of those forms that you push play-dough through all the spaghetti comes out

and then it all goes wrong.

What it does make me think of is regulatory frameworks and how they are

quite often described,

designers get kind of hands off about it or scared about it or it's

this compliance thing that needs to go, that's a step down the line,

then we've got to kind of pass.

But actually a lot of the time that framework

has a spirit and it's actually quite close to what we're trying to do.

A lot of the time.

It's trying to protect consumers or protect people that are using it.

And so it has an outcome in mind,

but then it tries to wrap it in a particular kind of framework and people then

start adhering to the framework where actually if you step back from that and

say,

well what's the intent of this and what are you trying to actually accomplish

with this? A lot of the time you can actually go quite,

can marry the best outcome

for the person who's impacted to the spirit of the law.

And that's

something to kind of always Hal to that spirit versus the letter.

And maybe that's the same thing for frameworks. It's like,

well what's the spirit of this framework and how do I

consume that and interpret in my own practice rather than just

follow the letter of it?

I remember working on,

I think I mentioned this in the Kate Haring podcast actually,

there was a project I worked on for a large government organization,

public organization, government organization in Australia.

And there was this thing that kept coming up where in workshops,

and we can't do that because policy and eventually we got the policy person in

and every time that came up they went, no, it's really not policy.

And people kept saying, that's the law. And I said, no, there's the law.

Here's our policy as a response to that law and then here's how this gets

interpreted by us all the time as kind of the dogma and there's these different

levels and it gets narrower and narrower more fixed to further down you go.

And as you're saying,

if you actually take the effort and time to step up a level,

you actually get much more wiggle room in terms of the things you can explore.

Absolutely. If designers aren't reading the regulations themselves,

they're missing a trick.

I keep detailed notes about all the regulated frameworks because

usually

there's the legal teams and the compliance teams and they're kind of quite first

in the letter of it, but there's a lot of other people that are,

it's almost hearsay.

Around it is.

And you can kind of go quite quickly through that.

Actually,

one of the things that we found when we were doing the research on this was

the end users of this service, I can't say who it was,

but the end users of this service, the way that people knew, oh,

this is what you can and can't do was because of a Facebook group and

it was, it's kind of a language problem and a design problem in that the policy

documents so sort of arcane and opaque in the language that they were written in

that it was sort of reinterpreted and the simplified version was the thing that

was circulating on Facebook and a lot of it was wrong.

A lot of it really was hearsay and then it just sort becomes the

norm.

The classic of post-it notes in the call center.

That's the kind of actual source of truth, not the.

Exactly policy. So look, we're coming up for time,

the talking of time. What are your hopes for path?

We've got quite a lot going on trying to

two years old studio,

largely largely me as a practitioner and intentionally keeping

it small and working with networks of people,

but trying to work at finding what the right kind of fit is and in the context

of I guess a market that has shifted a lot from kind

of buying projects from agencies to building a lot inhouse

and so experimenting a lot to try to find

the right way of working with that market.

And then it's interesting talking about frameworks because

building a lot and trying to embed some

stuff into some tools.

And so FRA has come up as a key part of that as almost the

intellectual bedrock of whatever it is that you're trying to build.

So I'm trying to build a lot a practice

and then working with some really interesting clients to implement some of these

things at scale, which is this really great testing bit.

So the way I look at it is,

I guess product market fits not a bad kind of idea for the way the practice is

evolving, working,

trying to find the right fit for it,

a vehicle that helps keep trying to grow

things and do things a little bit differently all the time and keep on the

edge of evolving things,

which is where I'm kind of happy about practice when I'm going to doing

something new or different or kind of evolving something.

Yeah, yeah. And clients mostly in Australia or all over the world?

Mostly in Australia. A little bit of a mix, but yeah,

a lot of large

financial services companies is probably the

mainstay of it, which if Australia, that's.

It's quite a lot of them.

The bulk of the market here,

but also big problems around scale.

And so that's the elements of my practice that I think is the most interesting

and challenging is how do you take these kind of practices and then grow them

out across large teams,

large volumes or quantity of work.

And a lot of my practices at that kind of thinking about a portfolio of

work in how it orate together, not necessarily just individual pieces.

So the show is named after Ray Charles Eames film

Powers of 10, which was about the relative size of things in the universe,

which is for me

the most useful metaphor for service design or the idea of moving to different

levels of zoom and the similarities actually and echoes there.

And so the very last question is always one small thing is either

overlooked or could be redesigned that would have an outsized effect on the

world.

Maybe this is a glib answer,

but it's something I've just been thinking about a lot.

I'm really interested in,

I dunno if this is a small thing, maybe this isn't a small thing at all,

but how batteries

battery flow and how there's this kind of behavioral piece around batteries

that as we get more used to batteries,

we are kind of embedding them in everything and they all become interconnected

with each other.

And so this is things like getting the grid connected up with your car

so that you're charging at the right times.

And I got obsessed a little while ago about this players all the way down to

charging headphones off your phone or all this kind of stuff. So

I like it as a problem because it's such a kind of

clear behavior and technology and system kind of example.

So it feels like there's something kind of interesting in this thinking about

the power grid as something that you carry with you that's a really nice,

interconnected, small thing that goes to a bigger thing.

Yeah, charging and charges. They're kind of interesting space at the moment.

I mean obviously in automotive world there's a big thing going on there.

It seems lightly that Tesla is going to be

a charger company, perhaps more so than it is a car company.

I was interested to see,

thank you so much for being my guest on Power of 10. Where can people find you?

Where's the best place? Is it path or is it.

The best places? My website, paths ventures.io.

I use it quite extensively and there's

a bit of framework tools,

stuff that I'll be releasing soon.

There's quite a bit of stuff there that's nearly ready to be shared.

And on social media, LinkedIn is the main.

Place. Yeah, these days I'm kind of checked out of

almost everything.

Checked out everything else. Okay. Alright.

Well thank you so much for being my guest on Ton.

Lovely, Andy, thanks for the chat. It's been really good.

So if you've been watching and listening to Power of Ten,

if you would like to find anything more, you can find, wait, search my name,

Andy Polaine, really everywhere. You'll find me on Mastodon.

I've kind of pretty much given up on Twitter.

You'll find all the show links at polaine.com,

where you can find more episodes.

You can check out my leadership coaching practice on my courses,

sign up for my very irregular newsletter.

I need to try and make it become more regular, but called Doctor's Note.

If you're looking at this on YouTube,

there's a whole bunch of more stuff that I'm going to be doing on YouTube.

So give it a thumbs up or subscribe if you've got any thoughts.

I put them in the comments.

I know for many people this live stream was very early in the morning and for

the Americans you'll all be asleep. So if you got any thoughts about it,

then pop a comment in and I can respond.

That's the nice thing about YouTube versus the podcast.

This will also appear on the podcast feed.

All the links will be in the show notes down there.

Thanks for listening and watching and I'll see you next time.