UX Research, Analytics, and Dark Patterns, with Luke Hay

In this episode of the Versioning Show, Tim and David talk with Luke Hay, a user experience professional and author. They discuss the meaning and purpose of UX, a day in the life of a UX professional, the value of analytics in UX research, looking beyond vanity metrics and drilling down into the details of user activity, starting UX research on a new project, dark patterns, carousels, and Evil Versioning.

Show Notes

• Check out Rollbar’s free Bootstrap Plan sign up offer
• lukehay.co.uk
• Luke on Twitter: @hayluke
• darkpatterns.org
• Researching UX: Analytics
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

UX is about … users, their everyday lives, how they interact with things. Obviously, the UI is a big part of that, but it’s also about things like their motivations to do things. Their overall experience with your software, your website, or your product.

---

User research is a particularly important part of UX. You can’t be a UX designer or a UX researcher without actually talking to users about their experience. It’s much more than just drawing wireframes or creating designs on websites or apps.

---

people often focus on the kind of what I think of as the vanity metrics — things like the number of visits that your website gets, looking at overall bounce rates for a website … that kind of thing … rather than drilling down into detail, which is much more useful

---

the analytics will generally tell you what’s happening, and then further research will at least give you an indication of why that might be happening.

---

I think the main thing about any form of UX really is understanding your users. It’s around finding out who your target audience is for your app, and then just talking to those people, really.

---

You can actually get real users starting to interact with and see how they get on with it, really, and see where there’s any clear problems there. I think that, in my experience, doing user testing on real users, you always get some sort of good feedback, and it’s often not what you’d expect.

---

the key for me is having real users interacting with things, because it becomes blatantly obvious if you’ve got users trying to perform some tasks and they will tend to use things completely differently to how you imagine that they will.

---

That’s almost a form of dark pattern as well — I don’t know if you’re familiar with that term, dark pattern. But the idea is there’s a design that’s made purely to essentially confuse the user, trick the user, make the user’s life harder for the benefit of the business.

Transcript

Tim:

Hey, what’s up, everybody? This is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number 27 of the Versioning podcast.

David:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

Today, we are talking with Luke Hay, who is a user experience professional and also a new author. We’re going to talk a little bit about his career, some of his expertise, and hopefully we’ll talk a little bit about a book in the process. So let’s go ahead and get this version started.

---

David:

I’m excited to tell you about a new sponsor of the show, Rollbar.

One of the frustrating things we all deal with is errors …

Relying on users to report errors, digging through log files trying to debug issues … With Rollbar’s error monitoring, you get the full stack trace, context, and user data to help you find and fix impactful errors super fast.

You can integrate Rollbar into your existing workflow; send error alerts to Slack or Hipchat; or, automatically create new issues in JIRA, Pivotal Tracker or Trello.

Adding the Rollbar’s SDK is as easy as copy and paste. Start tracking and logging application errors in minutes.

We have a special offer for listeners. Go to rollbar.com/versioning, sign up, and get the Bootstrap Plan free.

Loved by developers at awesome companies like Heroku, Twilio, Kayak, Zendesk, Twitch and more.

Give Rollbar a try a today. Go to rollbar.com/versioning.

---

David:

Luke, we’re really glad to have you on this show. Welcome.

Luke:

Yeah. Thanks for having me.

David:

This is the Versioning Show, and one of the things we like to do is start off with a philosophical question. Your philosophical question for the day is, In your current career, what version are you, and why?

Luke:

Nice easy one to start with, then! That’s a good question. I think I’ve gone through various versions. I’ve been in the industry for quite a long time. Been working in the web since the ‘90s, and gone through various different roles in terms of both analytics and then moving to UX and combining the two. I guess I’d say, at a push, maybe I’m version 3. I’ve gone from analytics to UX to a combination of the two, really, and having the two work together in tandem.

David:

Well, nice progress and room to grow.

Luke:

Yeah.

David:

Very cool. You are, as Tim mentioned, a UX professional. I know one of the things, it’s a classic question but everybody has a different explanation for how people can understand it. The distinction between UX and UI, when it comes to design analytics.

Luke:

It’s almost a controversial subject at times. I think people got very strong opinions about it. From my side of things, UX is — it stands for your user experience — it’s about much more broadly users, their everyday lives, how they interact with things. Obviously, the UI is a big part of that, but it’s also about things like their motivations to do things. Their overall experience with your software, your website, or your product.

David:

How would you visualize that for people? How do you make that tangible to folks?

Luke:

It’s a good question. A lot of the time, there’s various difference and diagrams. There’s a famous one that people often use, perhaps wrongly, where you’ve got two paths, and one’s a man-made path, and one’s people taking a shortcut, and that’s the one they says is user experience. For me, I’m not sure how helpful those kind of diagrams are, really. I think it’s more about the user experience being broadly around understanding your users and studying more about them as people. User research is a particularly important part of UX. You can’t be a UX designer or a UX researcher without actually talking to users about their experience. It’s much more than just drawing wireframes or creating designs on websites or apps.

Tim:

What would a typical day look like for you in this profession?

Luke [3:56]:

That’s a good question. I’m not sure there is such a thing as a typical day, but I like to think there’s a lot of variety in what I do. In terms of my approach, generally, as I’ve said in the book, it’s an analytics-first approach to UX. I start off, although this wouldn’t all necessarily be in the same day, I would generally start with projects looking at the analytics for a website we’re at. That could be Google Analytics or similar tools to that. Find out how people are using or interacting with it.

Other things that I might do in this hypothetical day, I might do more user research — so that’s actually user interviews, perhaps talking to users of software or a website or an app, or it could be stakeholder interviews. So finding out more about business from the key players within that business about what they’ve heard from their customers about how they deal within that side of things.

Some user testing — or usability testing — is another big part of what I do. So there may be some user testing, getting users to work through particular tasks on a website or app. That would be a busy but typical day, I guess.

Tim:

So you mentioned analytics, which is a topic that I find fascinating. I was wondering if you see any mistakes that people might make when they initially view a large pile of data like you would find in Google Analytics.

Luke:

Yeah. I think the first mistake that a lot of people make, particularly in the UX industry, is perhaps not using analytics as much or as often as they should do. Obviously, just my opinion on it. But a lot of the time, I think naturally people who work in UX got to work more directly with users or with design as a concept and aren’t so drawn to the analytical side of things. I think there’s an element of that — that it can be overlooked, and not used to its full potential.

In terms of getting started, as well, people often focus on the kind of what I think of as the vanity metrics — things like the number of visits that your website gets, looking at overall bounce rates for a website … that kind of thing … rather than drilling down into detail, which is much more useful — to find out how people are using particular sections of your website, or where they’re coming from, or looking at things like conversion rates.

David:

The line between the subjective and the objective I think is kind of subtle, when you’re talking about some of this, and I’m curious how you draw that — how you make the distinction.

Luke:

I think one simple way to look at it, which is perhaps oversimplifying it, is that the analytics will generally tell you what’s happening, and then further research will at least give you an indication of why that might be happening. I’ll generally use the analytics to spot that something seems a bit odd with the data, that perhaps conversion rate is particularly low on a certain type of browser, and then maybe do some testing with that — functional testing or, ideally, userbase testing — and try to find out what the cause is there. So, yeah, the analytics will tell you what’s happening, and the UX research side of things will attempt to tell you why that’s happening.

David:

I’m really glad that you made that distinction, because, every now and then, I’ll be working with a team that will tell me mostly users on an iPhone 6, using just Safari browser, will go to our site, so we need to optimize for them. And then I need to try and fight this battle of explaining that it could be that case, or it could be that your application or website is a gate that is preventing anyone without that browser or that device from accessing your content. I’m sure you do some consulting. I mean, you wrote a book on the subject. How do you teach people how to correctly interpret data?

Luke [7:32]:

I think that’s a really good point, the one you just made there, and I think that leads into finding out more. Looking outside of your own analytics as well. There’s a section of reports in Google Analytics, which are the benchmarking reports, and this will tell you what kind of … the performances of other websites within the same kind of industry, the same size as you, and then you can start to compare those things.

