Embracing Empathy

Embracing Empathy

Speaker Name: Tim Hudson UXDX18

**Tim Hudson **
Thank you all for joining the session. My name is Tim Hudson. I work for a company called Ajin. We make payments. We'll get more into that in a moment. I'm here today to talk about embracing empathy. And some tell you a little bit about empathy and my view on empathy or our view on empathy again. But first, a little bit about myself, I studied at Saint Martin’s College of Art in London. So I started as an artist. I still make paintings. You can see those. I'll show you a link later if you're interested. But we're not going to talk about that. Today, we're going to talk about how I got into empathy with Agile. So I have a little confession to make. I'm talking about empathy. Does anybody know what this is? This is an NBI profile. It's kind of a profile of your brain and how you work. And this is not just any MBTI profile. This is my NBI profile. And if you had this laser gun here, laser, this one. Wow. If you look at this section here, this says that I'm quite strategic, an imagineer, I'm quite creative. If you look at this section here, this is about socialising and empathising. And if you look at this smallest section here, that's about empathy. It says that Tim will most probably not be comfortable in an environment that requires him to be emotionally sensitive and show empathy and support on an ongoing basis. So I hold my hand up. I'm not empathic. I'm more em'pathetic'. So it doesn't get better than that. So there you go. So I work for a company called Ajin. We make payments possible. So we make it possible for your money to get from wherever you want to pay into the merchants. Bank accounts. And it's quite a complicated process. For many years, it's been run on traditional rails. And we're kind of disrupting or trying to disrupt that whole process of getting payments from one place to another. So you see, here, this is what makes us unique: this is the usual path of payment that a merchant would connect to a gateway. Maybe you've heard of Stripe or some other gateways out there. But what we do is we take all the pieces, so the gateway, the risk, the processing, we are an acquirer and a processor. So we just make one system, so there are less points of failure. And we can keep the data connection along with all the dots all the way. So it's quite good. So if you've got a Netflix account or a Spotify account or pay on Facebook, you probably pay through Ajin. We don't only do online sales and E-commerce. We also have moved over the last few years into a point of sale. That means that when you go into a Nike store and buy your shoes, you're also probably playing ping through Amgen. So in product design, or what was called UX at first, what were our touchpoints? So we make it possible to make these payment pages that you will pay online with. Even though we don't make those pages ourselves, we create the framework for people to make those payment pages. We do have to make some just what we call the default page. We also provide our software for the terminals you pay in stores. So that's one touchpoint to our customers. That's to shoppers, let's say, but our main customers, we're strictly business to business. So mainly what you would do and you've heard about icebergs already this morning, we create icebergs. So what does this represent in terms of Again? The tip of the iceberg is the customer area, where our merchants login and manage their payments. So they'll manage the risk, manage the users, and do the case management, that kind of stuff. And underneath the iceberg is what we do operationally inside Arjun for our customers so we can also manage risk. And there are many, many other financial operations that we perform. So that's basically what our product designers and UX mainly do at IGN. Internally in Agile, we have built a fantastic engine, and when we talk about our software, we often refer to it as an engine, and we say we've built the best engine for payments there is we took the old rails of the payments flow, we've redesigned it from scratch. We're also about 11 years old.

