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.