For example, just looking at the number of mobile users a website gets, you can use the benchmarking report and say, Well, at the moment, 20% of users that come to my website are on mobile, but actually you look at the benchmark for my industry, it’s more like 30%, and then you can start to find out why that is. I think the numbers are great for answering those kind of questions.

Quite often, someone will make a statement, and it may be a bit of a hunch, but unless they’ve got some dates to back it up, then it’s really just an opinion. So definitely using the data, as long as it’s from a source that can be trusted, and I speak a bit about that in the book, but if it’s from a source that can be trusted, then it’s something you can use with other people. It’s very hard to argue with those numbers, really.

David:

Actually, speaking of the book, one of the things I noticed was that you drove the book around the subject of analytics, and I don’t know if UX is always talked about with such a focus on analytics, and I’m curious about that.

Luke:

I think that is definitely an area that, in my opinion, is underdeveloped, really. It’s something that I think people should be using more of. I’m not suggesting at all that analytics should be the only form of user research you do. In fact, it should lead onto other types of research. It’s about having that sort of quantity of data and the quality of data working together, rather than just using one or the other.

Again, analytics, it’s a good way of solving arguments. If two people have got different opinions, quite often the analytics will show you which one is doing better. Later on in the book, I talk about A/B testing as well, which is obviously an analytical approach to design, in a way — showing two different designs to your audience, and then seeing which one performs better.

David:

Right, and I think the crossover between those is one of the reasons why people get confused sometimes about the distinctions between UX and UI analysis and design. So you came to this UX … what is your background? What did you bring to it?

Luke:

That’s a good question. I think my background started a long time ago. I’ve been working in the industry since late 1990s, really, and people were just sort of using websites back then. Here in the UK, it was fairly uncommon for people to have internet connections at home, and it was with dial-up accounts and that kind of thing, so the industry was very much in its infancy back then. And I got into it, helping out essentially a web company with their analytics as it was back then.

It was very basic information. It was the kind of metrics that I spoke about earlier. Perhaps the vanity metrics, in terms of the number of visits websites were getting, and that kind of thing, but it was at least an idea of how your website was performing, because without that, you were almost blind, really, and it was very difficult to know who was using your website, and how long they were staying there, that kind of thing.

So I really started off with a bit of an analytical background. A slightly technical background as well, doing some setups for new sites and that kind of thing. Working for a web hosting company for a while in between there. From then on, I went to work in-house for a couple of places. I worked both in-house and agency-side, and you can kind of get a good idea of what’s going on with a website if you are working in-house, because you’ve got a lot of time to spend looking at analytics and finding out what’s going on and really understanding not only the business but the customers or the users.

David:

Would you say that you’re primarily self taught, or did you bring a degree or education to this as well?

Luke:

Yeah, I’d say self taught would be correct, in terms of I don’t have much in the way of formal qualifications that are useful towards the UX and analytic side of things. But I think, also, I’ve been taught by a lot of people that I’ve worked with, either as direct colleagues or people like the UX community here in Brighton in the UK. There’s a lot of people here who I’ve learned a lot from. So it would be a bit disingenuous to say I was self taught, but I’ve learned from others along the way, and to say, in terms of formal qualifications, there’s not a lot there apart from the Google Analytics individual qualification, which anyone can take, really.

David:

I think that that makes you actually fairly typical of the guests that we have on this show. We find a lot of people who are professionals — advanced, respected in their fields, going out there teaching and leading huge projects — who don’t have what you would call formal credentials. And yet, their enthusiasm for the subject has driven them to learn about these things, and then go out and share their knowledge.

Luke [11:50]:

Yeah, absolutely. I think that’s the case here as well for most of the people I meet. I think purely because, as I said, we’re talking a long time — maybe 15 or 20 years ago — there really wasn’t any of those formal qualifications to take. It’d be interesting to see what happens over the next sort of 10, 15 years, whether you do see more people with more formal qualifications as more of that side of thing’s available, particularly in the UX and user-centered design field. There’s a lot of things now that actually I think I’ve been very interested in taking part in if I was ten years younger.

Tim:

Let’s say I am a new or an experienced web developer and I want to build an application. What sort of general advice could you give to me before I sort of get started coding away, in terms of UX and analytics-type of data?

Luke:

That’s a very good question, and, yeah, a fairly difficult one. If you’ve got any sort of application that’s already built, if you’re redesigning the application, then that’s slightly different. If you’re doing that, then, hopefully, you will have analytics running on the current application and you can start to see how people are engaging with it, learning their behaviors, perhaps spotting potential areas for improvement, that kind of thing.

If you’re starting from scratch, of course it’s slightly harder, but I think there’s still things you can do. I mean, I think the main thing about any form of UX really is understanding your users. It’s around finding out who your target audience is for your app, and then just talking to those people, really. It is a really good starting point, you know? Shadowing them to some extent, as well, if it’s some sort of work app that they’ll be using. Perhaps spend a day with them, do some immersive research, spend some time with them in their work environments, see how they normally do things, and how your app can actually help with that side of things.

Also, I’d recommend testing as early as possible, and when I say testing, I mean sort of user testing, usability testing, rather than functional testing. So it may even be that you have a very primitive sort of prototype of your app. You might want to build it in its entirety. There’s some good prototyping tools out there that you can use. You can actually get real users starting to interact with and see how they get on with it, really, and see where there’s any clear problems there. I think that, in my experience, doing user testing on real users, you always get some sort of good feedback, and it’s often not what you’d expect.

David:

As you mentioned, a lot of our audience tends to be on the technical side of things, and I’m curious, since what you do often interacts with technical folks, are there ways that you find are useful for people to build their products and build their tools so that they can work well with UX analysis?

Luke:

Yes, there certainly is. I think getting involved with each other as early on as possible is always good. There’s no use for the UX person coming along when you’ve nearly finished your app and saying, Oh, yeah, I want to do some testing on it, and then telling you you’ve built it all wrong. And the same the other way around as well. There’s no point a developer kind of getting some UX person in at the last minute to do some testing and kind of keeping their fingers crossed that it works as it should do.

So I think having someone from a UX background involved from the start of development is really useful, because you can get that kind of feedback from them. They can help you. Using their experience, they can sort of talk about best practice and that kind of thing. Also because they’re perhaps not as close to it all as a developer, it means that they may give it bit more of an unbiased opinion, whereas a developer might be head down and perhaps be too close to things.

So I think having that second opinion from someone who’s got a lot of experience working with users and also, as soon as possible, really talking to real users and bringing users into that design process.

Tim:

I guess as a follow-up question, what common pitfalls do you see when companies or individuals release new products or applications? Like when you’re just browsing around on your phone, what’s the thing that makes you throw up your hands every single time?

Luke [15:34]:

I think there’s certain websites and apps that are perhaps designed by committee. There’s too many people perhaps involved with it. There’s a lot of politics potentially going on in some companies where certain people — who maybe haven’t done the research, who haven’t spent the time talking to users — make design decisions, either just based on what they think looks better, or perhaps some sort of brand issue that they think it fits in better with the brand.

I think, I’d say that the key for me is having real users interacting with things, because it becomes blatantly obvious if you’ve got users trying to perform some tasks and they will tend to use things completely differently to how you imagine that they will. So, getting people involved at that stage means that you can miss out on that kind of thing.

I mean, in terms of actual examples of bad websites or bad apps, I don’t think there’s any particularly that spring to mind, or none that I want to talk about here, but I think, yeah, it’s really just using your real users to do some testing for you.

Tim:

I definitely have an example, and we can be controversial, but I’ve got to lay something down here, and I’ve got to get your opinion about it. I can at least stop obsessing over this issue. I go to Yelp a lot to get reviews of restaurants I’m about to go to, because that’s mostly what I do. Mostly what I do is write code and eat food. So every time I’m on my phone, on Yelp, they only let me look at like five photos before I’m forced to either tell Chrome to request the desktop site or download their app, which I have no interest in whatsoever. Luke, why do people do this? It’s terrible!

Luke:

That’s almost a form of dark pattern as well — I don’t know if you’re familiar with that term, dark pattern. But the idea is there’s a design that’s made purely to essentially confuse the user, trick the user, make the user’s life harder for the benefit of the business. That’s probably a good example there, in a way, with Yelp. Actually, they’re not doing what’s the best for the user, clearly. They’re doing what they think is best for the business.