And we started, you know, we often refer to it as one of the best engines in the world for payments. So the modularity engine, so what do we do as UX? Well, of course, we tried to take this, and we made it into something like this. And the guys who started the agenda were very technical, really technical. We're not a design thinking company at all. Or we never were. This is where we're trying to get to. And this is where we're thinking about empathy. So these guys have built a double booking accounting system, this kind of thing, these guys who look out the window, and they don't see a landscape, they see numbers. And it's very difficult for them to produce nice interfaces. And this is the sort of interface I was faced with when I started working again, about five and a half years ago. It's very functional. The use of space isn't very good. It's just filling in some, some stuff. So this is what I was faced with. To begin with, There were no front-end developers who knew how to do HTML and CSS. There were no UX designers at all. There wasn't even any design. So this is what the team and I have been doing over the past five years. When I first got there, they gave me this. And they said I said, yeah, we've got to design something. And I Oh, yeah. The hump of black plastic. That's good. But I want to use Photoshop. This was the line x machine. I want to use Photoshop and stuff like that. And they said, no, no, you've got gimp and Inkscape. So I'm like, Yeah, right. So I kind of felt a bit like an island. All these intelligent developers are developing these, you know, functional systems. And here's me saying, No, we've got to make it look pretty. And oh, yeah, it's got to be usable for our customers. People didn't get that. So here, you see, this was the environment we were in. And there, you see, I brought the first Mac screen in to add yen. But you see, it's all black and white. And everybody got these black screens, black desks, and they weren't really in an environment that made them feel like producing something good-looking and well-functioning. So how do we work agile? We have this basic set of principles that we call the Ajin formula. And as you see, there's eight of them here. You don't have to read them all. I'm going to pick out a few that are important to me to do my job at IGN. We say to all our employees that we don't hide behind email. Instead, we pick up the phone. Just go and talk to people, don't you know, waste time, don't even pick up the phone. In the same office, we encourage people to just go and talk all the time, talk at the coffee machine, talk whatever, don't do not waste time with red tape or anything like that. Just see the person. We also said, which was quite difficult for me to launch fast and iterated. You know, payments is a fast-paced game. Everybody's trying to get in there. So it's about launching fast. And when you think about developing and making UX possible, when you've got something like this built into your core cultures in your core values, and it's like, really, if we're trying to do anything on the front end, it's like trying to change wheels on a fast-moving car. So we're all the time every month releasing, releasing software, the developers, there are 100 developers there, coding, coding, coding, we've got new, no UX, there's no you front end coders. So this is what our design looked like back in the day. So you know, we went and got some definition. And then we built it. So, where does empathy fit in here? Well, it doesn't really. Maybe when you define it, you can listen to the customers, what you want. And everybody probably knows your role in UX, I assume, or your developers, and everybody kind of knows that this is the past that we should have, you know, define research. Now there are lots of points in here to put empathy into what you're building. But when you've got no time to do that, and when you're trying to sell this to a fast-functioning company, it's quite difficult to get these points in here and get empathy, and actually to do this whole process is quite difficult. So we wanted to start from somewhere a bit smaller. We wanted to start from principles, just three simple principles. We want our interface to be intuitive, consistent, and helpful. Right. So this was the kind of interface we were faced with back then. And, of course, agenda payments and data are very important. So I've just picked one example out of the whole of what we call the back office. In the customs area, just to make a point of what's going on and what was going on. So here you see, well,

We had data, great, and not many people did at the time. And not many payment service providers, But we did. And you see, it looked quite pretty, right? Looks great. It's like lots of colors and stuff. But what's going on? If you look at the principles intuitive and helpful, this isn't very intuitive. It's not very helpful. But how could I say that to the guys who built it? And these guys were thinking functionally? So if you see here, you know, we've got a graph that's orange and green. But what does it mean? It doesn't say anything. This doesn't align with this one or this one with this one. So if you look at comparisons, that's difficult. This is some kind of like a pie chart, don't get me started on pie charts. We'll get to that later. And this what does this tell you? Well, let's assume we're talking about payments. How are we doing? Well, in the world, it's a map of the world. We're doing pretty green in Europe if you're not colorblind, and in the rest of the world, pretty shitty Brown. But that's okay, this ad because you will see the number of sessions you've done when you roll over. And when you roll out again, it disappears. So I said that people hadn't got good short-term memories, how are they remember that when comparing figures? And then we've got good short-term memories? Who's got a good short-term memory here? Has anybody got good short-term memory? Come on. Do you miss stuff? Don't be shy. One? No, no, she's scratching her head. Anybody else? Good short-term memory? Well, let's do a test. Let's do a little test, shall we? I'm going to show you a couple of pictures. I'm going to show you this picture of a house. I'm going to show you another picture of the same house. And it's almost identical, but there is one change, right in this picture. And all I want you to do is just remember this picture in your short-term memory, look at the next picture and see if you can see what's changed. Now. If you have, don't shout out. Yeah, that's not going to work because then you'll ruin it for everybody else. I want to see you raise your hand slowly. If you've seen what's going on here. So picture number one.

Picture number two. Did you see what's changed there? Come on. I've got 25 minutes. Am I ready? We'll go back. Picture number one. Did you say that time?

