 Hello, everyone. It's quarter to 12. There's a big clock up there. I love going after everybody because then I can refer back to what everybody says. We are all talking about the same thing. So what you're going to hear from me is stuff that Marcus said, that Jennifer said, that Liam just said, and I particularly like being back-to-back with Liam because we talk about the same thing. I just put a different slant on it. He's got these lovely frameworks and I'm a little more loosey-goosey. Anyway, as they introduced me, I am Sarah Bloomer. I've been working in the field for about 25 years in Australia, New York, Boston, all over the place. I last came here in 2006 and there weren't as many people at the conference so it's really nice to see so many people and what's going on now in India in the UX field. One of the things that's unique about my background is that in Australia I didn't work with software companies. All of my experience is what I call internal software design so I think I developed a unique perspective on developing software because what we were doing was helping companies to basically design their businesses by the way that they design their systems and that informs the way that I think about user experience design and the way that I think about user experience teams. I've ended up helping companies in Australia establish what we then called in the 90s their usability teams and I took that knowledge and have applied it across to other teams in the States and I guess get asked to help put teams together and optimize teams and that sort of thing. I want to talk about changing the UX mindset and it's basically similar to our analogous to what Liam was talking about in terms of how to gain influence in your organization. I've had a lot of interesting conversations with you guys about problems that people are having in terms of getting themselves recognized and used properly as UX designers within your organization. So I'm going to try to talk about that. There's three, let me get rid of that little box over here. Go away. There we go. Three topics that I'll be focusing on. One is culture. I talk about that a lot. Another is collaboration and the third is capability maturity or what we more commonly refer to now as UX maturity. So when you want to move up the maturity model and there are lots of UX maturity models out there on the web that you can find, this is a really simple one that I like that was developed in 1994 but still a really useful model for thinking about how to gain influence in your organization. And the thing is that we tend to forget that when you're asking to gain more influence you're actually involved in a change. So we tend to battle for acceptance and get really frustrated and annoyed and pissed off when people don't realize how valuable we are or not being used properly. What I want to encourage you to do is to not battle and fight for acceptance but to get strategic about how you go about that. So for example, if you're at the bottom of the list here at skepticism, there we go, that means that let's say you've been hired because your boss thought, well, all these other companies have UX so I better get one too. But they really don't know how to use you so you're not being used properly. If you're at that point, you really want to build up curiosity and there's a few ways to build up curiosity. You can do that by finding something really strategic that's in your product that needs to be changed and don't wait for somebody to ask you to change it but start to propose what could be done better. So you could create prototypes like Liam was talking about to demonstrate that or you could just pick something really simple. So I heard one story on Wednesday from somebody talking about an icon that he knew wasn't quite right for their end users but the developers were all convinced it was fine. So he took that, went out and did some evaluations with customers and then was able to come back and prove to the developers that he had a better solution and that way he starts to build credibility and his abilities as a designer and also to build curiosity. Like if he got that right, what else can he do for me? So you want to start to build that kind of curiosity and then if you're at the curiosity level, then you should be looking ahead in order to improve your influence by gaining more acceptance. So now perhaps you're working with one team and you want to demonstrate the sorts of things that you've done so that you can get into other teams as well. So that's true whether you are a UX team of more than one or a UX practitioner of one and I think this is particularly relevant for a UX team of one and I've talked to a number of you about how frustrated you are at not being accepted better into your organization. A lot of the things that Liam talked about and Mark talked about and Jennifer talked about are you can't be scared. You've got to be confident in your abilities and your ability to be a designer. I think a lot of people feel like, well, I've heard this story many times. They just asked me to do wireframes. I give them the wireframes and then they say, that's not right and they throw it out and do their own thing. How many people have had that experience? Yeah, look at that. Lots and lots of you. So you're all trying to sort of get some credibility with your organizations and I'm going to talk a little bit more about how to do that. But the main thing isn't to get mad. It's to do some of the things that we've all talked about, which is to build a collaborative relationship with the people that you're working with. Now, partnership not a lot of companies have achieved that. Who here feels like they're at that level of maturity in your organization? We got a few. Okay, that's good. So a lot of times when people talk to us about how to build up influence in an organization, the first thing they say is you need an executive sponsor. But what I'm trying to say is there are better ways or there are other ways to do it, that an executive sponsor doesn't always do it. Another typical one is invite everybody to your usability testing and then they'll understand how important you are. These are both good, but there are other ways that you can go about building influence in your organization. The main thing is, and I've been talking about this for about 20 years now, is we tend to get on the soapbox because we know how important we are to an organization. Liam talked a lot about that. But we tend to get on the soapbox and yell at people and tell them that we're important. So you want to get off your soapbox and start to get more strategic. We also tend to get busy with UX because I don't know about you, but as a designer, I like nothing better than a good solid design problem and then putting my head down and working on it. So we get into that design problem, we try to solve it, and we leave everyone else out. So that is not a good way to go when you're trying to build relationships in a company. So I often said to people when they say these developers don't listen to me, you've got to find ways to engage them with you. You have to build a collaborative relationship with them. And there you want to understand, I think Liam gave a good free framework for it. But what are the things that they're being measured on? What's important to them? How can you make them look better? That's like the form policy idea. So you want to go and learn more about them. And I'm going to talk about more of that in a minute. So the point is that you need to look outside yourself and outside your own little world. I told you I was going to say a lot of the same things everyone else has. You want to work with the colleagues and the stakeholders and identify who they are. And sometimes they're not always obvious. There are other allies and colleagues that you could be working with. You want to build awareness about what you're doing. And I'm going to talk more about ways to do that. You want to negotiate what your role is. Back in the 90s, I used to say to people, if people don't understand what it is you do, and back then we called it usability or user centered design, then find something that's similar to what you're doing and call yourself that. So there were two big initiatives in the 90s in Australia. One was continuous improvement, where they were trying to make the workplace a better place to work. And there were lots of techniques that we could apply in order to achieve that and help the continuous improvement initiatives be successful. So that was one way that we would do it. Another one was total quality management. So we would just say we're total quality management people and we can bring our techniques and help you succeed at total quality management. And that way we could demonstrate our techniques without people saying I don't know what this usability thing is. You know, I can't, I don't need you because you do something I don't understand. A lot of our techniques are transferable to lots of different areas. So if you're trying to build that credibility and build relationships, figure out what's important and then step into that and adapt. So UX, as many of us have said already, is just a part of a whole. And there's lots of ways that we can help people. We tend to talk about knowing about development, you know, the development process that we're using, the coding constraints, we have techniques that we use and a design process that we use. But that's, that's when we're being, you know, naval gazing and we're only focusing on our own team as if we're this isolated team. But in fact, we need to be working across the organization. So very often, as Mark was saying, we have to demonstrate leadership. So and we have to manage people and we have to manage up and we have to manage down. I'll talk more about that in a minute. But those are really essential qualities that whether you like it or not, even if you're being a quiet leader, a leader doesn't mean standing out in front. I often talk about my leadership style as sort of being the prompter, the person making everyone else look good. Sometimes that's called the servant leader. So leadership means sort of finding ways to take your company where it wants to go, take your team where it wants to go. There's a lot of soft skills that we forget that we need. And one of the most important soft skills is communication. Because we're trying to communicate on behalf of our users, we're trying to communicate our design and the rationale behind our design. We're trying to communicate to users when we research with them and up to management and to the stakeholders. So communication is really important. And when I had my consulting business in Australia, when we interviewed people, I made people do a writing test, which was not very popular, or a writing sample rather, because they had to be good communicators and that was one of the only ways I could see if they had communication skills. So you need that for promoting UX, but you also need it just to do your job. Sometimes you need domain expertise depending on what the application is that you're working on. So depending on where you are, you need to develop that domain expertise. But I was talking to somebody the other day and saying, the beauty about UX is that our skills are transferable across domains. So it doesn't mean that once you have that domain expertise, you have to only work in that area. And then other skills like writing, facilitation, which I think is becoming more and more important. I run a lot of workshops. I think a lot of you heard about different types of workshops in the workshops that we taught you this over the last couple of days. And so facilitation is just becoming really critical. Of course, communication is part of that as well. And then divergent thinking. So we've been talking about the need to come up with multiple ideas. Liam talked about that, being able to not just think about the obvious solutions, but being bold and trying to look beyond the obvious solutions. That's really hard. And obviously, in Agile, as we know, it's really hard in corporations when you're trying to be divergent and people want you to just meet a deadline. But you still want to try to do that as much as possible, sometimes in the smallest possible way. So there was this study done by a woman named Mia Northrup in Australia, which I really like. She went out and ran a survey asking people what soft skills she thought they thought UXers should have. And this was the list that came from UX people. But she also sent it to product managers and project managers and other types of people to see if there were any other types of skills that they thought we should have. So here we've got creative thinking, communication, problem solving, things that you would expect that a UX practitioner needs to have. But UXers added facilitation. So these soft skills were shared by everybody. Senior managers added critiquing and consensus building. So again, making sure that you're going out and working across multiple teams. Because one of the unique aspects of being a UX person is that often we work on multiple teams. We've got our UX team and then we've got the product teams. You may be working with one. You may be working with several. And so we're constantly going into multiple teams and having to consensus build in those teams. Product managers want you to build trust, do client management and negotiation. And I think that one of the reasons that's there is because we have to negotiate with product managers. I'm sure you've all had that experience where you're fighting over ownership of the UI with your product manager, who owns it, who gets to decide what we do. So being able to facilitate that discussion and negotiate, again, is really important. You don't fight them. You find ways to work with them. So the most important thing, the biggest stumbling block I think we forget about is corporate culture. That is, if you're aware of what your corporate culture is when you're trying to build influence, then you can go into that and build influence with your eyes open. So I want to talk about this a little bit. Before I talk about corporate culture, I want to make the point that not all companies are the same. And as I said, I had this unique experience back in the 90s where most of my clients were telcos, insurance companies, banks, government. They weren't software companies. And so I would come over to the States and I would, people would only be talking about software companies and they were using language I didn't understand, like ship date. I mean, we don't talk that way anymore now that we work in a continuous development cycle. But we did launch date and then after you did a launch date, you went into a maintenance phase and that was different than what happened in a software company. So I think that, and I learned when I moved over here, sorry, moved to the States, instead of working for software companies, just how different they were. So in a software company, software is the business. So that's all you're doing is developing software. But when you work in an enterprise, which I'm using really broadly, software is built or used to support a business. So we put UX people working on enterprise systems like a CRM system. We're not building our own, but we're making sure we're implementing it in a way that works for the business. But a lot of times people have home grown applications as well. And a lot of times today people have websites and web applications that they use to run their business and interact with their customers. So that may be shared between the software company and the enterprise company. And then in a creative agency, of course, you're supporting or working with those other organizations to help them design their software. So for example, I run the survey every two years asking UX teams to tell me about themselves to see what the commonalities are worldwide. And when you ask people what the most important element that makes them successful of a software and an enterprise company, they say having a senior corporate sponsor. But that's not true with a creative agency. They say the most important thing is having the right skills. So there are different weights and different important elements for a UX team depending on the type of company you are. The other thing that makes it unique is that you're going to have products and teams and you're going to have processes and that's going to be different. You're going to have the business goals and drivers that surround all of that. So the company, and we tend to forget this. We again get so focused on what we're designing that we forget that we're building a product for a business that has a particular set of goals. And so it's really important that you put your head up and understand where the company is trying to go and why you're building what you're building. And there are also a set of constraints. So for example, the who? If you're a team of one and how many people are you are UX team of one in their organization? Oh, not as many as I thought. Maybe about a fifth of you. Versus being on a big team. Who might be a team that works together or a team that's distributed globally? All of those things are going to cause certain constraints about what you do. And then when is how much time do you have to build something? Are you working in an agile environment with two-week sprints which is going to be different than if you're working on longer development cycles. And that's going to influence what you can do and how you do it. But then around all of that is this this thing called the corporate culture. So a culture is something that drives the values and norms that drive actions. And what that means is the behavior of the people that you're working with is going to be driven by the values and norms that your company holds. Kim Goodwin talks about this in her leading UX talk. And she says that cultures that deliver great experiences are adaptive, they accept risk, they accept failure. Failure is a really important part of design thinking and it's an important aspect of innovation as well. You can't be innovative unless you can try stuff out and fail a few times. A lot of corporations don't allow that and that could be part of your corporate culture. It's committed to quality, it's willing to prioritize and it's other focused meaning it's the team isn't focusing just on itself but on everything around it. I did change one word and what Kim says here which is the word deliver. She says cultures that ship great experiences and again I see that is taking a software perspective rather than an in-house development perspective and I think that's an important differentiation to make but I think this is also true it's just harder in in-house development to do some of these things because it's like the shoemaker's daughter. You know people don't spend as much effort and time and money on in-house development as they do on their products. So sometimes companies have something they call corporate values. How many people are in a company that has a set of values that they've printed out? So a bunch of you right mostly the big companies right so here's Zappos. These are usually aspirational like we want to deliver Zappos is an online shoe company you probably all know I tried to pick one people would know but wouldn't be in the room is anyone here from Zappos? Okay I succeeded. So we want to deliver wow through service we want to embrace and drive change we want to create fun and a little weirdness so you know that's a way of talking to the people that you want to hire we want to be adventurous creative and open-minded so I would want to go in there and see if these things actually exist. An example where people a company that did not follow its corporate values was Enron if those of you know who Enron was you know they're they're out of business now because they were taking money that they were they they put their prices too high for their customers but one of their values was integrity and doing the right thing by their customers and so if you read their values and then look at their behaviors they were miles apart so you want to look at whether the actual company values are in fact the behaviors and attitudes of the fellow employees whether people actually live those values or not and if they don't that's going to tell you a lot about what you're dealing with so the way that I go about learning about values is I look for myths and values so here's a myth myths are beliefs that reveal the values so here's one. Users don't know what they want so we can design for ourselves so that might be a myth that you know exists in your company so what's the value that goes with that well the value is that you know users are stupid and they don't know anything so if that's the value in the myth that's in your organization and you're having trouble doing customer research now you know why you have to change the myth in order to be able to do your customer research instead of fighting all the time so for example we talked about this in my workshop and I said if you can't go do customer research find other sources go and talk to your customer support group go and talk to the sales group go and talk to any group that's customer facing learn about the customers and use that to start to build up a sense that the users aren't stupid so that you can start to shift those myths and values instead of so you're not fighting anymore you're getting strategic and finding other ways to shift somebody's perception and shift the culture another angle on culture that I learned from Paul Sherman is is to think about it as design centric or engineering centric or sales and marketing centric so and I'm oversimplifying here but if it's design centric the creative they take a very creative approach to design and they tend to design for other designers and sometimes that means that they're talking about just visual design because I always object when people refer to design and assume it's visual design because I'm a designer I'm not a visual designer but I'm a problem solver and I'm a designer but you have if you know that that's true of your organization then where I've had problems working in that type of a culture is I'll do my wireframe I'll even test it in a paper prototype and then I'll hand it off to a visual designer and they rearrange everything on the page because it didn't balance out well visually so I need to sit down and start to to work with them and collaborate with them so they understand why I made those decisions why I located things in turn certain parts of the page when I'm doing web design if you're engineering centric which a lot of our organizations are it's technology driven and that's where often the people with the power are the developers and they'll make the final decisions they've always used own the user interface it doesn't mean that they want to do that because a lot of times they'd much rather be coming up with clever code but they've always owned it and so again you need to create a partnership with them rather than looking at designers you need to to create a partnership with engineers in a way that makes sense to them and finally sales and marketing my experience has been that they tend to think they know the users better than I do that that they can just give me the demographics and the market research and I'll be able to just go from there so I will often take sales and marketing people well not sales people but usually marketing people on field studies with me or I'll try to compliment any market research traditional market research that they're doing so when I was director of user experience at constant contact what we did was build up a relationship I would go and find out what market research they were working on and I would do complimentary field research and we would present our findings together to teach the rest of the organization about their customers so again aligned with Liam I think we need to use our own techniques to go and find out more about our organizations and here are three ways that you can do it you can do field studies which is going out and actually treating your coworkers like the way you would do field studies or customer research on your customers you can do personas and I'm going to show you examples of each of these and you can use rich pictures which some of you may not have heard about before so with field studies you really want to go out and get to know the teams that you're working with and all the stakeholders you need to figure out what their pain points are and understand what their goals and their beliefs are so this is a good way to find out about the company culture one way that I really like to do that is to get them to tell me stories you know tell me about a successful project how did that work and if there's an existing user experience team tell me about working with the user experience team and that way you start to identify their beliefs their myths their pain points and start to understand how you can shift that relationship if it's not if it's not working well it may be working fine another technique I use is I have a bunch of cards where I've pre-printed myths and values that I've collected over the years I actually have four sets I have barriers opportunities myths and values and I get we play this game where I get them to sort through the cards and pull out their top five and that way we very very rapidly identify what the corporate culture is and from there start to identify what techniques will be acceptable and not acceptable within that particular culture so another popular way or way that UX people are starting to make a shift in the corporate culture is to be the product owner so you know with customer research we often talk about going out and being the customer so that you get that direct experience so if you can be the product owner then you're gonna understand what they're dealing with and being able to feed that back to the UX team so using your own techniques that we already know how to do within our own company so my friend Jen Fabrizzi went and talked about and the company she worked for then was Mass Mutual and they were doing an innovation initiative so she went did this sort of thing and developed personas of her colleagues because she wanted to understand the work of the UX practitioners and to understand what their pain points were and what was working for them so you're not just gonna say well my team is perfect but I need to figure out how to work with everybody else now you're looking within your own team and figuring out what makes the members of your team tick and what works for them so she's got this sample persona of a UX practitioner and it's you know basically representing their pain points their motivations the kind of scenarios in terms of how they're working because by by doing that and she had other stuff too but they describe examples of somebody working with other people in the organization so that she can identify the pain points and start to say okay here are the stakeholders that we need to smooth out and build better relationships with by identifying it and thinking about it from the perspective of team members and then the last one Jen used is something called a rich picture which is kind of like serves a similar purpose of a customer journey map but a customer journey map tends to have a beginning a middle and an end in terms of a relationship that you have whereas the way we work is it's a little messier and a little more chaotic and what she's trying to do here is is reason about work this was actually written up in interactions magazine which was a really great magazine that no longer exists in 1998 but you see it's trying to capture the emotions of the experience so you know I've got a block for my team I don't know what they want you know will it be on time and on budget so the sorts of things that they're trying to find out and understand are where are the where are the pain points in the overall system that we need to address so this is actually online you can get this if you just do a search on Rich Picture and Monk and Howard you can you can find the article about this if you're interested in it but again this is taking a systems approach to thinking about the UX teams relationship in an organization I have no idea how I'm doing for time how am I doing for time okay so I have more than two minutes stuff similar again to Liam's thing this is something else Jen created in order to help people in her organization understand how UX fit with the greater within the greater organization trying to communicate the reach and the sorts of things that UX does so my final tips are be a leader to drive change communicate all the time keep a learner's mind and I think that's something that Mark really addressed nicely building trust in all directions so you're not just building trust within your own team you're building trust across all those boundaries because that's what we do is UX people we are influencing the entire organization you want to give credit where it's due so again it may be due to somebody outside your UX team or within the UX team and then staying out of the weeds I know a lot of UX managers who hate leaving behind design so they continue to do design themselves but you actually need to be looking out as a as a leader and a manager so value your team make time to mentor and coach and shut up and listen so that's sort of my list of what it takes to be a good UX manager and leader again collaborate in all directions so this is again repeating what I've already said but you need to be talking to adjacent teams and colleagues so you may have allied teams and beneficiaries I think of people like customer service as being a beneficiary of UX sometimes they're just overwhelmed with the amount of calls they're getting you go over to them and say what are your biggest issues let me see if I can get that on my roadmap and fix them and they become your ally another way to communicate your value adjacent teams might be your QA team so you're not working directly with them but they can become they can become part of your team indirectly so at constant contact I used QA because I didn't have a big enough team to do user experience QA so I got them to do the user experience QA for us your own team and of course upper management and other stakeholders and then building communities of practice Liam brought this up too but this is one of the ways that so I'm listing here he was saying who else is going to be interested in the sorts of things that you do who could benefit from what you do like building the prototypes for sales to use to show to customers well this is a similar idea customer facing experience you might get this group of people together to learn about customers so that everybody benefits from that we've been doing that with one of my current clients getting people together regularly saying what are the top top three things you know about our customers and sharing that with each other because otherwise we're all in these little silos talking to the same people product strategy might be one customer research so here's where I was telling you about what I did a constant contact with market research is what we were basically doing was sharing our research and integrating our research with each other so finally if you want to start to influence the organization more and move your team up the maturity model you need to start by learning about your culture as I said earlier you need to design your team so that it fits within that culture and then you want to be be a leader and this just summarizes everything I just said in the presentation and it's not going to happen overnight here's another version of the UX maturity model you know the earlier one only had four steps and this one's got six but I you know it talks about it as being unrecognized and it has it at the top is being embedded which is sort of like the innovation example that Liam showed you know whereas if you're embedded then you've filled that circle and so you're not going to get there right away we always talk in a lot of my companies now that I work with about taking little baby steps and you have to remember that it's going to take time to create that change and to build that influence and to be very tactical and strategic about it thank you