It's All About User Experience - BelTech 2014

Who here knows what UX means? Hands up. 1, 2, 3, 4, 5. Yeah, see, not nearly enough. I'm in the right place then. Good. A little bit about myself, because, you know, whenever I get a platform, I'm a marketer still, so, you know, self-promotion comes naturally. The accent's from Holland, by the way, in case you're wondering. I am actually a Dutchman. I know the name doesn't give it away. Long story. I am the digital director at the Tomorrow Lab, which Not that long ago, it was called Peers Communications. We split the company up into different brands because I thought it made more sense. We basically build websites and make them successful. You can follow me on Twitter, but don't if you don't like profanity, because I do swear quite a lot. And I do some blogging here and there. Yeah, this is what I mentioned about the Tomorrow Lab. Like I said, when I have a platform, I can't help myself. Enough for the self-promotion, right? Let's get straight to the point. UX, user experience. What does that actually mean? What does that actually stand for? This is the definition off of Wikipedia, which doesn't really say all that much, as Wikipedia is quite wont to do. So I thought, why not just show what UX isn't? I know there's quite a few coders here in the room. Honest, honest show of hands, who's built something like this? Right, keep your hand up. Now, ball that into a fist and punch yourself in the face. I mean, come on, really? Anybody who's ever parked at St. Anne's Square here in Belfast will recognize a lift system very similar to this. Every time I parked there, and I parked there quite a lot because it's handy for us to get to, it's close to the Cathedral Quarter, lots of lovely places, coffee shops, pubs, obviously. But I spend like 30 seconds every time I get into that lift trying to find the bloody button I'm supposed to be pressing. This doesn't make any sense. And one of my favorites here, found this one on the internet. Try getting out of that one, trapped on a parking lot for the rest of your life. Yeah, this doesn't make sense either, does it? Do you push? Do you pull? What do you do? Conflicting signals there. Someone hasn't really thought about that very much. Yeah, anybody who's ever used Windows will recognize these. I mean, really? The one on the bottom right is interesting. The operation completed successfully with an error icon. I mean, again, mixed signals. That just does not compute in any way. You know, and I'm saying this as quite a fan of Microsoft and Windows in general. The error messages are stupendously idiotic. Is the Microsoft guy still here? Come on, let's bash him. No. No. When it comes to technology, the technology that we build, we tend to forget that we're not just building something that, you know, has an if-then-else statement in it to solve a specific problem. We're building something that is intended to be used by actual people, not geeks, no, people out there in the wide world who don't know what an if-then-else statement is. And we can design these technologies in such a way that we get a specific type of response from these people, a positive response, hopefully, unless, you know, you like pissing people off, in which case, by all means, design something to go horribly wrong every single time. I'm pretty sure the guy who designed Windows 98 had exactly that in mind. The problem with good user experience design is that we only notice it when it goes really, really wrong. Like the examples I just showed you. If it goes really, really right, if a lot of thought has gone into designing an experience of a piece of technology, it becomes invisible, it becomes seamless, becomes something we don't notice anymore at all. A couple of examples. I already said I don't like Apple that much, so I don't like Google either, but that's because of my history as a search engine optimizer. But I have to give it to them, they know how to build a good interface. They make it really, really easy to use their systems. That on/off button, you can't miss that. And the thing about these sorts of interactions that we more or less start to expect nowadays from all the systems that we use is that there's a lot of thought that has gone into that. A lot of thinking, a lot of research, a lot of iterations. But it's invisible to us because it just works. It just makes sense. And that's the beauty of good UX. It just makes sense. But that also makes it a very ungrateful task to do right. This— I love this interface. Book a holiday. As simple as you can make it. Pick a place to go, where you're leaving from, when you're leaving, and just find stuff. How easy can you make it? This is a very simple app that shows you what's on TV at PBS. It's that sort of stuff that, you know, looks very simple and very straightforward but there's an awful lot of thinking, an awful lot of hard work that's gone into designing that sort of experience. So, why does all this stuff matter? Why is UX so important? At least I think it's important. Because whenever we create a piece of technology, it doesn't exist in a vacuum. It's been said before here today that if technology exists for the sake of technology, for the sake of itself, it doesn't really do anything. It doesn't serve a purpose. We build technology for it to be used, for it to solve problems, for it to improve people's lives, to make things easier. We cannot and should not separate technology from the people who will actually be using it, whether that be financial services people or civil servants or customers who buy stuff online. We have to keep in mind who we are building this technology for. Here are a few examples of technologies from the last 10, 15 years that were built because they could, not because they necessarily solved a problem. In 2001, Microsoft launched the first tablet computer, which ran on Windows 98— well, Windows XP, I think it was. Well, that's your mistake right there. They just did it because they could, and they sold maybe 5 of them. Be honest, who here has ever used a QR code that they found on, say, a packet of milk or on a billboard? Who's ever done that? Right. Whoever thought that was easy? That was handy? I mean, unless you have a Windows Phone, and seriously, who has a Windows Phone? Unless you have a Windows Phone, you have to install an app to read the QR code in the first place. Oh, hi, Andy, you have a Windows Phone. You have to install an app in the first place to scan the bloody thing, and then usually you get sent to a website that isn't mobile-friendly. What the hell are these people thinking? Also LaserDiscs. Who here remembers LaserDiscs? They're huge, this enormous thing that you stuff into this player. Nobody's going to use that. Of course, now shortly after the LaserDisc was invented, the DVD came out, which stuffed 5 times as much data on a disc the size of a CD. So it became very obsolete very quickly. But again, it's just something they built because they could, and they didn't really think about how people would use it. And because I wanted to wile on Apple a little bit as well, the Apple Newton, one of their biggest failures, a PDA that they built because they could, not because it really added any value as such. So it totally flopped. Not everything that Apple do turns into gold, fortunately. What great user experience design means is that when people use the technology that you've built, they have to spend less thinking power, less cognitive energy trying to do what you want them to do. And that means they have more energy, more concentration left over to focus on what the actual task is you're asking them to do. That's a big distinction there. You have to separate the task they're supposed to do from the means by which they do it. You have to make the means as simple and straightforward as possible so that they can focus completely on doing what you want them to do. And especially when it comes to repetitive tasks or tasks in office environments, that is very important. You do not want to frustrate your users. In the world of e-commerce, for example, there's a bit of a golden rule: every single extra form field you fill in, it means another percentage of users will drop off because they don't want to fill it in. The less information you ask from your users, the more likely they are to go through the whole process that you want them to go through. And it's that sort of mantra that applies to all, or should apply to all technology. It has to be easy to use. It has to be simple. It has to be straightforward and self-evident. It has to be pleasant. Technology has to be pleasant to use, because if it's pleasant, if it's fun to use, people will use it more, and they come back more often, and they tell other people about it. And that only has advantages for everybody involved. The value of usability is sometimes very hard to quantify, because like I said, we only notice it when it goes horribly wrong. But it makes technology easier to use. And if it's easy to use, it's used more often, and if it's used more often, it adds more value to everyone. Not just you as the builder of the technology, but also to the users who, you know, you should be designing for in the first place. I'm going to talk a bit about how you can understand UX and UX design. I hope everybody's convinced of its importance by now. If not, Come talk to me afterwards, we'll have a very intimate discussion. One of the first things that people tend to confuse is user experience is the same as the user interface. And that is quite a classical error because the interface is important, but it's just one aspect of the whole user experience. Take for example an app that you built for an iPad. The app itself has an interface that should be easy to use and straightforward. But the act of using it involves an actual hardware device. It involves tapping and swiping. And it involves a use case, an environment in which the user is sitting in. If, for example, you are creating an app for someone to use on a construction site, you can't use sound very well because it will be noisy. So you have to find a way to make things that you want the app to do not use sound in any way, other types of feedback. So user experience encompasses all aspects of your technology being used. The device it's being used on, the interface, every single step of the process you're trying to take the users through, everything. So it's not just the user interface. UI design is not the same as UX design. UX design can be very complicated. I'm not going to take you through all of these because it hurts my brain looking at those, never mind your brains. But it can be very simple. It basically evolves— you have to evolve a process in your organization. I'll talk about that a little bit more You have to evolve a process where you put the users for which you are building the system at the center of everything that you do. Now, in a classic technology project, if I can call it that, you take requirements at the start and then you start building. And if you're lucky, you might get some users to test it at some stage down the line when you say 90% done or 80% done. That's a very wrong way to build something because you usually end up with something that you think matches your requirements, but it's probably an interpretation written by someone who got all this research done, which you then interpret in your own way, and that's what you end up building. User-centered design is the heart of UX design. It means that every single step Every single step of the process you involve users. You start not even— you don't even start by writing a functional spec or anything like that. You start by asking your users. You start by doing the research on what the users' requirements are. And you do that quite in depth and in detail. Then when you do the concept phase of your technology, again, you talk to your users. You let them see it, you let them get feedback, you try it out, you do prototypes, wireframes, give it to users, see what they do with it. Then of course you design and build the whole thing. Again, every single step you involve users. Now there's a lot of UX designers out there who feel that UX is something that doesn't apply really well to the agile process. I tend to disagree with that. I think UX and Agile development are made for each other. Because Agile makes it much easier to get that user feedback involved in almost every single iteration of your product. You have to make it part of your Agile process. Every single thing that you do, every iteration of the product that you're building, you can test it against users. You can get that feedback and see if it's actually working for them. And this is the hardest bit, how you can get UX design embedded in an organization. I suspect that most technology organizations nowadays are maybe at a 3 or 4, 4 if you're lucky, on this particular ladder, whereas 1 is UX is entirely unrecognized, And 6 is it's such an integral part of the organization that nobody can think of doing it any other way. Ironically, the bottom and top layer of this particular model have one thing in common, which is that UX is almost never mentioned. In the bottom layer, it's never mentioned because nobody knows what it is. In the top layer, it's never mentioned because it's natural. It's just second nature. They don't even have to think about it anymore. There's very few organizations that are at 6. Apple, Google are the obvious examples of— and Facebook actually to an extent as well— the obvious examples of companies that don't even talk about UX anymore because it's the very core of their business. They make products for people to use. But you know, the stages you have to go through as a technology company, and because UX is such a new field, seen as a bit fuzzy compared to you know, the hard technology side where, you know, you solve problems, you write code, either it works or it doesn't work. If it does work, you have no idea why, but you'll take the credit. If it doesn't work, you blame the next programmer. But with UX, it's fuzzier. It's, you know, you get icky people involved. You get feedback from users that's not clearly black or white, yes or no. It's a big gray area. And that makes it a bit of a daunting prospect. for technology companies to fully embrace and adopt. But it's absolutely necessary that you do so, because all the other companies are doing it. And you can't build technology anymore for the sake of it and expect people to start using it. If you don't put your user at the center of what you do as a technology company, then you will be overtaken and left behind. Thank you. So, to summarize, you have to design for the people who will end up using it, which has some disadvantages because it takes you into some uncomfortable territory. But for some people, and I probably think project managers especially, this is fantastic news because you can override the hippos. Anybody here know what hippo stands for? Highest Paid Person's Opinion. Very common in almost any technology project, Especially when you build websites. You know, you've got a great design, you've got it signed off by nearly every stakeholder, and at the last minute the CEO of the company comes along and wants to piss all over the design and say, no, that needs to be blue, that needs to be red, I want a bigger button. If you embed UX in your process entirely, you can say to that person, nope, your users, the people who should be using this, don't like that. The feedback's not good. And, you know, hippies being hippies, they might still override you, but at least you can then say, I told you so. So that's quite satisfying too. You need to start with research. Don't start trying to solve a problem without understanding the problem you're trying to solve. You know, when a client comes to you and says, we want an application that does this, always ask why. What is the problem you're trying to solve? And don't let the client write the answer for you. Get to the heart of it. Try to get in front of the users, the client's clients, if you will, who will end up using it, and ask them what the problem is that needs to be solved. I can guarantee you that 9 times out of 10, the actual problem that needs to be solved is quite different from what you were asked to build in the first place. And like I said, it needs to be embedded from the start. You can't just throw a gloss over a piece of technology at the end and call that UX design. That's a discredit to everything UX stands for. You need to embed it from the start. It needs to be an integral part of everything that you build. Because everything you build, you build to be used. There's very few cases of technology where there's not an actual human being involved who's been using it. You know, if you build APIs, fair enough, that's computers talking to computers. But anything outside of that, there's people involved who will be using this. And you need to understand these people and how they do their daily work. and how this technology will fit into that, or not. That's it for me. I'm probably way ahead of time. Thank you. Thank you, Barry.