Come on; somebody's good short-term memory got saved. And picture number two? Anybody? Oh, somebody saw it. Who? Well done. We'll stop at one. What's happening here, buddy? I always put kittens in because that brings empathy for me. So what's going on here? Did anybody see men in black? I've just got this little finger of my hand, and I've got all your memories just going like this? Well, now, what's going on here is, if you notice, I put a white blank screen in the middle. So when you look at something and collaboratively when you see something, your brain doesn't see the whole picture. It sees little parts of the picture, your eyes dotted around, and it builds up this frame in your mind of the picture. And you see what it was, when I put that white screen in the middle, what I'm effectively doing is wiping your short-term memory, because your brain thinks, oh, hang on, forget what I've just seen and see something else. Right. So that's actually what's happening. Unless you're looking at the exact spot that changes when we've got the white screen that makes the changeover. You won't notice what's going on. And I guess none of you were looking at that spot. So let me show you again, and I'm going to remove that white, blank screen. I'm not going to do the men in black thing anymore. He already picked one. Picture two who saw it that time? Does anybody see it? Does anybody not see it? Okay. So what we end up with is not a map of the world with green and shitty Brown, but we just end up with some bar charts, which clearly show you know how you're doing in each of the regions that's a bit more intuitive. It's a bit more helpful to our customers. Such a pie chart. Oh, God. Here we go. A pie chart. This is not just a pie chart. This is lying with data. Can anybody see how this is lined with data? Does anybody see this? Yeah, the number of people. I'll just point out since when has 19.5 been bigger than 21.2? Yeah, it doesn't work. Does it add who the hell would want to do that? I have no idea but to move swiftly on. We are not very good at looking at circles. Pie charts are not very good. And I tried to eliminate them from Ajin. And I give everybody this talk as an introduction session. And I say to everybody again, look at these circles, the second-largest dark green shape there? Can you spot it? Well, you probably can. But it's not that easy, right? And to make it more difficult, what I could say is take these three dark green shapes. I love doing this. By the way, I wish my cat was here. Right? I did that. I did this presentation for the cat just to practice. And this is where it all broke down. Anyway, take these three shapes. And are they bigger or smaller than this shape? Quite difficult to do, right? It's quite difficult because what I'm asking you to do is make a circle. Our brains are not good at looking at circles, minus another circle, and seeing what's left. Right. So that's not an easy thing to do. But bar charts, height, and width are quite easy to look at. And it's easy for us to judge. Why is that everybody? Just stand up for me? Come on. I'm just making sure you sleep. Good, good. That took a bit longer than I wanted just to have a look around the room. I've looked at the neighbor, and you are taller or smaller than your neighbor. Look at somebody at the back of the room. And are you taller or smaller? I mean, I'm on the stage. But you can probably guess if you're taller or smaller than me. Right? Exactly. You can sit down, thank you instinct. We've got a built-in instinct to know about height and width. Where does that come from? I guess when we're growing up as cavemen and whatever, and there are animals around anything bigger than us, we want to run away. And anything smaller, we want to kill and eat. So there we go. It's kind of built-in. So it's a lot easier for people to see bar charts. So just use bar charts. It's a lot more intuitive. Right? Now, if you want to create empathy for yourself, right? So if Ajin didn't want to, I'm trying to make the general employees empathize with our customers. Right? Now. If I want our customers to empathize with agile, that's completely the other way around. I could use pie charts, even though I hate them. And I think they're not very intuitive. I could use them in something like infographics. Why would I do that? Why does a pie chart create empathy the other way around? If you think about it, we like circles. We're not very good at judging them. But we like them. Why do we like circles? Does anybody know? Well, we've got round faces and round eyes. And we like to look at round faces and round eyes, right? The bigger and round of the face and round of the eye, the more empathy. Oh.

Oh, moving swiftly on. So what do we do again? Well, we call them product designers now are all split into streams. And we tell people in the stream, so we've got a different product designer on each stream. We've got fraud and risk and data and reporting. And we go through, and we tell people these things. And we say, look, we want to be not a functional company. Here are the ladder tips, product success. You may have seen this may not, you know, we want to move from functional to usable and comfortable. We want to make that experience delightful and meaningful with our software. What does that mean? How do we show them what that means? Well, I don't know if you're familiar with thermostats, but this is an example of something functional and something that may be classed as meaningful or delightful to use. Why is that? Well, you just press the buttons, and it makes your radiators come on when you want. This one learns when you just come on, and it even provides a nightlight when you walk to the bathroom at night. So how do we get our product there? How do we try to do that? Well, here's one thing that we've done with terminals, we've just taken a not-so-nice interface. And we've tried to, you know, think about all that kind of stuff. And we built it into our terminals and we got sound.

