 So I am here to talk to you today about empathy in the enterprise and what that really means is how human technology and actually organizations come together to create big messy website problems. So to give you a little bit of information about me, my name is Dan Gordon. I may have met some of you already. I am the director of user experience on the digital team at PEGA Systems. We basically manage all of the organizations' global website. This completely adorable girl right here is the other way that I spent my time. What's living hell? Okay, hold on. Try this one. Does this work? All right. I'm just going to do this one. It's fine. So if you want to find me, I'm on Twitter and on d.o is Danny girl. And look at my daughter again, please. All right. So let's talk for a minute about design thinking. Before I was at PEGA Systems, I worked at Harvard Business Review for about 10 months. And there were a lot of things I liked about that job, but one of my favorite things was that I got access to everything that HBR publishes, everything. There were books lining the shelves. I could access anything on the website. And since HBR is a business publication and talks a lot about management, they talked a lot about design thinking. And it's fascinating. It was really, really interesting, the idea of building empathy for people and doing all of these fun things and coming up with new stuff that nobody had ever heard of. But the more that I thought about it, the more I realized that when we talk about design thinking, we invariably are talking about business to consumer or maybe business to business. We're talking about all of these really fun and sexy and time consuming things like ethnography and design sprints and sketching and post-its. And it's also interesting because we're coming up with something that nobody's ever seen before and isn't that awesome? But that's not where we live. That is not the world that the majority of designers live in. In the enterprise, in particular, we are dealing with this weird mishmash of business to consumer, business to business, and sometimes business to employee. And all of the sections of the Venn diagram in between. And while we still get to do some fun research methods, we still get to build in usability testing, do prototyping, we get to do interviews, more often than not, we're never creating something truly new. We're building on top of something that already exists, we're optimizing our current functionality, or maybe we're migrating to some new platform from an old platform. So what does that mean when it comes to actually building empathy and doing user-centered design? So when I think about empathy, I actually break it down into four different types of empathy. Because while it's really nice to think about end users or consumers as the people that we have empathy for, getting our designs actually to leave the world usually requires empathy for a bunch of different processes that all work together. So the first type of empathy is empathy for technology. And the reason I say that is because in most cases when you are dealing with an enterprise site, you are dealing with a site that isn't just based on Drupal. It is based in six or seven different technologies, usually internal systems that actually have to interface with your website. And you are constrained very deeply by the way those systems work. So you end up as a UX designer having conversations with your developers like, no, we can't change those taxonomy terms because they are in this enterprise system and if we change it, it will all get overwritten in the next sync. Or that page, this was my favorite, that page can't be changed unless you want to do a git checkout and change the XML and re-upload it. When you are dealing with things like authentication, there are two different legacy systems that we have to integrate through a third layer to get into Drupal. All of these different things cut into the complexity of what we have to build. Then we have to deal with empathy for the content creators. Now part of that means that we have to understand all of the different people. It's not just about what are the fields that need to be in a content type? What does that form look like? How do we hide things? That's a piece of it, but we also have to think about where content is being authored. Where is it coming in from and how do we make sure that those systems are able to support the people who are creating content. So for example, we have technical writers and e-learning specialists who are creating content in a tech doc writing software and that content needs to move over to Drupal and retain some of the semantic formatting tags but also needs to strip out all of the extra stuff. How do we facilitate that? We have digital marketers that want to push the envelope on design and layout but we need to find a way to do it without killing everything. How do we do that? Then we talk about empathy for content consumers. Now this is the one that most of us think about when we think about empathy. What is it that they need? Where are they going? What is the path from A to B? But when you're talking about the enterprise, we're talking about all the people who buy and who sell our products. We're also talking about all the people who build things with our products. This is a lot more than your traditional business to consumer company. So you have to figure out all of these different modes and all of these different ways in which people need to actually consume our content and that's not even discussing new hires, people who are considering whether they want to work with us, people who need technical support for our products, people who are moderating our user group communities, industry analysts who are trying to figure out what's happening with our software, people who are attending our events. All of these different factors come into play sometimes on one single website. Finally there's empathy for the actual organization that you're with. Now one of the things that I had to learn very quickly when I started transitioning into user experience is that I don't get to build the things I design anymore. I need other people to help me build them. And what that means is I go from being the maker, being the person who takes things from end to end to having to work with other people to get these ideas implemented. There's the developer who's got a bunch of different priorities and maybe this design is a little more expensive or a little harder to build than something that he'd want to do, that he or she would want to do anyway. There is the project manager who needs to manage the backlog and fit all of this in with other priorities. Most importantly, and sometimes annoyingly, there's the hip-up. The highest paid person with an opinion. I'm sure that you've met these. If you have consulted with clients at any time, you've had these people. We call it the executive swoop and poop is another nice term for it. Very pleasant. But part of my job as the director of user experience is to convince these people that the direction that we're going is the right one and to incorporate their feedback into the design while still making it clear that it's our design. That we make the final decision. This is a much different set of skills than sitting behind a desk doing wireframes. And then there's the people who just want to be difficult. And you have to figure out what to do with them. I find that imagining them as Ron Swanson helps. So where do we start with all of this? How do we actually take all of this stuff together and actually start to create a pattern of empathy that actually works for us? So there are a couple of principles that I've actually come up with over the years. And I'm going to share them with you today. I was able to get them down to five. I had like seven or eight. And then I was running through the presentation like, my God, people will be bored. So I managed to sneak them down to five. And the first one is to start with a small group and work your way outward. Now, I'm sure we've all heard the metaphor of the iceberg. Where everything you see is right at the surface. But there's all of this stuff underneath. And you just have to keep digging until you get there. Well, in the enterprise, it's a little more like a bunch of icebergs floating out in the ocean in random spots. And once you've gotten to the bottom of one or even before you've gotten halfway down to the bottom of one, you realize that there's this other iceberg right over there that you should be paying attention to. And you have to run over there and say, okay, well, what's this now? And then you realize, well, nope, there's this other iceberg. I got to go start looking at that. So if you start small and work your way outward, it helps you make those connections. And it helps you keep track of all of the different things that you're learning. Now, there are a couple of ways to get started with this. My favorite, the way that I typically start is I have a bunch of different research methods handy. Analytics are great if you've got them. Surveys are great if you've got them. I like to use interviews and contextual inquiry. I like to use usability tests. And then we also want to find opportunities to build research into our everyday work. So if you're kicking off a new design project, make sure that you build in some time to do some research, test your designs in progress. If you have a user group conference, these are a great way to actually get and touch and talk with people to do short interviews and get a better understanding of who these people are and what they need. The next principle is to find and befriend the gatekeepers to your audience. Even if you're working in a consultancy and you've got clients, you have certain gatekeepers who are able to help you get to the people that you're trying to understand. So the main gatekeepers in any company are going to be department heads and customer service representatives. Customer service representatives, they get the calls. They understand the problems that customers are having. They can help you understand the spikes in traffic. Department heads can help you forward emails. Send them an email and say we're trying to get people for a usability study, can you forward this to your team? Event organizers can actually help you get space at an event. And it might be that you're able to get a booth, which would be fantastic. It might be that you just get to go to the event and pound the pavement talking to people. Either way, making friends and understanding those people and having executive sponsors for what you do is a great way to help continue driving UX forward. Finally, don't forget market researchers. Most companies have some market research that they've done and have a sense of who their actual audience is. And this can give you a jumping off point not only for recruiting for your own research, but for understanding what the organization thinks their audience base is. So while we're talking about market research, we also want to think about behavioral segments as opposed to marketing segments. So what I mean by this, marketing segments tend to tell you what people want. So how they make decisions, how they buy, it helps you figure out what type of content or products you want to build. What it doesn't tell you is how they actually behave on your website or how they think about the problem that your product solves. By behavioral segments, you're actually looking at the way that they treat the content and the way that they organize it in their mind. And it helps you to figure out certain behaviors or philosophies. So this is much more likely to actually inform the design that you ultimately choose. Now, to give you an example of this, if I'm an ops director or a CEO, if that's my market segment, I can assume as a designer that this person is short for time. They are more interested in a high level view. And they need something really, really quick so that they can send it to a front. That's a pretty reasonable assumption from a market segment. If I go to behavioral segments, I can say that if I'm a carried executive, yes, I'm short for time, but I handle that by quickly skimming headlines, bookmarking anything that looks interesting. And then once I actually do have time, like a long plane ride or on Sunday morning, I go back to all those things I bookmarked and I read them all in one go. If I'm an office thought leader, yes, I'm busy, yes, I'm starved for time, but I'm going to quickly skim this article and forward it to somebody that I know. Those are two very different design personas, but they could happen within the same market segments. Indy Young, the founder of Practical Empathy says that the key is to recognize that there are different casts of characters involved with the various services your organization has to offer. By focusing on particular behaviors instead of just market segments or job roles, what you get to do is say to your organization, look, I know that you have these market segments and I know they're valuable for what you need to do. These design personas are useful for what we need to do. The next principle is to focus not on user stories, but on the jobs that people actually have to do. Now, this is a pretty typical user story. As a user, I want a set of quick links to files I need frequently so I can readily access them. Now, if I'm a developer, what does that say to me? I have a block, I call it quick links, people can add links to it. That's what it says to me. But if I dig into the actual jobs that someone needs to do, I can say when my colleagues and I have to work through a proposal, we need to have all the template files in one place so we can work more efficiently. When I'm starting out an engagement with a client, I need to find the resources and paperwork I need to get up and running so that I can feel competent that I'm adding value. As I'm working on a client engagement, I need easy access to key forms that I have to fill out to report progress on the project so I can spend less time doing paperwork and more time getting my work done. Those three jobs fit that user story, but that gives you a much different perspective on why you need quick links. And it gives you more information about how you could design that experience so it doesn't look like every corporate intranet ever. And the final principle, and I would argue the most important, is to socialize what you've learned all the time. Really, all the time. And the reason you wanna do that is, A, it makes people really happy in meetings when you're able to tell them, well, this is what we learned. But also because it helps you build that institutional understanding within your team of the people you serve so that you can continue to make better products together. So a couple of the ways that we do this, and I did this at Harvard Business Review, I also do this here. We actually put all of our user research, all of the reports are up on our Wiki, our Team Wiki. So basically anyone who's part of the company can get the report and access all of our user research. We also were able to send the links out to different stakeholders. We use a service called Hackpad to do this. You can also use Confluence or any other Wiki software to do this. Another thing we do is fairly regular usability testing, which we invite stakeholders to and we give presentations on. We'll sometimes do highlight reels so people can actually see certain issues popping up. We also will send it to developers so that they're able to actually see, this is exactly the problem that they were having. When we have research findings, we also try to build them into what here is a feature priority matrix. So what this does is actually say, okay, given what we heard, these are the features that could come out of that and this is where we'd recommend them in terms of priority. And then the other thing we do, and this works very well with hippos by the way, is when we're in meetings and people are talking about what we should do next, we're able to actually share things that we heard from people in the organization. Well, you know, this is what we heard and it seems like this is a much bigger need than what we're talking about here. And it goes a long way, not only for helping you get your point across, but also for letting people know, letting stakeholders know that you actually care about them. So given all of these things, some of these are much easier to do than others. Most of these things take some time, but if you're able to put some of these things into practice, it's much easier to get things done and to create cohesion in your organization. So I wanna leave time for questions and open discussion and it is, you know, the end of the day, which, you know, I'm happy to be up here at five. But before I open the floor up to questions, I do wanna remind you that sprints are happening on Friday. So if you are a coder, a UXer, or someone who actually, you know, just wants to make Drupal a better product, go to the convention center on Friday and sprint with us. You can also evaluate this session. It's bit.ly slash one R-N-J-O-Z four. And I will put these slides up on the website so that you can all have them. I was working on them until just recently. So I wanna open up the floor to questions. Anyone? Yes. Okay, so I think if I understand that question correctly, you're basically saying, let's say that you've got the quick links discussion that someone wants to have and you're able to break it down into job stories and say, well, these are the three jobs they're trying to do. And then what does that actually turn into when you're creating a design? Does that sound accurate? Okay, so, well, this is sort of a hypothetical, but the way that you would have that conversation is those job stories are three entirely different use cases and one block that says quick links with a bunch of random links that aren't even organized by what you're trying to use them for doesn't serve that need. But if you can break them down to, for example, a stage in a project, then you understand, okay, well, what we really need to deal with is that stage in the project. And here's how you go through that project and here are the files you need. Does that make sense? So this is now turning into, well, that's not really a set of quick links. This is actually a set of instructions that includes links to the files. Does that make sense? Mm-hmm. They still might. I mean, and that's the thing about enterprise design. It's not just about empathy, it's also about patience. You can't win every single fight, but being able to speak to a real user need, being able to speak to people you've spoken to and say this is what we heard from the 20 some odd interviews that we did, from the eight people that we did usability testing with, that goes a long way to helping you back up that state. Does anyone else have a question? Yes. Okay, so I think what I'm hearing is how do we make sure that we're able to achieve consensus without delaying the project? Sometimes the project just gets delayed. So I think that's where the influence comes into play and actually trying to have empathy for the organization and really getting out there and meeting people. Sometimes it ends up really being like meetings before the meeting. So you have to basically find, you basically have to figure out, okay, who is the person that's going to object the heaviest to this? And can we either talk to them before the meeting and give them a sense of what we're trying to do or is this just a person who's going to be difficult and we need to basically get back up and work around them? So it really requires, I think it depends on how hard you think it's going to be to get consensus and who is the person that you need to work on a little more, does that make sense? But yeah, sometimes it does just get delayed and you have to sort of roll with that. Anyone else? I always fall back to why. So if you've heard feedback from customers that they want this particular feature, you can ask, well, okay, so what is it going to help them do? Why are they asking for it? And if you can talk to some of those people who requested it, start digging in, start digging in, why, what is this going to help you do? And I think there's also, with stakeholders, if there are business owners, do the same thing with them. We want to do this because it's going to make us more competitive, okay, but these are our customers. How are they going to get value from this? So if you can bring everything back to why are we doing this and what is it going to help people do, that goes a long way. And it helps people actually think through solutions because if you can bring it back to a job that someone has to get done, it gives you more ideas for making it better and you're not just chasing after the competition now, now you're saying, okay, well we know what people need to do and this is a better way to help them do that. Next question. No? All right, cool. Enjoy your drinks. Thank you. Thanks.