Now, it’d be really interesting to see whether the negative outweighs the positive for them, I’m sure. It does mean that they’ve got millions of people installing the app, but it also means they’ve got millions of people, like yourself, who are actually quite annoyed with them and probably go elsewhere. Those kind of things, yeah, can be really frustrating, and I think that is where you put the business needs above the needs of the user. Obviously, there’s a nice middle ground to reach, but I think there’s, yeah, something almost sinister about forcing people to do things that they don’t want to do.

Tim:

I mean, it’s like the case that you outlined earlier. You know, the simple picture with the path and the foot path, right? That’s sort of like the prime example I see it as, you know? It’s like, you’re trying to get users to do this one thing, and they’re doing what I do, which is just request the desktop website.

Luke:

Yeah, exactly. All that means is you get essentially a worse user experience from it, and I’m sure if there was a good competitor to Yelp, then you would probably be using them instead.

Tim:

Yeah, they don’t even have to do much.

David:

I love that phrase dark pattern, and I’m curious. It sounds like that’s something that you come cross frequently in UX. Are there other familiar dark patterns that come across in mobile and web development?

Luke:

Yeah. I mean, there’s a whole … I think it’s darkpatterns.org, which lists all of them. There’s quite a few. We’ve all seen them. I think one of the probably most common ones is when you sign up to newsletters and you’re not sure whether to tick the box or un-tick the box because of the way it’s worded. It says, Tick the box to not receive our newsletter, and that kind of thing, so confusing language there to deliberately try and get people ticking or un-ticking a box and getting essentially the opposite of what they’d expect to see.

There’s things like sneaking products into baskets on e-commerce sites. So it may be that you’re buying a camera and they sneakily add a camera bag at the same time at the checkout and, if you’re not careful, you can actually end up buying something that you didn’t want at all. That’s another good example.

I think one of the other ones is the sort of easy-in and difficult-out. This is an example perhaps from the offline world, in a way. If you’re join a gym, it’s very easy to sign up. You can probably sign up online and just enter your details and then you’re signed up and good to go. But actually, when you want to cancel that gym membership, maybe you need to go down there in person or you need to send them a letter or something equally ridiculous. It’s not quite as easy to cancel as it is to sign up, and that’s a bit of a classic dark pattern, really.

David:

20 pushups or we won’t let you out.

[Laughter]

Tim:

You should change the acronym from UX to GUX, so it’s good UX, because clearly UX doesn’t mean good UX. You could be a UX professional and specialize in evil stuff, right?

Luke [20:04]:

Yeah. You could be a sort of dark UX-er, I guess, specializing in dark patterns. Fortunately, certainly speaking from experience, all the UX people I meet don’t really have that kind of outlook. I mean, to work in UX, you have to at least like people, or be able to tolerate people — to talk to them and to do user testing and that kind of thing. So it’s not a case of people getting to UX or businessmen who are kind of just trying to make as much money, at the expense of the users. In my experience, anyway.

Tim:

I have to say, though, if there was an evil UX conference, I would definitely go. I’d go for like three days.

Luke:

[Laughs] There probably is one. It’s probably all undercover. But yeah, I think, in a funny way, it would be really interesting to go to, to see these tricks and things, and certainly the fact is dark patterns do work, in some ways, from a business perspective. Just the simple thing of the easy-in and difficult-out. I mean, I’m sure there’s plenty of people around the world who’ve got gym membership who never go but just can’t be bothered to actually jump through the hoops they need to cancel it.

David:

Since we’re talking about negative experiences that we’ve had online, one of the sites that I have found that has a very awkward UX is Google Analytics, where you go and you try to find information. And I’m wondering to myself now as we’re talking about this whether or not they’ve structured it intentionally so that people don’t try to just casually go in and get the vanity metrics but they have to follow some sort of pattern to find the things that are important to them.

Luke:

It’s a really interesting point, I think. I’m probably not the best person to ask, because I’ve been using Google Analytics for more or less as long as it’s been around.

David:

I’ve been using Google Analytics ever since it was Urchin.

Luke:

Yeah. I mean, I actually find it relatively easy to use and relatively intuitive. Now, that may be because I’ve been using it for a long time, and I’m interested to hear you have as well, but I think I don’t know if it’s a deliberate thing or more just the fact that there’s so much information they need to get to there, it’s very hard to lay it out. I mean, if you try to use other analytics tools, then you’ll actually probably appreciate how easy in some ways Google Analytics is to you. But, having said that, I’ve had plenty of people, particularly in the UX industry, tell me that it’s very hard to use and doesn’t make any sense at all. Yeah, I don’t know. Perhaps more user testing before I would fall for Google Analytics there.

David:

That is a fair point.

Tim:

Luke, I’m sure that you have had to spend some time convincing people who want to employ dark patterns to not employ dark patterns. What I mean by that is, for example, every single company I work at asks me to build a slideshow and put it on the front page. Without fail, every single one. It’s a miracle, really. But, a lot of times, when I try to talk to my employers and explain to them why nobody clicks on these things — most often there’s a better way to represent data, those sorts of things — they come back not with, Well, here’s a study that says opposite. They come back with, Well, we feel, or I feel like it should be this way because that’s just … It’s a point of emotion, rather than a point of fact. I’m curious if you’ve ever run into that situation, and how you go about convincing people to look at data and successful studies and companies that have done the right thing and done well by it. How you’ve convinced people otherwise, or how you go about convincing people otherwise.

Luke [23:24]:

That’s a really good point, because, yeah, certainly the sort of carousel that you were talking about — the design carousel on the home page — that’s a classic one, because people are always keen to have that. Particularly if there’s lots of different people who’ve got a stake in the home page, because then it’s almost democratic. Everyone gets their say, as you rightly say yourself, they don’t tend to get many clicks. The are circumstances they do work in, but a lot of the time they don’t, and they’re more just a compromise that doesn’t really please anyone. You just have these things, and everyone’s happy because they can see their particular department or that particular product shown on the home page at some point, but yeah. Very inefficient use of space and other things that people sort of have banner blindness when it comes to those, and that kind of thing.

I think for me, the first step is, as you say, use evidence. Previous studies. There’s a few studies around carousels, some of which are actually often used but perhaps a bit outdated now. But there is information out there. You can try and convince people, This is what previous studies have shown.

The best way to do it, though, is to use analytics for that carousel. So put the carousel live on the page. Give it a week, or a couple of months, and then say, Ooh, look, you’ve only have three clicks on this and two clicks on that one. And then, that kind of data is really hard to argue with, and then the best way to do it I think is to do an A/B test, where you have that sort of scrolling carousel and perhaps an alternative, which might just be one of those images in the banner, or some entirely different type of navigational element on the home page, and then see which one performs better.

That works particularly well for e-commerce sites, because ultimately you can do that A/B test, and if one makes more money than the other, then you’ve got to have a very good argument and say why you should go with the one that doesn’t make you as much money.

Tim:

That’s an excellent point, and a great way to have those discussions. Listen, I know a lot of people who are listening to this show are going to want to read more about what you’re doing and find out more about you. How can people find you online, maybe even get in touch?

Luke:

Yeah, sure. My website is lukehay.co.uk, so that’s probably the best way to get in touch and find out a bit more about me. As you mentioned at the start, there’s a book as well, which is Researching UX: Analytics, which is obviously published by SitePoint. So that, for me, has been written for people who are either UX people looking to use analytics more or even, let’s say, developers who haven’t really been using analytics or not using it to actually help inform their design decisions. And that’s sort of the starting point for them, I think.

David:

Sounds great. Well, thank you so much for joining us on the Versioning Show today.

Luke:

Thank you very much.

[Musical interlude]

Tim:

I am really, really, really glad that I got to rant about Yelp.

David:

And I knew that evil Tim was going to dive into those dark patterns as soon as Luke mentioned them.

Tim:

Yes. That sounds … I mean, listen. I wouldn’t actually implement these dark patterns, but just knowing about them and to going to an evil conference, that’s like one of my dreams. Who wouldn’t want to go to an evil conference? You’d see the evil keynote, you get all the evil merch, there’s probably an evil after party. That’d be great.

David:

You know, that is probably not a bad way to market something like this. Maybe we should change the show to Evil Versioning and talk about the evil aspects of all of the things that our guests are doing.

Tim:

That would be really cool, and probably very uncomfortable for most of our guests. But I guess we can extend an offer. If you’re evil, let us know. We’ll interview you.

David:

I’ll tell you, my sister has always told me that her great ambition her entire childhood was to grow up and become the evil scientist, with the beakers and the green bubbling liquids and all of those things. Evil is attractive. Evil appeals to people, and knowing how to do evil, of course, teaches you how not to be evil, right? [Cheeky voice]

Tim:

I think we can justify it like that.

David:

Okay.

Tim:

With that being said, Luke is a UX professional, and that’s who we spoke to. [Laughter]

It was really interesting to see the many ways he goes about just the things that we don’t even think about. When I build something, I most often hand it to somebody else to consider the implications of how users will interact with this thing or how many times a certain button has been clicked on, and if that button has gone on to lead to a purchase ten steps later.

I’m most of all thinking of the immediate. If I’m building this thing so that it’s performant, or so that a user in a different country can both have access to it and that it can be translated to language that they speak. I’m not often thinking about the global picture, so to speak.

David [27:56]:

One of the things I know that always comes up, particularly when I’m doing front-end engineering, is how you’re going to instrument the app, and the instrumentation being where you put in the hooks that are going to catch what events are relevant and what matters in terms of what users are using and what kind of feedback you’re going to get. And sometimes I find it’s really useful to talk to the UX person in advance before even starting to build the interface, just as Luke said, because they’ll tell you where you need to put those hooks in and what things need to trigger some sort of response so that we can track metrics that are relevant.

Tim:

Yeah, and that type of communication is so imperative. We’ve often spoken about how whether you are a developer working with another designer or a product stakeholder or a user experience person, you absolutely need to get out in front and be proactive about that. Once you get the design and start coding is too late. Often, you catch things. For example, if someone is depending on a mouse hover for some pure business reason and that’s something that needs to happen, you as a developer might have a lot more insight into, Hey, not everything will fire a hover event, and therefore, we should probably re-think how we’re trying to capture this specific metric.

David:

And designers should be thinking about these things as well. In fact, in my experience, I’d say at least half the time, there’s been nobody on the job who was assigned to be a UX professional, but the designer took on that responsibility, and would do user testing and would build those aspects into the design so that we would know what to work with. It’s interesting, because almost never have I seen engineers take on the role of UX, but I’ve seen designers take it on a lot.

Tim:

Yeah. I think as developers and engineers or whatever the term is this year, we should really develop an interest in user experience, because we are almost closest to the front lines, in that aspect. We are building the interface that the users interact with, and I think it’s a bad excuse to say, Well, that’s not my job. This is what my boss wants and therefore I’m going to turn it into code right here and now. I think it’s responsible of us to consider the implications, how users are going to interact with this thing that we’re being asked to build and, if we find something that isn’t going to work or if it’s evil, we should say something about that. We should do what we can to make sure the work that we are producing is ultimately something that delivers the best user experience possible because everybody wins that way.

David:

Now I’m thinking about all of those bitter designers that I’ve worked with. The ones who’ve obviously spent hours and hours behind the scenes arguing and trying to fight the good fight until they ultimately lost and had to design something that had a dark pattern in it, which then got handed to the engineers and they had to justify it to the engineers. I’ve been in those conversations, and I’ve worked with those designers, seeing dark patterns that had to be implemented, and knowing that those discussions happened behind the scenes and knowing that was something that I could push back on at this point but it’s already been argued and decided.

Tim:

It’s a very demoralizing process, because, like we were discussing with Luke, very often you will have someone who appeals to emotion rather than facts or data and says, “I want this thing on the website or app because it appeals to me and I like it and therefore we have to put it there. Meanwhile, you might know for a fact that the feature implemented in that way is going to have a negative impact on what you’re doing. Not only is it bad for the company, but it hurts your pride, in a way, because you care about the things that you’re building. I mean, we all should, right?