This is another interface that we have. And if you see this is the kind of settings that we'd have before, you know, just lots of stuff to fill in lots of ticks. And now we're working with the design system, our design system that we call the agenda design language. And we've tried to put some more information in there. It's not just a tick box. We've tried to add some information, that kind of stuff in there. So this is what the design system looks like. It starts in Sketch. Then we get our very experienced developers to build this as a library so the other front-end developers can go on and use this. But I have an important question. Why did it make you stand up a minute ago? Why did we do the exercise with memory? Right? I'm trying to do what I put our developers through, and everybody works at Ajin. I'm doing that because I want you to experience exactly what I'm talking about. It's okay to tell people and show people and make them sit there and see this thermostat and understand it. But when you stand up now, when you stand up, hopefully, you'll remember, Oh, I'm using more of, you know, touch, smell, sight, sound thinking, oh, yeah, that was about pie charts. I shouldn't use pie charts. And that memory tests are making you empathize with the user. Because when the users get to click and remember all the, you know, data when rolling in and rolling out, that doesn't hit home until you make somebody do it. Until I prove to you, hey, cognitively, you're not very good at this stuff. So let's think about the user. So this is how we're trying to bring empathy. Within Agilent. I told you about the environment we worked in, and I showed you that it was all black and white computers. One thing that we've been doing is making our offices look nicer. You know, these people from Google, and you see all these, you know, sleep pods at Google and that kind of thing, great environments. And we're like, why can't we have the environment. So this works. These are our offices around the world. We've now got 14 offices, you see Singapore, New York, San Francisco, but we try to make them look beautiful. So people working there are surrounded by good design, we've started to do design sprints, there was a workshop yesterday, very good on design sprints. Who knows what design sprints are? Great, they are very useful when we didn't last time I gave this talk and would not start to do them. I've recently made five or six design sprints, and they've been wondering if you can get the buy-in. Now the buy-in is quite difficult because I took this to our, you know, strategy team, and I said, we've got to do design sprints, this is going to be great. And they looked at this; I told him about this book. And you know what they saw these five days? Five days for the team of people. Gosh, we launch fast. We iterate. Yes, I know, I know. But look, this is going to be so useful. I did a bit of research, and there are some very smart people called AJ and smart from Berlin. Big up to them, they were fantastic. They've been working with the design space for a long time. And they've made design sprints 2.0. So if you're going to use a design sprint, please look at this because it's only four days. But it's not four days with all the expensive people. Because this was the old system. Monday, Tuesday, Wednesday, you'd make use of sketches to decide the whole group is there for the first three days. And then you prototype and test on Friday. This design, print, design, sprint 2.0, you get it all done. You prototype on Wednesday and test on Thursday. This has been very successful. Agile is great. So I highly recommend it. When we do the user testing on these design sprints and stuff, you can see. We've set up two rooms where we film the person doing the test. We filmed the screen as well. And we have that beam to another room. And we get everybody from the team developers and everything watching that. And going through that with it with the people. That's also very useful. And they all make notes. And then they can see that wonderful idea of how they were or whatever the other way around. But anyway, what we've also done is we've talked about our developers, we've also made a code of conduct for our developers, you don't have to read this as well, I'm just going to point out a couple that I managed to squeeze in there. Okay, there's a lot of kind of guidewire guidelines here. But the two that are important to me are that we think like a merchant. So meet them. We want everybody in our company to meet the merchants. And a product is only finished when it has a face and is validated with a live customer. And oh, it's a wrap. Thank you.

We do have a stand if you want to come and talk to us. You see Nick, the head of product design. Instead, we've got Thomas, who's our design system developer. We've got at least a lot. If you're interested in a job, come and talk to us on my lab set. And I just did. And you can see here we've got a tech blog at medium. We've got careers if you're interested. And this Instagram, the secret code machine, is mine if you want to see the paintings. Thank you very much.

