(percussive music) - So as John said, I've been doing some version of this thing for a long time. I really only just put this slide on not to tell you about me, but so you could have my Twitter in case you wanna catch me later, 'cause I often forget to do that, and people are like, "Who are you?" I'm like, "Oh yeah." So anyway, I'm like Madonna.
I don't get mixed up very much, and she's never Tweeted back at me.
It'll happen one day.
I'll be very excited.
So in this new role, so my, the company I work for are a traditional software company, and in the last couple of years, they added both a design and a data and data science practise to what was traditionally kind of Microsoft .NET traditional software.
They're very well-known for that and clients come to them and they're known, but they knew that they needed design, but they don't really know what it is, and of course they don't then, you know, it's consultancy.
So somebody has to find the things that we're gonna work on, identify the clients might need us, listen for the right things, and then do all the shaping of what that is, and that's not me, because I'm not the salesperson.
So I have had to spend the last six months or so figuring out, because before this I was a freelancer.
It was easy as a freelancer.
I could say, "Right, you came to me.
"I can do this, this, this, and this." And they would go, "Yup, that's exactly what we wanted." And that was easy.
Now I'm having to sell a whole concept to people who inherently don't understand it, which is a wobbly concept anyway.
So I had to kind of go deep and figure out what even this thing was, what the world thinks it is, what my, the people I'm trying to communicate know it as, and what the people they're communicating with know it as in order to make sure that the right opportunities come our way and that we don't just have to paint things pretty. So it's been an interesting process kind of unpacking all of that and really trying to understand all that kind of secret sauce of design.
So it's certainly true that kind of in business, design has hit the mainstream a bit.
Every couple of weeks, there'll be a new article about the business value of design, how design will make you innovative and competitive, that kind of thing.
The kind of the mainstream business press, though, not necessarily, like, the world as a whole. And what I thought I would do as a, when I was kind of writing this, the beginning of this talk was look at what the business world is seeing about design. So I went and dug into a few articles that I could find, a lot on kind of McKinsey and Harvard Business Review are the ones that talk about it a lot, and that have the eyeballs of business runners. Excuse me for these slides being really dull-looking. I'm like, what do I do with this? I don't know.
Article called What every exec needs to know about design. So it's, they said it's all about creating experiences. It's user-centered.
There's emotion and desirability, and then some stuff about competition and testing. Making design a business priority.
Thinking about customers, empathising, end users, solving problems and keeping customers in mind. Oops, what'd I just do? I hit the button with my thumb that turns the slides off. Who puts this button that turns the slides off right underneath the button that you're trying to press? Anyway.
Lucky I recovered from that.
Article called The right way to lead design thinking. There some empathy in there.
Ambiguity, I love that word.
Rehearsing new futures.
That one's a bit jargony.
How to get the most out of your design team. Hire experienced leaders.
Take the handcuffs off.
I don't even know what that means.
I don't know why design had handcuffs on in the first place. Run experiments, that's a good one.
Measure and encourage adoption.
This, if you're interested, is a really solidly good article on design, and I'll make the slides available later, of course. They dug into businesses that had a design function and really looked up what made that work.
And so, and it's a good kind of solid article. The others are just kind of a bit of fluff pieces. Good leadership, cross-functional talent, iterativeness, and user experience was in that one.
And if you would like to read something that is, like, full of opinion, and strong opinion, at that, this is actually a decent read.
It's really kind of funny, because it's John Maeda and he has thoughts, but it's worth having a read of this one sometime. So from that, I'm like, okay, business is seeing something in this thing called design. They're reading these kind of articles.
They're getting something out of it that is kind of user-centered-ish, kind of innovative, kind of empathetic, but I don't see that generally.
Mostly people I talk to still don't know what design is. Our customers don't know what design is.
Even listening yesterday, I missed the early talks, but I caught everything after lunch.
The way we spoke about it yesterday was a bit incoherent, still a bit about the visual.
So certainly in the world, people don't understand what this thing is, even though it's kind of rising in the press and with a bit of coherence.
And the reason is that the word itself is a problem. And if we could actually just unpack this word and throw it away, we would find life a lot easier, but we can't do that.
You can't just throw away words that people are already using.
And people use it in two ways.
Like, as a noun, the design is the artefact.
So it are the drawings or the screen layout or the architectural diagram or the pattern, if you're a fashion designer. As a verb, it's like the actions of deciding those things. These definitions still don't clarify to anybody what design's really all about, especially our version of it.
So, I thought, what I was trying to here was unpack it enough so that when you're needing to communicate either your value, what your team does, what your secret sauce is, you've got something that is better than just, "Our design is amazing." Anybody who knows me and sees me talk knows I always go into a tangent on cognitive linguistics, and we're gonna do that again today, because it matters, not just because I like cognitive linguistics and tangents. There's a super interesting thing about the way our brains work and the part where they operate.
So if you think of kind of most concepts in the world sitting in some kind of hierarchy, like, everything bundles up into hierarchies. So if you think about the kind of hierarchy of animals, dogs, dalmatians, or the hierarchy of furniture, tables, boardroom tables, the place where our brains literally operate is in the centre of this hierarchy.
We don't think at an abstract place, and we don't think at a detailed place unless we're a specialist in an area.
So I actually kind of think around this spot because I used to show dogs.
So if I look at a dog, my brain says, you know, thinks of the breed, but most people go, thing with four legs and a waggy tail and that's smiley and happy.
It's a dog.
If you walk into a place where these things are sold, you don't look around and go, furniture, if it's only, like, tables.
You go, table.
That's where our brains work.
This level of thinking is where we can interact with things in the world.
So you can pat a dog, you can sit at a table, you can sit on a chair, you can throw a ball.
It's all about how our bodies interact with the world, and that's where our brains work, it's where language forms, and it's where we inherently think.
I promise I'll come back to why that matters and is not just a random tangent.
The other interesting thing about cognitive linguistics is that when, the way that we form ideas and concepts naturally is based on our experiences.
So our experiences with a concept is how we build them into our brains and how they build up over time.
So if you are working with somebody whose experience of design is primarily about visual, their brain is gonna be wrapping visual around the whole thing.
So when you read stuff that John Maeda writes, like, he clearly has an idea of what design is in a broad sense, but he has a strongly visual background, so you see it permeate his writing.
If you work with somebody who, for design, them design is quite strategic, that's how they think.
If they've come up through a school that's all about design thinking, they think that way.
So you will all have a concept of what design is based on your own experiences, and that's fine.
It's just important to recognise that that's how we build up ideas.
And it kind of sounds really obvious when I say it, but it's not how we always kind of understand how we think about the world.
The reason that matters is that because we don't necessarily think in that broad kind of part of the hierarchy, we don't think about what design is, we can't think design and get a picture of it. We can't, like, there's no concreteness around that. We can certainly talk about it as an abstract concept, but it means that we're all often missing each other. What we can do practically is go down to that next level where the pieces are more visualizable.
I don't know if that's a word.
More concrete, and where we have a better shared understanding of what the thing might mean.
So I'm gonna go through what I think are the pieces of design at a more concrete level, at a level where you can think and where you can communicate better.
So I think, again, our style of design, which is a little different to other styles. Design is inherently user-centered.
It is all about really understanding the people who will use the things that we're working on, not just thinking about them, not just empathising with them, but actually working with them and involving them in our design.
If you read the McKinsey study with the diagram that I said, when you read that through in detail, it's not actually about design.
It's really saying user-centeredness won.
In the companies who had a user-centered practise, not a design practise, that was the secret sauce that made them amazing. This is the place where we can also build in the concept of genuine inclusivity by being user-centered, by understanding people.
I don't care if you call it user-centered, human-centered. I'm not gonna get into the argument of the word user. Whatever that is that we're really about the people who are using our things, and that's a concept that you can actually communicate. You can tell people the reason this thing works is because we work with people, we understand them, we build things that actually work for brains and their tasks.
Design is also inherently creative problem-solving. And I'm all, you can probably tell this, but I'm all about using as little jargon as I possibly can, so I never, ever say design thinking, even if I'm running what literally looks like a design thinking workshop, I say, "We're gonna do creative problem-solving today," 'cause that's a little jargony, but not as jargony as design thinking.
So we don't just go, okay, I have an idea.
I am gonna run forward with an idea and I'm gonna get something at the end.
We...
Try different things.
We explore different avenues.
We do different versions of things.
We don't just go a linear path.
And that creative problem-solving, being creative in trying different ways of doing things, and I don't mean, like, artistic creative.
I mean tackling things in a bunch of different ways is a core part of what makes this thing work, and it's another way that you can say the reason that this project is going to work is we're not just gonna pick up an idea and run with it. We're gonna check that they're, that we've actually got the right idea.
There's lots of ways of doing this, and we're gonna pick the good way of doing it. Another thing about design is that it's all about sharing the experience, and this is another powerful reason it works. So as I said, I've been doing this for a long time, and when I was starting, the way we did design, and I'm terribly embarrassed about this now, is the designer would kind of get the brief, the spec, whatever it was, and go away and, you know, do some drawing, or do some, you know, wireframing.
And would come back and go, "Here's the design! "Do you like it?" And all the stakeholders would go, "What the fuck have you done? "That doesn't make any sense! "What have you--" (babbles) And you're like, ugh.
And I spent years watching people on forums and things asking, "How do I convince everybody that my design is right?" And I'm like, well, maybe it's not, 'cause clearly I've been the grumpy old lady of design forever.
But going away into your corner and creating a thing and then showing people, they don't know all the hard stuff that's gone on in your head, all the things that you've thrown away, the ideas that you've tried, the things that didn't work, the things that did work.
All they see is a thing that might not be what they were expecting, that they've got questions about.
Now, and not across the board, but definitely more, we use design as a shared experience.
We get in rooms with our stakeholders.
We get in rooms with our users.
We work through problems together.
We explore different ideas.
We throw away the ones that don't work.
We do that in a shared way so that when you get to the end and you're like, okay, this is the thing we're running with, the whole team know the thing you're running with. It's not just you.
It's not all on you.
It's not all on you to communicate.
The whole team owns it.
And I thought this was a really funny quote, 'cause it's such a good visual.
I do not know how that little thing works in a URL. I'm like, that's crazy, but, I don't know how you would, like, type it out if you needed to do it, but that's what the URL looks like.
And this was from the, John Maeda's design in tech report, the one with the red in the picture.
"Alone and isolated within a company, "design is a microworld of aesthetic high-fives." I don't know, whatever.
I don't think you guys thought that was as funny as I did. I thought that was pretty funny, actually, just to picture, like, oh, we're good! Look at how we did, how beautiful we did.
And so I just saw I have a good note on my slides. I don't know if you've ever seen these long discussions about everybody is a designer.
Somebody will say it, and then the whole of Twitter will go, "No, everybody can't be a designer!" If you share the experience, if you work together as a team, your team are all designers.
You are all involved in making those decisions. There's not a secret sauce.
Another core part of design is designing with people, not for them.
So co-design isn't practised across the board, but when it is, and in the right contexts, it's really powerful, because in a lot of situations, having people design their own experiences is much better than somebody abstractly designing a thing and saying, "Here's the experience you're going to have." If you can involve people in their own experiences and have them contribute to it, so if you're doing kind of any enterprise work or, you know, work where people are reusing a thing day in, day out, they should be involved in that.
They don't have to be designers, as I just said. They need to be with a team who can help make decisions. But this is again one of those core pieces of why this mysterious thing called design works. Involving people in actually creating their own experiences. Kind of related to the creative problem-solving, design is experimental and iterative.
This is my only wanky diagram.
Don't take a photo and say that Donna, like, thinks this is a good diagram.
Every time I look at this I'm like, I can't quite figure it out.
But the thing that it does have is it has the nice little experimental loops in here, and it has some kinda egg-shaped loopy things there. But it does communicate that we don't just take that straight path.
We experiment, we try things out, we go backwards and try them again.
We take the things we learn and we build them back in.
Even though I don't love the diagram, I love the concept of learning from something, taking the learnings back, building as you go, learning from it, and not just assuming that you can go straight from one thing along a linear path to another. Design is also implemented.
And I know that not everybody agrees with me on this, but I think any kind of design that has no delivery or implementation is literally just hand-waving theatre.
It's when, so you can spend a lot of time, and it's good to spend time experimenting, coming up with ideas, you know, throwing things out, poking and prodding.
At some point, that has to go through a process to get built, and that's where you learn everything that is hard about what you're doing.
That's when you redesign and design as you're going, as you build it.
And you might go, yeah, well, of course everybody designs with, everybody delivers.
But I have been interviewing most of this year and a lot of last year, and I had so many people in front of me who to them, design was the double diamond that they'd been taught, which is you go wide with ideas, you make a prototype, you test your prototype, and then you're done.
And they thought design was coming up with a prototype. That's not, that's just having an idea.
Same as hackathons.
Hackathons are just having an idea.
Until it, until you get it through and you push it and you check that it works against the real world, it's not a thing, it's just an idea.
So to me, and this is one that I know that people don't always agree with me on.
Actually, you don't have to agree with me on anything. You will learn most about what you are coming up with when the rubber hits the road and you've got to get it in, get it both built and marketed and in use by people.
So where I just said design isn't one thing, design is a bunch of components, designers aren't one thing, either, and I think that's another mistake we often make, is treating us as if we're all one thing and interchangeable.
And that's actually one of my most challenging issues at work, is teaching people that we have different skills. Guess what, developers aren't interchangeable. You can't just pick up one and go, hey, you know that language.
I'll put you on this project.
Somehow people think they can just pick up a designer and put them on anything.
We have different skills.
I, this is, like, a really, don't worry about the detail on this.
I did just enough to kind of think the concept through. I was thinking about the skills that designers have. There's some of the skills across the top.
Then I was thinking about the kind of knowledge that we get as we build up our career in working different fields.
And there's a lot of it.
So you don't...
This isn't one thing.
So thinking about, you know, people have skills, people have knowledge, people also have a particular mindset that they bring to their work.
And again, these aren't all the facets of mindset. These were enough to think through this idea and communicate it.
So when I'm thinking about how I might staff a project, who might do various things, this is how I think.
I don't think I need a UI designer, a UX designer, a service designer, a content designer.
Content designers are a thing now.
A UI developer.
I don't worry, and that's what I said to John about roles. I don't have a role title.
I'm just a consultant.
There's some hierarchy, but I'm a consultant in a consulting firm.
I had a hell time last year getting work because my CV looks like it has information architecture in it a lot, because I did a lot of information architecture. I'm good at that.
People, like, junior recruiters would look at it and go, "Have you ever done user research?" And I'm like, "Yes, only for 20 years, "on every project I ever did." 'Cause they're skimming role titles.
Role titles are for HR.
They are unrelated to anything the real world actually does. We have skills, knowledge, mindsets, and that's how we should be thinking about how we put people on projects.
So an example of a piece of work that I'm doing right now needs as skills people who, somebody who can do really good facilitation, who can work with teams, who can help them move forward, a good attention to detail, 'cause there's gonna be some detailed work in there, a good ability to tell stories.
Also needs a good understanding of human cognition. With this one I'm kind of taking to market, so what does product strategy work, and for a particular reason, this project needs a really good understanding of organisational culture.
So when thinking about who on my team is good at, for working on this particular piece of work that we have, I'm looking for somebody with those things, not with any kind of title.
Another different one.
You can see this is quite different on the spectrum. There's a piece of work we're doing right now that needs a tonne of amazing storytelling, really good visual design skills, really good art direction skills, and skills in, like, making content.
That's a wholly different kind of work to the one I just showed you, and it needed kind of knowledge, it needed to have a really good understanding of cross-platform.
And in the kind of mindset with this particular one. I showed you the last one.
I had a really pragmatic streak.
This one needed somebody who's a real idealist, who was gonna push the boundaries and throw it open. This one wasn't gonna be me.
This is none of my skills.
If I was on this particular project, I would've taken us down a really boring path. But instead the person who I put on this project came up with something amazing that I can't show you. I can tell you later on when it launches this year. But entirely different set of skills was needed for this one.
A different kind again.
I've got a piece coming up soon that just needs really good interviewing skills, really good research skills, an ability to structure content and interfaces, good research methods, good business strategy, and a good understanding of culture to get something done. You can see those three are quite different. The other thing that you may have noticed is that this person doesn't need to necessarily be called a designer.
The skills involved in some of those pieces of work might come from anywhere.
I was talking to one of our data scientists recently. I was doing some research in-house around how we talk about our skills sets.
And I said to him, like, "What's your best skill?" He said, "Oh, the thing I'm really good at "is finding a problem "and pulling it apart "and really understanding what's going on." And I'm like, "You should work here with us." I didn't say you should be a designer, because, you know, not going there with roles. But there are lots of people who have these kind of skills. Some of us are gonna be super specialist in different areas. Like, I am super specialist in structuring content. I'm really good at kind of communicating complex concepts, even if I can't say the word.
I'm really good at kind of modelling out detail, and I have no ability to do anything visual at all. But some of our developers are gonna be really great at some of those things.
Some of our developers are much stronger at the visual things than I am.
Great.
It doesn't matter what we're called.
It matters that we get the right thing on the right gigs. So...
Now that we can...
Sorry, I was just like, ooh, where was I up to? So now I've talked a bit about, like, what design is. I talked a bit about what designers are.
We can start thinking about how we might go about, like, thinking about the communication piece. And so again, I said I've been interviewing a lot this year, and I'm interviewing quite really senior people who can't tell me what is special about themselves, what they're really good at, what is their design secret sauce, what is their design ninja skill.
They don't understand what it is.
So hopefully, if that's where you are, and you're like, well, I go to work and I do my things, but I don't know what's really special about me. If you don't know what's special about the thing you do, you can't communicate why you should be on a gig. We've had that whole thing about designers needing to get, you know, a seat at the table for years.
If you can't, if you don't know what is amazing about you, you can't possibly communicate it to somebody else so they give you the opportunity to contribute. So think for you about whatever your version of these kind of skills and knowledge set is, as well.
This isn't definitive and correct.
And think about what are you really good at? Where do you fit in this? Where are your gaps, and what is it that you concretely deliver value in? And start, like, spend a bit of time in your own head thinking about that so that you can communicate better what your value is. Think about where your gaps are.
What are you not good at? What are people always asking about? What are they misunderstanding? One of the big gaps I see in the design community generally, and this is just because of where we kind of come from and where our career paths take us, is I think we have a quite profound lack of business understanding.
So when I'm talking to potential clients, I'm always talking to them about the risks in their business, you know, what, where their competition is, how they get their product to market, what they're trying to mitigate.
And when you talk to some business people, not everybody, about managing risk, you've got a different conversation about how the things you do can help them.
So a lot of the things I do, especially if I'm doing strategic kind of work, I'm trying to help people figure out where to go, not just have them run along a path, is all about let's make sure that you're on the right path before you go and build things.
All about risk.
I could get better at this, as well.
I've run businesses, but I'm still not a super strong business consultant, and that's kind of my gap is getting better at that so that I can really help people understand what value I can give them, but also so that I can understand what value I give them, as well, and that's what I'm working on recently.
But think about where your gaps are and whether that's affecting your ability to communicate with other people what your value is. Also think about when, still about communication, think about who are you trying to communicate with? What are they, sorry, who is asking? What do they already know? What knowledge do they come in with? What is their experience of design? Have they only ever worked with designers who focus on a more visual side? Have they only focused, worked with designers who smash out wireframes? You need to understand where their concept is so that you can stretch their concept, but also so that you can attach your experiences to their experience to bridge that gap.
If you're talking to somebody who thinks that design is about visuals, and I have to deal with this one all the time, and you're trying to help them understand that what you can do is help businesses make good decisions about where to go next, those things are never gonna match up.
They're gonna be like, what? How does making things pretty help businesses on what to do? Duh? So you have to think about what they already know and really listen to what they're asking you. So I hear clients come to me with all kinds of problems. Sometimes they don't know where to go next, and that's one that I work on a lot.
Like, got all these ideas.
We don't know where to start.
That's a different kind of skill set and a different kind of work to other kinds. Sometimes they need things to look good.
Sometimes they've got a really solid idea.
They know it's marketable.
They know it's ready to go.
They need somebody to execute the making of screens. And I'm not saying design there, because that's what the word would normally be to leak out my mouth.
Sometimes they wanna check an idea is a good one. Sometimes they don't know about their users at all and what we offer them is research.
And sometimes they're about to implement something brand new and don't know how.
Those things have different answers, and a broad idea of design is amazing isn't going to answer those in concrete terms. So think about what they're asking you.
So as a wrap-up.
Design isn't one concept, and you will not ever nail communicating it as one concept. So think about what those chunks are, go down a level of concreteness, and communicate the concreteness to people, the things that they can understand.
Designers aren't one thing.
We are not the same and we are not interchangeable. Think about what you're amazing at, what your gaps are, and what your value is to the things you do and the things you would like to do.
And listen to who's asking, what do they already know, what do they need to know, so you can figure out how your communications are gonna, you know, connect in their brain.
And that's all.
(audience claps) (percussive music)