I don’t think anybody is sitting around here just doing this to pass the time and pay the rent. And if so, I hope you find a career that you enjoy! But I certainly try to wake up every day and go to work thinking, All right, I’m really going to care about the product today. And that means that, if I get asked to do something that I know sucks, it’s not a fun experience and it kind of hurts a little bit, especially if it’s something that somebody says this is final and there’s no more arguing about this.

David [32:08]:

See, Tim, I knew you weren’t really evil.

Tim:

Or maybe I just want you to think that, you know?

[Laughter]

David:

Part of your nefarious plan.

Tim:

Yeah.

David:

One of the things that really impressed me about the way that Luke talked about that was the importance of using those analytics to make those arguments and make the case after the fact if you can’t win up front. Because often we’re in a situation we can’t win up front and, sometimes, it may even be subjective. We might not even know for a fact, maybe in this particular instance with this particular, unique audience — that gallery on the home page, that slider on every home page, — maybe in that particular instance, for that particular audience, that slider is going to make the difference between huge sales and no sales at all in a positive way.

Tim:

That’s true, and I think that’s why it’s important as a developer, when you are building something new, to always incorporate analytics, even if no one has said anything about it and that’s going to put more tickets onto your plate. It’s an important thing that you should speak up about it.

How are we going to track these interactions? Are we going to make sure we have something like analytics or in-page events that are making sure that we know when a user clicked on this button … or definitely clicked on this button, because sometimes you’re asked to implement share buttons and you really want that data to know in the future that nobody clicks on those things. They just share the URLs like the web inventors intended.

David:

It’s true. One of the things about Luke that really impressed me. He’s in a data analysis, UX role. He talked about data analytics and he’s not formally trained, just as many of the guests on our show have not been formally trained. And I know, back in the day, when I started doing web analytics, it was a new science and nobody really had any context for it, and I certainly wasn’t qualified with my anthropology degree. But your passion drives you, and you figure out what you need to know, and I love that Luke has taken on the responsibility of that and just gone out and taught himself and learned from the experts what he needed to know.

Tim:

Yeah. It’s just another testament to the fact that this industry at least aims to be about sharing knowledge and helping each other. No one is at this alone. We all depend on designers who depend on developers who depend on user experience professionals. I think that’s just another way that we can call continue to learn from each other.

David:

And there is some great resources out there, such as the darkpatterns.org site that Luke mentioned, and I know that I’m going to want to go and read his book again and take another look at the Google Analytics, the way that it’s evolved over the years, and see if I can’t make better sense of it these days.

Tim:

What I’ve definitely learned today is, well, I’ve been reminded to track everything. I’m working on building a product right now. I need to go and make sure all analytics and in-page events are being tracked, specifically because I really, really hate having to implement things that don’t work well for users. And if you often find yourself in that situation, then you should make sure that all of your things are tracked and hooked up to deliver data to business stakeholders as well.

David:

And data can come from all sorts of sources, and since user testing is one of those things that is, as Luke pointed out, kind of both subjective and objective, tweeting the company, giving feedback that is not in the form of a click but in the form of writing your feedback. That also gets pulled into the UX analysis.

Tim:

Very true. That means I should probably start mailing Yelp hand-written letters about how much I dislike the … I can even include screenshots, you know? Dear Yelp, please see attached screenshot. I do not like this. Sincerely, Tim.

David:

We are not going to maybe make a hashtag and get our audience doing that for you, are we?

Tim:

I mean, if someone wanted to do that on their own accord, I certainly wouldn’t stop them.

David:

Okay. Well, we’re not going to do that, so Yelp, you are not going to be spammed by the Versioning Show.

Tim:

Yeah, no, that would be bad. But what you should do is you should talk to us about dark patterns that you have found or dislike. Or not dark patterns; UX experiences that you’ve had that you particularly enjoyed. And also battles that you’ve won, because we all like to hear about developers, designers, and UX professionals who have fought the good fight and won and improved on the experience that a customer will soon have with the product or application.

David:

Yep. Let us help celebrate your story. Tweet us at @VersioningShow.

---

Tim:

Well, thank you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @VersioningShow — and give us a rating on iTunes and let us know how we’re doing.

Tim:

We’ll see you next time, and we hope you enjoyed this version.