Stage Secretary
Great talk template. Can you hang up for just a few minutes? We might have a few questions.

**Tim Hudson **
Oh, yeah,

Stage Secretary
I think we have a few times. A few minutes for questions. Does anybody have a question for Tim?

Tim Hudson
You can see back there. No.

**Stage Secretary **
Well, I know you guys. I have a couple of questions. So you guys recently IPO does that, right? We did. He did. So as that changed I mean, that's a big step for any company. I know you guys have been around for 11 years now. Has that changed to any of your things? Is that anything that happens in the design group of the UX of the product team?

**Tim Hudson **
We knew we were going to do the IPO for a long time. It had been on the cards for a long time. And Peter ASIO spoke to everybody about it before we did it. And it was very clear. IPO means nothing to us. It's just the shareholders we had, who we didn't know being changed for different shareholders that we don't know. Right? So it means nothing to us on a daily basis. All it means is we've got different shareholders. And it's another day as usual. So no, the IPO hasn't changed anything the way we were.

**Stage Secretary **
Yeah, that's great. So when did you join the company?

**Tim Hudson **
I joined five and a half years ago, March 2008.

**Stage Secretary **
So about halfway through the company's life. Yeah. And have you seen, were there any metrics that you use to judge the success of your implementation of more customer empathy,

**Tim Hudson **
It's good because getting metrics on what we do? Because there weren't, there were no metrics at the start. So we've introduced systems like an internal system because we're in payments, we can't use any cloud systems. So the data is very precious. So we're not using Google Analytics. But we've got an internal data metric system for our back office. So we're using that; of course, support tickets are a great metric. So now we've got full access. All designers have got full access to all support tickets. And you can go, and you can look at those in Looker and that kind of stuff. So yeah, this has changed now.

**Stage Secretary **
That's great. Any questions? Yeah, we have some questions. Great. Let's get a mic over here. And state your name and company as well.

**Charles **
Hi. My name is Charles. I'm a UX researcher at Primerica. So I want to go back to your point about pie charts and how confusing they are to interpret. And then you recommended these bar graphs instead. And that he showed us a photo of a puppy, and now we feel empathy towards that puppy. And so now I'm kind of lost.

**Tim Hudson **
So okay, the point was what I was trying to make, and I was in two minds whether to remove those two slides or not. So I'm glad that you pointed this out. You know, what I'm trying to do on IGN is build empathy from within. So within the iceberg to our customers. The point with the pie charts is that they would empathize with our customers. So if we put out some infographics with pie charts on or circles, our customers would then emphasize empathy towards us. So if you want to do that, that's a good way to do it. I still don't think pie charts are very good. I'm trying to make our team empathize with our customers. So it's just a bit of a switch round. Sorry if it was confusing. Yes, clear. Now. Does anybody else want to pick me up on pie charts?

**Stage Secretary **
Great question. Any other questions out there? Yeah, one more in the back. There are a couple. Remember, state your name and your company.

**Javier **
Hi, this is Javier from on track. I'm the Chief Product Officer. I was wondering how you combine design sprints with regular work. It's very similar.

**Tim Hudson **
Well, we say design sprints are a tool. You can use them if you want. So the streams are set up in such a way that we have two leaders of the stream: we have a product lead and a tech lead. We've got front-end and back-end developers and business strategists in there. And I've been touting the design sprints as I thought they were a good idea. But we've won by no means of enforcing them. And before anybody takes a design sprint, Arjun, I have to make sure that they're filled in just a little thing to make me know that they're serious about it, that they're going to put the time in and the effort, and that they're going to do the homework beforehand. So they need to find the experts to speak with. They need to make sure they've got the resources to carry on with whatever we've designed in the design sprint. So there's a lot of conditions that we do when we say, Look, these are the conditions. And I'm not going to let you make a design sprint unless you do that. So we kind of build it in so that the pauses where a design sprint would naturally fit in would be when they finished a major product project. And they get to the end of a release. Time's up, and time's up. When they release and embark on the next new project that would be a good time to make a design sprint, depending on how big the project was, so we want it to fit in naturally. We don't want to force anybody to do it. Great question.

**Stage Secretary **
Thanks, Tim. Thank you. Remember to check out his art.