Automated: This presentation is from UX Australia 2015, held in Sydney. For more presentations from this and other conferences, please visit uxaustralia.com.au.
Speaker 2: Again it's my pleasure to introduce Martina. She's from the UK. She's come a long way to talk to us about how to communicate better with each other. Thank you.
Martina Hodges: Thanks so much. Hi guys. I'm really excited to be here. It's such a pleasure. It's my first time in Australia, my first time in Brisbane. I just want to give you a little bit of context when I talk about my context of speaking to users, speaking to stakeholders, speaking to colleagues. I look at it from a European perspective. Maybe not every single pattern is exactly the same, but I'm sure it relates to how you relate to and how you speak to your stakeholders. Now I'm going to share some of my own experiences, some of my own observations of how not to talk to stakeholders. All the mistakes I've been making over the years myself. I do have a co-author, I do have a colleague here I've worked on this topic with. His name is James O'Brien. He can't be here today but I'll be speaking on behalf of both of us.
To get started this is a late afternoon slot. We'll have a little quiz, and then I'll get straight into those AntiPatterns. Ah-hah, this is interesting. Here we go. We will be playing ... Oh no, what's going on? This is not good. We'll be playing That's My Clients from Hell's Line. It's a game show where I ask you, what the hell does that client's line mean? We have three questions, very simple. I show you a piece of feedback from clientsfromhell.net and you tell me what the client is really trying to say. Are we ready for question one? Okay, let's get in it.
We want the design to be intentionally confusing, to show how complicated the concept is. What could they possible be asking for? Travel insurance? Any other ideas? Absolutely, we really want to show how smart we are. So what are they actually trying to tell us? We've conflated complex with confusing, and we really need the design solution that communicates the complexity without sacrificing on usability. So we really need to unpick what they're trying to tell us rather than just going, "Oh my god." I think Dave was saying what the fuck this morning, so it's safe to say in the session, right?
Question number two, let's get ready. Don't use sky blue as a feel good background colour, it's not essential for our users to feel good, they just need to spend money. What could they actually be asking for? We don't value aesthetics, we don't measure feel good? Our KPI is money? Change your background colour. We don't want to distract. Yeah, one way of looking at it is you need to make the case for the link between user satisfaction and profit. To your point about measuring, how does that translate into our KPI?
Question number three. Final question before we get into those AntiPatterns. Our main goal is to get people to sign up to our newsletter, so we need a huge green sign up button in the middle of the page like twitter.com. What are they asking for? Calls for action? You're not amiss on that one. So our KPI is to increased signups, so it's my job, our job to actually sell them a better solution than that button in the middle of a page.
So at the end of that round, final scores are clients 3 and designers 3, because when we understand what our clients want, everybody wins, right? I mentioned this, so everything that ... Yeah, absolutely, right? It's quite a funny one. I do have that sign on my wall just to remind myself that we all really want to get amazing products and amazing services out into the world, but nothing gets out of the building without rounds of feedback, rounds of reviews, and sign off. So really, it's not just how good we are as a designer, how excellent our ideas are, how excellent our design skills are, it's really about learning how to communicate our ideas, our intent, the reasons why we do things with stakeholders and with other team members, so they understand why we're doing what we're doing and what value we're trying to create for the business and for the customer.
I feel that's always a sticking point. I think over the years it's always been interesting, with my best intentions how many mistakes I've made. I just want to share a few of those with you. I've collected 13 of them. In that short three quarters of an hour that we have, I can't dig into all of them. I want to share all of them just to see what resonates with you guys, so you can spot them in the wild, but I'll deep dive into four of those AntiPatterns to show you how to better respond to that and also to spot when you might be experiencing those.
Let's start with language AntiPatterns. Quite simply, speaking different languages. Sometimes it feels like we're all on different planets, we're all speaking on a completely level. It might be easier for us as designers to pick up what other designers are saying, but it might just be confusing if not completely nonsensical to some of our colleagues. So really important for us to be able to communication what we're trying to say with different language as well. I'll dive into that, into more detail.
A second one is not having consistent design language. I find we have a lot of empathy for our users. We're very mindful with the language we use for them that is simple and elegant, that we're mindful of the sign posting to be consistent with our navigation, consistent with our labelling. When it comes to our stakeholders, we don't often extend that same empathy. Quite contrary, I find quite often we're trying to reinvent what we do and find new ways of explaining, like new ways of labelling what we do, and are quite creative and constantly changing. If I can't keep up what my colleagues are doing, I don't know how the people outside of our practise are actually keeping up and understanding what we're trying to tell them.
The third one, we've already mentioned having different KPIs, having different Key Performance Indicators. So it's not just the language we use to describe what we're doing, but it's also how do we actually measure success and how do we actually articulate our goals that are different too? So it's important for us to make time to learn what do other stakeholders want to get out of this product, what does success look like for them, but also be able to articulate to others what it means to be successful as a user experience, as a product or service we're trying to create for customers.
Let's dive into speaking different languages a little bit more. Everyone on a cross-functional team brings different abilities, brings different experience to the team, but they also bring their own dialect, their own specialised language. This gets particularly confusing when different team members have just subtly different language. So you might use the same words but mean different things. You might have overlap by using two different words to mean the same thing. Or thirdly you might just be borrowing a common word and have specialised meaning for your team, but others don't share that understanding. This leads to a lot of confusion, a lot of frustration, and missed expectations for projects. So find ways to actually not just capture what's been said, but also really dig into understanding what's been meant so you're all sharing the same goals and trying to address the same business and user goals.
So how do we know that we're actually experiencing this AntiPattern? I made a neat list for that one. You find yourself suddenly resolving design issues when you realise you're both arguing the same point of the argument. Your answers to questions are met with, "Yes, but," and then just question just rephrased in a slightly different way, so clearly you haven't given an answer that satisfies the other person. Stakeholders start asking design questions of other people instead of you. Maybe the project manager, maybe somebody else. And you might start to struggle finding different ways of explaining what you're trying to communicate when you realise that the words you're using aren't understood by the rest of the team. And finally you know that you've answered that question correctly and it might be quite frustrating, but the terminology you've used just hasn't been understood by your teammates.
So what are better ways to actually respond to the situation? My first pattern for this AntiPattern is stakeholder safari. A fancy way of saying do some contextual research. Quite often we meet our collaborators for the first time in a kickoff meeting. Or we don't really know them very well. Go and find where they live. Actually, go to their desk, spend some time learning about the language they use, the goals they have, the context they work in. At the same time, this is a really great opportunity to build trust in you that you're actually going to respond to that, and perhaps it's an opportunity to explain what you do and how you two can work together better.
The second one is the meeting before and after the meeting. Meetings are a great place for different dialects to crash into each other. So the informal time before and after the meeting is a great opportunity to check for understanding, to double check that other people have really understood what you're trying to get across, or to clarify any confusion. The third pattern is step back. Quite universally practical. We often have this urge to step in straight away with an answer, but really the pattern is all about taking a moment, stepping back for a second, replaying what you've heard, double checking your understanding, and then responding with a more measured response. Best case scenario, you've caught not answering the right question, or not arguing a point that wasn't actually challenged.
The final pattern is play it back. Quite simply, once you think you've understood something, once you've translated into your own understanding and language, play it back to the other person to check that how you've translated it is actually correct. It gives them an opportunity to also either tweak your understanding and also understand how you're using terminology. The second set is presenting AntiPatterns. Presenting without contextualising, pulling that proverbial bunny out of the hat. We'll go into more detail about this one. I just talked to Donna about the second one. Assuming others don't get design.
I think throughout my career, I've been doing this for almost 20 years, there's been this prevailing us and them thinking. Just because we're designers and we're professionally trained, we think only other designers have valid points to make in response to our design. Only they're fit to give us feedback. But our colleagues might not have the same language, they might not have the same experience and training, but they have perfectly valid feedback. They experience good and bad design on a day to day basis. Sometimes they have great ideas and it's great to listen to them. Sometimes it's not always gold. But it's important to understand what's the underlying need that we're trying to address? What's the question that's trying to be asked? Then perhaps taking that design suggestion at face value.
And the third one is throwing deliverables over the fence. I personally hope that we're getting a point where this isn't going to be relevant for much longer. I really care for cross-disciplinary collaboration and all of us working together, but of UXs, we're often asked to create that experience by ourselves, as a design team, document that, lots of annotations. It makes assumptions that our design speaks for itself. It makes the assumption that at this early stage in the process, we already know all the answers. And then we're taking that documentation, we're lobbing it over the fence to the next person in the supply chain to actually create this experience for users.
Now I feel we're really missing an opportunity to actually communicate those ideas, to actually help that person decipher what we're wanting them to do. I've certainly launched quite a few products in the past where I've felt like some time has passed between me finishing that design and handing it over to who knows who's going to develop it, and seeing that thing being launched and wondering, "What happened in the meantime? This has got nothing to do with my initial idea, with my intent for this experience. So I was really hopeful that with more agile, more lean collaborative working practises, we're getting beyond this kind of more waterfall idea of design value is created by handing over that documentation rather than creating the experience itself.
So let's look at presenting without contextualising in a little bit more detail. When James and I have done research on this, one of the main topics that came up is people are really frustrated when stakeholders give feedback in one direction in one session and then immediately contradict themselves the next time you speak to them. I feel while we get frustrated about this experience, everyone who actually responds, everyone who's on your product team has the product's best interest at heart. But what really is at play is a contact imbalance with the design that we create.
Simply meaning, we spend every day with this work. We understand the full context, we understand the background story. We're living it, we're breathing it. But our colleagues might have not seen this for a week or two. They've worked on other aspects of getting this experience to the market, and we need to help them to actually remember what the context of our decision making is. Otherwise it's not a surprise that we're only getting superficial feedback on a superficial feedback on a superficial reading of that design artefact that we're showing them.
So how do we know that we're experiencing this AntiPattern? Again, I've got a neat list for that. Stakeholders give contradictory feedback from one session to the next. Stakeholders only give feedback on superficial readings of your design artefacts. Much of your work seems to be tweaking minor details, but major issues go unresolved and undiscussed. You follow feedback to the letter, but the person who asks it isn't happy with the outcome, with the solution you present. You're spending more time in review sessions correcting misinterpretations of what your design intent is than actually stepping through the work. And finally, stakeholders take the work and present to themselves so you don't have any opportunity at all to help with context, to help answer any questions that might arise.
So how do we better respond to this one? Prepare for presentation. Sounds pretty gnarly, but pretty straightforward, right? Know what story you're going to tell. Have all the artefacts in place to tell that story. Have all the supporting material to help people understand how you've arrived at this solution. Bring in all the artefacts that help them understand what your UX framework is. One interesting suggestion is actually run through the whole story one time first before you ask for feedback. Might be difficult to hold them back, but it's helpful to get that full context first, and in the second step-through actually collect feedback then. Much more productive to see the bigger picture for us before you dive into details. You might miss a solution that you've already created.
Be present to present. I find that in a lot of organisations I work with, they would really like to circulate the things they're going to present before the presentation. So really everyone at their own leisure can step through a deck and what I find challenging is this works really well when you're all subject matter experts. When you all know how to read the artefacts. But if you're working in a cross-disciplinary team, it's a lot more challenging, and it's really you being there to help gauge understanding, to help clarify context, to help answer questions. That really helps the entire team understand the context better. This can be particularly challenging if you're in an agency situation, because really your client is paying for those artefacts, and if you're telling them, "Actually, you can't have them, you can only have me presenting them," that's an interesting challenge to overcome and explain why it's so valuable that you're there to explain.
Casting feedback. We touched on this earlier. Casting feedback is all about not all feedback is immediately usable, like our first three questions that we saw earlier. But it's really about understanding ... So if I'm getting helpful suggestions for features and improvements, perhaps I need to understand what is the question that's being asked? What is the underlying need that's not being met? Rather than taking those design requests at face value. So document what the question is. The next time you're playing back how you solved that problem, really frame it with here's where we were before, this is the feedback you gave me, and this is how I arrived at the solution. This really helps this notion of getting this flip flop feedback, really mitigating against this, oh this time it's this way around and next time I'm going to say something else entirely.
Set scope expectations. Quite simply, explain which areas of the design are ready for feedback and which ones aren't ready yet. It's important that everyone knows what's a parameter for what can be discussed, and what's not ready yet, why should we pick holes in it when we haven't thought it through yet. And finally, actively confirm. It's okay to ask whether you've been clear with everything you've presented. Phrase it in such a way that it feels okay for stakeholders to admit that they needed a little bit more help in understanding what you mean. Thirdly, work and practise AntiPatterns. Being in the room but not present. It's not just the silos in the organisation, but sometimes the walls we build around ourselves start to become a real challenge. I dive into that a little bit more in a moment.
Insisting on perfection. This is an AntiPattern I'm challenged with myself. I find it really hard to not just want to spend that little bit more time just add a little bit more flourish, add a little bit more polish, have a little bit more time before I feel like I'm done and I want to share what I made with other people. Quite frankly, without inviting feedback early and often, I'm introducing risk, I'm introducing waste. I don't know whether I'm [noodling 00:20:34] on the right design solution at all. Whenever I remind myself, whenever I get stuck on this particular AntiPattern, I remind myself that if I haven't shared this and I'm embarrassed about the first version I'm sharing, I've waited too long to get feedback from others on that.
Not embracing everybody's goals. Now on the surface you might be moving along nicely with a project, but if you're not truly embracing all the goals that other stakeholders have, we spoke about having different KPIs, different measures of success. If you're begrudgingly squeezing a feature in or if you're thinking that it's really superfluous or frustrating to try and shoehorn that other request in, you're really eroding the trust that your stakeholder has in you. You're setting yourself up for a much more challenging working relationship. So it's important to truly embrace what other people need from a product or experience and be helpful and collaborate on this together.
The final one is living in the deliverables. I already mentioned throwing deliverables over the fence. Now, spending your time actually perfecting those deliverables, focusing your value as a UX that you're creating on that deliverable that you're handing over to somebody else, instead of using your artefacts as learning opportunities, as conversation starters, with users, with other stakeholders, with team members, you're really focusing your time on the wrong effort. How beautiful that deliverable is isn't really the same thing as actually creating an amazing experience that you deliver into the hands of your users.
It's a bit like being in the room but not present. It seems a little bit of an oxymoron. Because what we're really saying is, the thing that really helps bring the product forward, the thing that helps you solve ongoing challenges, ongoing questions among the team is actually being present, is actually hearing what their question is, it's actually hearing what they have to say. Now, quite often, when we're busy, when we want to focus, when we actually want to do our best job, we put our headphones on to focus and be shut away from the rest of the team.
So it's really that kind of silo I'm talking about. A lot less silos that we're creating in large organisations. It's really about this distraction that we feel from the chatter that's really important to improving the experience. Being there with your point of view to jump in and answer questions. As we become more collaborative with our working practises, people look to us a lot more to actually facilitate the design process and have everyone involved in it. We really can't afford to shut ourselves off from the process so much.
So how do you know you're actually stuck in this AntiPattern? You'll notice that decisions are being made without you, but you feel like you should have had a voice in it. You're uncomfortable and concerned about the direction of the project from one meeting to the next, but you've not made yourself available to actually participate in the conversation that steers the product in between those meetings. And you spend the majority of your time tucked away to focus. That could be setting up residence in the local coffee shop, having your headphones on all the time and not hearing what's going on around you. Working from home a lot or just hiding in a quiet corner in the office where no one can talk to you.
So how do we better respond to this one? Push for in-person access. Now, trying to get consensus, trying to make decisions on email-based or text-based communication channels. It's really challenging. People skip over your reasoning, people misunderstand and misinterpret what you're trying to say. Find a way to actually have a voice conversation. If you can't jump into the room together, perhaps find a way to have a voice or a video call. Once you've made those decisions, it's a fine idea to actually capture those in email and circulate them. That's what this medium is a lot better at.
Life in mono. I can't mention this often enough. If you like music, if you want to have your own working style, try only using one headphone at a time. Try and find a way to still be able to absorb what's going on around you, the questions your colleagues have. The third one is a stenographer's pattern. It's super simple and really effective. I'll borrow a table. Quite simply, court stenographers have a really intense job of listening to tapes and actually writing notes. So interrupting them in their workflow can be really unproductive, can be really ... They lose their flow, they lose their point in the tape, it's really frustrating. So what their colleagues do, they simply place a hand at the field of their vision, at the side of the desk, and wait. They wait until there's a natural stopping point, when it's a good point to actually pause and actually start a conversation.
The final one is a scary face pattern. I've encountered this one in design agencies. Simply what people did to carve out quiet time, carve out focus time is take photos of themselves pulling a really scary face, laminate that thing and actually put it up on your monitor when you just need your five minutes or an hour. I know this is open to abuse and I don't mean you put that thing up first thing in the morning and you leave it there all day and don't have time for other people. But if you need to carve out small amounts of focus time. Find ways of doing that. Perhaps it's in the actual work space. Perhaps it's with these kinds of patterns to help you focus but be available.
We're on the final batch. Thanks for following through with me. The first one of those is responding to tone and not content. As a English as a second language speaker, I always had this sort of feeling that people felt if they just shout louder at me in English I'll understand it better. That's not what I mean. Also, it's not about heated debates, heated arguments, having a row. Even very, very simple ways of changing your intonation of stressing one word over another in a sentence can completely change how people interpret what you're saying.
Again, I'm actually German. I know I have no sense of humour, but also when I moved to the UK it was actually really hard. People thought I was being aggressive, I was being rude, but what I was doing was just ... German is a very direct language ... Absolutely. And for English ears that was really rude. It was just unbelievable how direct I was with my questions and how could I possibly say that? So it's subtle, simple things like that. It's not just being aggressive and that's never okay in the workplace, but try and be mindful of how others might receive the message you're trying to get across. I invite all of us to be a little bit mindful about that.
The next one is defending too hard. You know that situation when you're arguing a point and you're just arguing for the sake of winning the argument and sticking to your guns, and it's not really about improving the customer experience, but you feel like, "No, it's my idea and I want to stick with that." I've learnt over time that we're naturally predisposed to loving our own ideas. I think Dave made a really good point this morning about we all have our own bubble, our own belief system. It can be really difficult to be objective about that. But I'd like all of us to be a little bit mindful about at what point are we arguing because we love what we think and when are we actually pushing for a better customer experience for more value, we're creating for the business and the user?
Having said all that, my 13th AntiPattern is not defending hard enough. We have so many opportunities to improve how we communicate, how we listen, how we collaborate, and how we emphasise with our fellow coworkers. But we're the user champions. We care about improving their lives. We don't do our job properly if we don't make a great case for their delight and their satisfaction. It's really important to be a great collaborator, to cooperate with your product team, to actually work well together. We can't just bulldoze our ideas through at all times. But we're not doing our job properly if we're not making a great case for a great user experience, when we don't know which points should we actually argue for? Which points are really critical in creating an amazing product or service?
And it's really important to also make sure that decisions are made for the right reasons, that priorities are based on clear user feedback, not just business goals. We really need to bring those two things together. We demonstrate how we're delivering business value, and we're also weighing up the cost of a poor customer experience in comparison to other business metrics. So how do you know that you're actually stuck in this particular AntiPattern? Perhaps everyone seems happy with the progress the project is making, but no one, especially not you, is particular with the quality of the experience. You feel like you're conceding ground a lot of the time even if it's detrimental to the user experience. And perhaps you get feedback that you should be a little more assertive or that you take more ownership of the UX.
So very briefly, how can we improve on that? How can we work on that? This is really about bringing your whole UX arsenal out, your whole user-centered design toolkit out. But if necessary, find ways to educate the rest of your team about what value you're bringing, what value it brings to understand what problem you're solving for the user, and who that user is. [inaudible 00:31:08], I think very simply if we go into any feedback, understand and be very clear about which areas of the experience are a must, a should, a could, or a would, so you know where you can be flexible and where you really need to stick to your guns.
Be prepared to tell a story for every part of the experience. It needs to have a beginning, a middle, and an end like every good story. The beginning is really explaining what business goal, what business problem you're solving. The middle is your insight, your user insight, what have you learned? What are you trying to address? What strategy have you devised to solve this problem? And the end is really your design solution. How you've actually acted on that opportunity. Tying together what you're showing to them, tying together the design solution with a business need is really helpful in other people understanding what value you're creating.
And finally [inaudible 00:32:07] elastic user. I'm pretty sure we've all experienced this before. A lot of stakeholders have two mental models of users. They're either like themselves and know everything, or they just don't give them enough credit for what they're actually able to do. So there's this absolute novice who doesn't know how to do basic things on the web. Helping without all our tools around personas, insights we've derived from speaking to customers, keeping those fresh, updating that when we know more about them, tying every design element to the persona we're actually serving with that. Perhaps making a 2x2 grid of high business value versus high user value to help the team understand and prioritise different aspects of the experience. I find concrete ways for the team to actually prioritise, understand what value you're bringing, and not just deprioritized the whole experience aspect.
I did leave 10 minutes for questions. Thank you so much for listening. If you're interested in this topic, I did write a book about it. I have three copies to give away. A lot more patterns, this was really a whistle stop tour of the bare bones. I'd love to share more and I'd love to collect more of your patterns of how to actually talk to stakeholders. Thank you.
Speaker 2: Thank you. Okay. If you want to ask a question, you'll get a book. First three people. First stand up.
Speaker 4: Hi there. So how do you find that people take these AntiPatterns? Do they object to them, "I don't do that sort of thing," or do they embrace them or do they say, "Oh, that's some of me and that's some of my colleague," or is there a bit of a universal way you see it when you introduce these AntiPatterns to people?
Martina Hodges: I think there's a lot of, "Oh shit, I do that all the time." It's usually the response. Excuse my swearing, I do apologise. But quite often it's recognition and less often it's, "Oh, no, that's what other people do but not me." But I find yes, it's interesting how people react to it. It's a really good question. What would you expect? There's always a few of those, right?
Speaker 2: I'll run that up, [Bill Franco 00:34:36] asks.
Martina Hodges: Thank you.
Speaker 5: Hi. So the first step is obviously recognising that you're falling into one of those AntiPatterns. Have you found ways to go after that? How do you change behaviour, how do you change your team's behaviour or yourselves? [inaudible 00:34:54] do yourself?
Martina Hodges: Yeah, absolutely, and I think I was trying to cut out that whole angle, is I truly believe in cross-disciplinary teams who work together from beginning all the way through to delivering a product, rather than this piecemeal aspect of I'm the designer and my part of the process is quite compartmentalised. I feel actually collaborating all the time with all stakeholders actually, you have to address all of these issues all of the time. You can't hide behind, "Oh, I don't do that, or I do it this way." You really have to bring 100% of wanting to collaborate with other people and actually getting over some of these unsuccessful ways of actually working with each other. If you do that every day, it just doesn't work. No one wants to work with you.
Speaker 6: So when you've got a team of UXs and you've got some rookies in your team, how do you start this conversation with them and develop their awareness of this? I guess if you hit them with 13 or 50 of these in one go, it's a lot to digest. So how do you bring people along on the journey?
Martina Hodges: No, absolutely, what I do is I actually pair them up with other designers, or other people in the team. We all work on product teams together, so they actually absorb how we're actually working these things out in positive ways rather than in these unsuccessful or perhaps also confrontational ways. It's much easier than saying, "Here's a list. Go and cram and I'll have a test at the end." But yeah, I feel like just absorbing it when other people naturally work in that way is really helpful.
Speaker 2: We do have time for other questions of course, just pass you that. Just out of books.
Speaker 7: So when you were talking about the AntiPattern where you're kind of working and people are not including you in the decisions and that kind of thing, and it's happening repeatedly. How do you get around that, because ... Do you have anymore tips on how you would get past that?
Martina Hodges: I find, and it doesn't have to be this particular constellation, right? If other people make decisions without you, I want to understand when do they make them, who makes those, and how can I invite myself to that to participate in that? So it's really about figuring out how can I insert myself into the process. Does that make sense?
Speaker 8: Just a question around organisational AntiPatterns, because you're mostly talking about individuals or even in collaborative groups or teams. Some of these I could see a point to organisations. How do you break those down?
Martina Hodges: Much harder. I think Dave made a really point for that this morning. I believe it's difficult when the organisation incentivizes certain behaviour, and actually getting around that I tend to start small, in a small group of people. Maybe in a product team and actually build it out from there. Demonstrate, if you incentivize different behaviour, how you can be successful perhaps in a better way. But yeah. It's not a top down or tomorrow we're starting to do something different, and this is how we're going to do it. I feel it's really a grassroots thing of trying something else out. I'm perhaps under the radar.
Speaker 9: Thanks, that was a really lovely presentation. There's so much to unpack from all of that. I was just wondering, two things, one, which of those patterns did you find really useful for yourself? Like did you have a breakthrough that you can share? I know you talked about responding to tone thing, but I was wondering if there was another one that was a bit more of ah-hah moment for you. The other thing was, if there was one basic thing that all of us could improve on that you'd like to see other designers pick up and go with, I know you did 13 and there are lots more, but if you could wish one thing for all of us to do, what would it be?
Martina Hodges: I love that question. Actually, to be really honest, I hadn't asked that of myself. I'm certainly classically trained graphic designer. I went to one of the, I would say snobbish design schools, and one of the designers when I came back for a school visit had made this piece of art saying, "Central St Martin's pretentious little shits." Excuse me, more swearing, but encapsulating that whole kind of attitude of, "Oh, we're design school folks, so we have an attitude that we're more special, we're different, we have better ideas, we're just fabulous at solving design problems." I feel getting over that notion that as a designer I am special in creating products and services, not a peer-to-peer collaborator. I think that was a massive way of change for my work. It happened a long, long time ago, but I feel I see a lot of designers come out of school or perhaps out of different work environments where that is incentivized rather than tempered.
It's kind of frustrating to think that we're the only ones who come up with great ideas. Maybe that's actually the same answer for everybody else. I think it's nice to understand that collaboration actually makes better things and I really care about inviting everyone into that as a peer.
Speaker 2: Thank you very much. That was really great.
Automated: We hope you liked this presentation from UX Australia 2015. For more presentations from this and other conferences, please visit uxaustralia.com.au
