This week on the Boagworld Show, we consider the post-click experience and how to integrate testing into projects.
Paul Boag: This week on the Boagworld show, we consider the post-click experience and how to integrate testing into your projects. This week's show is sponsored by Balsamiq and Fullstory.
Hello. Welcome to the Boagworld show podcast. All aspects of conversion rate optimization, user experience, and digital strategy. My name is Paul Boag, and thank you for joining me on the show, as every show, is Marcus Lillington.
Marcus Lillington: Hello Paul.
Paul Boag: Hello Marcus.
Marcus Lillington: I'm trying to type and talk at the same time.
Paul Boag: How are you doing?
Marcus Lillington: Failing.
Paul Boag: Don't. You know that the listeners get stroppy when we spend too much time with the chat room people.
Marcus Lillington: I know.
Paul Boag: So it's like, I feel like it's turned into the Montagues and whatever it was in Romeo and Juliet. The two sides.
Marcus Lillington: Oh, blimey, you're showing your academic past there, Paul.
Paul Boag: Well, not really. I only managed the Montagues. I couldn't remember who the other lot were, so I'm not that. And that's only from the, what was it, the DiCaprio version of it. That one, the modernized version.
Marcus Lillington: Yeah, and there was a-
Paul Boag: Capulets, that's it.
Marcus Lillington: There was a Western version of it as well, sort of cowboy families. I can't remember what they were called either.
Paul Boag: Ah. Don't talk about Westerns.
Marcus Lillington: Why not?
Paul Boag: Because we are teetering on the edge of the release of Red Dead Redemption 2. So if anybody talks about Westerns, I get over-excited. And I've been watching loads of Western films to get me in the mood like Hateful Eight and The Magnificent Seven. And so I'm ready to go.
Marcus Lillington: Very different style of Western, those two.
Paul Boag: Yeah, they are. Yes. Yeah, absolutely. Well, Hateful Eight is interesting. It's nice. It went from being really, really slow in places to then gratuitously violent in sudden bursts. It was a good film. I enjoyed it.
Marcus Lillington: You'll never beat The Good, the Bad, and the Ugly for me. One of my favorite films of all time.
Paul Boag: That's very good. And I have to say when I said The Magnificent Seven, I was talking about the remake with Denzel Washington in.
Marcus Lillington: Oh, don't think I've seen that.
Paul Boag: It's good. It's not bad actually. It's not bad. Obviously it's not as good as the original. Goes without saying. But it's till not a bad film.
Marcus Lillington: I haven't seen that in years. Yul Brynner was in the original, wasn't he?
Paul Boag: Yes.
Marcus Lillington: Along with a lot of other very famous people. I do like a Western, a good one.
Paul Boag: It's a bit like that. So it's got Chris Pratt in, from Guardians of the Galaxy, and various other famous faces that you would recognize if you saw them, whose names all escape me.
Marcus Lillington: Me too. Blokes, mostly.
Paul Boag: Oh yes, yes. All blokes I think. Was it all blokes? I think so
Marcus Lillington: I can't remember now.
Paul Boag: But what I did quite enjoy, and this is the kind of comment that may get me into hot water, was the contrast between how Hateful Eight approached the black role of Samuel L. Jackson compared to Magnificent Seven and the role that Denzel Washington played. Because hateful Eight is very real to the time, isn't it? And it's quite jarring in places the way they talk about Samuel L. Jackson, while Magnificent Seven just ignored it. Right? You know. Denzel Washington, there was no reference to his ethnic background or anything like that. So it was quite interesting to see those two different approaches to the issue. Which I haven't got a problem with either approach.
Marcus Lillington: If you're telling a story crosstalk 00:04:10 It's license, isn't it? They've got a license to do that.
Paul Boag: The only time it annoys me is in Doctor Who when they travel back in time, because in Doctor Who it depends on who's written the story as to how they deal with it. There's no consistency. So in some episodes, they completely ignore color, which is fine. And then in other episodes, they reference it, which is also fine, but not in the same continuity in the same universe. It annoys me. But then Doctor Who was never big on continuity anyway, so not that big a deal, is it really?
Marcus Lillington: Tom Baker was my last Doctor Who anyway, so I don't really-
Paul Boag: You said you were going to try starting watching with Jodie Whittaker. Have you not done that?
Marcus Lillington: I did, didn't I? No.
Paul Boag: Yeah.
Marcus Lillington: That's the short answer.
Paul Boag: Two episodes have come out.
Marcus Lillington: Yeah, I could catch up, couldn't I?
Paul Boag: Yeah, give it a go. I mean, don't get me wrong. It's family entertainment, so it's the kind of thing you should be able to sit down and watch with your nine-year-old. So don't expect anything to make any kind of sense, but it's kind of fun. I kind of enjoy it, and I think she's brilliant. I'm really enjoying her. By far the best Doctor for me since Tennant, David Tennant. So yeah, I'm enjoying that. She's brilliant. What else was I going to talk about?
Marcus Lillington: I don't know, but it's only been two days since we last spoke to each other. Nothing has happened at all.
Paul Boag: I know.
Marcus Lillington: Nothing, zero.
Paul Boag: Actually for me, quite a lot has happened. I've been very busy.
Marcus Lillington: I've been busy? Does that count?
Paul Boag: Well I went to a conference yesterday, which was a really good conference. It was UX Bournemouth, which I know sounds a contradiction in terms, Bournemouth and good, but it was actually pretty enjoyable.
Marcus Lillington: Nice beach. It's a lovely beach.
Paul Boag: Nice beach. Yeah, nice beach.
Marcus Lillington: Ed lives in Bournemouth.
Paul Boag: So we had, who lives?
Marcus Lillington: Ed does.
Paul Boag: Ed? Yeah, yeah, yeah. So we had, it was a really good conference, some really good speakers. Very user research focused, which was interesting. I was a bit of the odd one out speaking there because I don't like people, so speaking to users is an abomination, as far as I'm concerned, but there you go. Apparently it's a thing you're supposed to do. Who knew?
Anyway, what was really interesting was that there was one particular speaker, a lady called Brooke Baldwin, who works for Facebook. And she didn't talk any theory at all. She just talked about what she does on a day to day basis. And to be honest, if I did what she did, I would go round telling the world what I do as well. Because essentially, she does user research for Facebook in emerging markets, which essentially means she spends her life traveling around the world going to places, really exotic, exciting places, and doing user research. So that's what she talked about, and it was brilliant. It was so interesting.
Marcus Lillington: How do you get that job then?
Paul Boag: Well, to be honest, I think it's quite a hard job, to be fair to her. Because I mean, they have to worry about things like is it safe to go to this country or will we be kidnapped?
Marcus Lillington: Oh, no, I don't want that job. No.
Paul Boag: Yeah, exactly. And they end up working really long days, 12 to 15 hour days and that kind of stuff. But still, you get to go to really exciting places at the same time. So no, the reason I bring this up is because it ties in very nicely with something we were talking about in the chat room in Slack, which is what should we do on next season of the podcast? One of the suggestions that somebody made, and I'm sorry I can't remember who it was because, you know, people again. Was that we do a season on what exactly is it that you do every day, you know? Where we talk to different people and just talk to them and ask them, okay, no theory. No kind of, what do you do when you go in to work every day? What actually happens?
And I think that would be a really interesting season because there's so many people like, well, like Brooke. I wouldn't know what a user researcher does on an average day because it's such a specialist discipline. Or even some of these more high profile people like, I don't know, Jeremy Keith, for example. What the hell does he do all day? Do you know what I mean? That sounded very judgmental, and it wasn't meant to at all. Because you could say the same thing about me. I mean, what do I do all day? So I think it's quite an interesting series. Talk to people that have either a very unusual roles or very specific roles within an organization, or alternatively, people that maybe have reached a point in their career where it's all a little bit woolier what they do. And I think that might make a good season. What do you reckon?
Marcus Lillington: Absolutely spot on. I mean, I couldn't answer that question.
Paul Boag: No, it would have to be, yeah, I know, because every day is different.
Marcus Lillington: It totally is.
Paul Boag: Yeah. But we could even talk about that, and that's okay to talk about. But what you don't do is, because these people that you hear a lot from, and I include myself in this, we talk a lot about theories and principles and what other people should be doing, but we don't talk a lot about what I'm doing. When I finish doing this podcast, now what am I going to do? And the answer is I'm going to have probably quite a difficult conversation with a management team about some design prototypes that I've created for them. But nobody knows that, and I just think it would be really good.
Marcus Lillington: Okay. I'm going to do a stakeholder interview. That's the next thing I'm going to do. Over the phone. But it does change. It varies a lot. Interesting. I've known you, sorry, reading out from the chat.
Paul Boag: Yeah, this is Ryan in the chat room being a cheeky bugger. He's known me for ten years, and he still has no idea what I do. Fair enough. Hands open. I tell you what, Ryan.
Marcus Lillington: That's the reason we need to do this season of the show.
Paul Boag: Yeah, and Ryan, you can come onto the show, and you can interview me about what I do. How about that? Does that sound like a good idea? I think that would be great. Get Ryan back on. It's been a long time since we've had him on the show.
Marcus Lillington: He's a good guy.
Paul Boag: Yeah, I thought you would be. Yeah. So let's do that. All right, so that's next season sorted out, which is really good.
Marcus Lillington: Lovely.
Paul Boag: But we haven't finished this season yet. We're only on episode twelve, and there are 15 episodes in the season. So Marcus.
Marcus Lillington: Hello.
Paul Boag: I know it's a bit difficult for you because that means only two days ago you had to come up with some content, and now you've had to come up with some more. But do you have a thought for the day, Reverend Lillington?
Marcus Lillington: I do. I'm not the first Reverend Lillington. That's a lovely thought, isn't it?
Paul Boag: Oh no, you're not, because your dad is, isn't he.
Marcus Lillington: Yeah, was. He's not been with us for a long time.
Paul Boag: Oh I didn't, Marcus, I should have known that. That's terrible.
Marcus Lillington: That's okay. You've thrown me by calling me Reverend Lillington.
Paul Boag: Oh, sorry.
Marcus Lillington: What was I going to say?
Paul Boag: Reverend. Reverend Lillington.
Marcus Lillington: Lillington. I still can't say my name. Even I can't say it.
Paul Boag: You are probably the most irreverent person I know but we'll skate over that.
Marcus Lillington: I did realize at about 1:00 that I needed to come up with some content for the show. I've been pretty good so far. I have like a weekly reminder on a Friday afternoon, think of something. And then I realize because we did this two days ago, oh dear. I need to come up with something. And then I realized I was right in the middle of planning a site review, so I thought, well, I could talk about that because it's top of my mind.
Paul Boag: Yeah, absolutely.
Marcus Lillington: And they can be a bit daunting. So I thought I'd share my thoughts on them. I'm at that stage of, "Oh God, I've got 50 pages to write," or however many it's going to be. What am I going to talk about? So I've got a bit of a structure going, and I've had some thoughts on it. And I thought, well, I'll just share my general approach to how I do these kind of reviews. So just various points. First on being, don't state the bleeding obvious because you're wasting everybody's time by doing that. It's, for example, if a site isn't responsive, don't spend a days just showing how it doesn't work on mobile. Everyone including the client knows that that needs to change, so don't spend ten pages showing them how bad it is on mobile. I suppose another example would be something like broken site search.
Paul Boag: But you're not saying you shouldn't mention it at all because what's obvious to one person isn't necessarily obvious to another.
Marcus Lillington: I've already written the intro to this review that I'm doing at the moment, and I've kind of covered all the things that we don't really need to talk about a lot in the introduction.
Paul Boag: Oh, okay.
Marcus Lillington: So you do need to mention them.
Paul Boag: Yeah, yeah, yeah.
Marcus Lillington: But don't linger on them. You need to, I guess you need to focus on stuff that's maybe more controversial, that needs, you need to persuade people needs to change.
Paul Boag: Yes.
Marcus Lillington: Find evidence for and that kind of thing. Another thing that I found useful lately, and this is, Chris started doing this. Chris always comes up with good ideas, and I steal them. Get help from somebody else in the team. Not just from somebody when you finish writing it and get them to review, I mean, a second pair of eyes right at the start just firing through the site. Just bullet pointing, "That. I don't like that, oh, that's wrong, da, da, da, da, da." And that can maybe show you stuff that you hadn't thought of. So that's a really useful thing. I've got Lee doing that right as we speak. He might be doing that, or who knows?
Paul Boag: So hang on a minute. That sounds very much like you're basically getting Lee to do your work for you.
Marcus Lillington: No. It's a very kind of simple, just a Google sheet of just kind of brain dump, go through the site and brain dump some stuff. No real thought behind it. It's just to kind of give me pointers of things I need to kind of validate the points that I've already decided I'm going to talk about or show me stuff that I hadn't thought of. So it's just getting two insights, really useful.
Paul Boag: Okay, fair. I'll let you off.
Marcus Lillington: Than you, Paul. The next one would be have at least a brief look at analytics. We tend to do separate, more focused analytics reviews, but I would still have a little look at analytics for a standard site review. This is more how I work, and it might not work for others, but I kind of do a mixture of planning, so I'll try to kind of get a table of contents, the structure of the document. But alongside of it of just going for it. I tend to find that if you start reviewing a site, you'll go down rabbit holes, and why not? You might find some gems doing that.
So what are the type of things that I like to look at? Internal focus is a classic, when you're trying to be more user-focused. A general lack of focus, what's the site for? Most sites don't it's not obvious what they're for. Information architecture, navigation, that kind of thing can often a bit confusing and broken, generally. Copy is a really big one, things like density, scannability, readability, focus on users, that kind of stuff. Calls to action, accessibility, engagement, and often an overlooked one is performance.
Paul Boag: Yes.
Marcus Lillington: They're the kind of things I try to focus on, general subjects. I think it's really important to show real examples of what you're talking about. The old adage of a picture is better, one picture is better than a thousand words. So yeah, don't just prattle on in text. Provide real examples. And finally, probably most importantly, the most important thing is don't just state what's wrong. Make recommendations about how the different wrongs can be righted. And that's it for this week.
Paul Boag: Yes. I mean, do you ever, sometimes I find myself, I wrote a review for a large multinational e-commerce company a while back, and that went in a very different direction because I didn't end up talking that much about the user interface. Because the user interface was competent, you know what I mean? It was okay. But what quickly became apparent from talking to the client and looking at the site is that they had underlying organizational issues that were, they weren't doing any multivariant testing. They weren't evolving the site in any way. They just wanted to hire me as an outside expert to come in and tell them all the answers instead of having a process to create those answers. So that went in a very different direction, that one, because I ended up talking more about what was going on behind the scenes than actually the website itself.
Marcus Lillington: Governance review that would be, wouldn't it?
Paul Boag: Yeah. Do you always separate that out as a separate thing?
Marcus Lillington: Yeah.
Paul Boag: Well, that's understandable.
Marcus Lillington: I think that it might be once you've delivered this review, because this is nearly always the first thing, one of the first deliverables in a project. It might point, as I've just said, make recommendations. In making those recommendations, people might go, "Oh, yeah, but we can't do that because of X, Y, or Z." And at that point, you can then say, well, you need to fix that.
Paul Boag: Yeah. Paul's asking in chat room, do you actually explain, when you talk about things being broken or wrong.
Marcus Lillington: That's why you need real examples.
Paul Boag: Do you put a justification in as to why you consider that wrong, and then kind of explain behind it?
Marcus Lillington: Just that I'm right and everyone else is wrong, usually. No, I do.
Paul Boag: That's what I presumed.
Marcus Lillington: I try to.
Paul Boag: Yeah, you need to, it needs to be, a site review needs to be as much educational as anything else, Paul. So it should absolutely explain what's going on behind the scenes as well.
Marcus Lillington: Yeah, don't assume anything.
Paul Boag: Yeah, exactly. Right. Okay.
Marcus Lillington: Yes, Ryan?
Paul Boag: Are these reviews paid for by the client? Absolutely, Ryan, yeah, yeah, yeah. And that is a big mistake I see people making all the time, is that they don't charge for this kind of stuff. They're kind of giving it to the client for free. And you know, but, and that means that it's kind of, you're not spending that long on it, and you're-
Marcus Lillington: No, charge. I'll come back to that as another thought for the day. Ryan has asked, how do you convince them to invest the time? That's a long answer that I'll come back to, but I would say that we will do kind of mini-reviews as part of proposals. That's something to sort of show the kind of depth that we might get into, but not a complete site review, no. That's something that should be paid for.
Paul Boag: Okay. We probably should move on, as there are many other things, although I would agree that's one worth coming back to, Marcus, convincing people to do them, and then what you do for free, and what you don't do for free I think is also another interesting subject that we could get into in all kinds of areas, not just in site reviews.
Right, let's talk about Balsamiq. I have spent most of my day today talking about what we do in Envision, which is some people see as a Balsamiq competitor. But it's absolutely not. Something like Envision is an incredibly powerful tool that you can use to easily show clients designs, produce your designs in either their Envision Studio, or in Sketch, or in Photoshop, or whatever else. You then put them into Envision, and you can kind of join up those things.
That is absolutely invaluable for testing high fidelity prototypes, but it is not so good for those very early conversations where you want to start brainstorming with clients, and you want to start wire framing things up in a very, very quick, very, very simple way. Now obviously ideally one might argue that you sit down together in a meeting and you do that, and absolutely, that is invaluable to do, and you should do that. However, that's not always possible, and sometimes you need to do those kinds of things remotely, and Balsamiq is incredible for doing that kind of remote, very quick and dirty wire framing.
However, I would argue that even if you are sitting in a room with a client, some clients, a lot of clients do not like drawing. They don't like putting stuff on a board. They feel intimidated by that. So actually, giving them a tool that is just so intuitive to use where they can drag and drop a calender widget onto the page, and they can drag and drop this element onto the page. That is invaluable, and that's obviously what Balsamiq does incredibly well. On top of which, you can move those elements around so you're not constantly redrawing stuff all of the time.
So definitely give Balsamiq a go for that very early wire framing and prototyping, working collaboratively with clients, with developers, with other people that aren't so comfortable with design tools. As a professional designer, sure. You're going to want to be in Sketch. You're going to want to be using Envision or these various other tools out there. But when you deal with clients and colleagues, you're going to want something much, much more intuitive, much more basic, much faster to work with.
Marcus Lillington: I think that's true.
Paul Boag: You can try, yeah, it is. I don't make this stuff up, Marcus.
Marcus Lillington: All right, I'm backing up what you're saying with a real example, as I was referring to earlier. We, I can't remember the last time we did any drawn wire frames. It's not a thing. And the point you made about the fact that you can't replace stuff easily I think is the key one. Because we often start wire framing something, and people go, well, that's not right. So you need to change it. And it's like, what do you do, throw it in the bin? It's just more efficient.
Paul Boag: Yeah, exactly. Right. Okay, so to give Balsamiq a go, you can get a 30-day free trial by going to Balsamic.cloud. If at the end of that 30 days, you think, "Oh, this is good, I'd like this," then when you sign up for the billing, if you use the code Boagworld, you'll get the first three months of that absolutely free. So that's a great way of kicking it off, using it on a longer term basis. So check out Balsamiq.
Right. So today I want to start off by talking in our series on conversion rate optimization, talking a little bit about the post click experience. So what happens when you eventually persuade somebody to complete your call to action? So they've added something to a shopping basket or they've started the form filling that they've got to do to submit whatever to you, or they've signed up for your app, or whatever it is? That post click experience is as important as the actual initial click. There is a damn good reason why people routinely abandon shopping carts, and that's because the shopping cart and check-out process often isn't as optimized as it could be. And you see the same thing in all kinds of sites, from making a donation on a charity site to onboarding on an app, whatever it may be.
Marcus Lillington: That's a classic. The donation on a charity site. You have this wonderful website that's beautifully designed, and the copy is great, and it encouraged you to click to make a donation, and then you go through to some third party app that might have a logo on it, different URL, and it's just generally hideous.
Paul Boag: Yes.
Marcus Lillington: Perfect example.
Paul Boag: Absolutely. And it's not surprising that something like only 18% of people that hit a donation process. In other words, they've already expressed a desire to donate. Only 18% of those people then finish that donation process, and I think that kind of says it all, doesn't it, really? And the same is true with shopping basket on e-commerce sites and all the rest of it.
So what do you do to help people? Well, the first thing is to provide positive feedback, okay? So one of the kind of things that we're taught, and it's something that I'm actually going to refer to later. Let's start with that. The first thing that you're taught when it comes to these post click experiences is remove distractions, right? So if you go into Amazon, and you start checking out, suddenly all the other options disappear. It's very much focused down on what you're doing. That is 100% right, and I have seen too many people using that post click experience as an opportunity to start getting people to do other things. So for example, "Oh, you're checking out on this website. Create a password so you can come back later." And it's like, no, people just want to finish what they're doing. At the end of the process, sure. Now ask them for a password. That's fine. Or they're going through the process, and they have their check boxes. Oh, can we spam you with email? That's not the time to ask. Ask them at the end of the process.
So making that a clean experience is absolutely vital, but that doesn't mean that when you strip all of that out, the one area where I make an exception to that is to take the time to provide people with positive feedback, to say to them at that point, your decision to start this process is worth doing. And it's worth finishing. So that might be something as simple as actually thanking people. So as I've said many times before on this show, my company, Boag Works, supports a charity in India, which is a very small charity that supports education for people that are incredibly poor in these very rural parts of India. Now I created their website, and all I had to work with was Squarespace, so it's a very basic website, and you can see it for yourself. Bethesda-project.org. Now when someone clicks to say I want to make a donation on that, what they're taken through to is a page that starts by thanking them. Where they haven't yet done it. They haven't yet finished the donation process, but by acknowledging their desire to donate, you reinforce it and make it more likely that they complete that donation process, right?
And it may seem like a stupid thing, nut it actually works, and I can prove it works. There was a scientific study where there was an honesty jar in an office environment. People were supposed to put money in the honesty jar if they had a tea or coffee. Okay? What they started doing is one week they would put a picture of flowers above the honesty jar, and another week they would put a picture of a pair of eyes looking at people. Right? And when that pair of eyes was there, the honesty contributions shot through the roof. Right? So in other words, when we are seen to do something, we carry on and finish doing it. Even if we're not really being seen, but just being given the impression that we're being seen doing it, like showing a pair of eyes or thanking people for their willingness to donate. So positive reinforcement like that works, but also there's the positive reinforcement with things like social proof or where you say things like you get a money back guarantee, so why not buy? All of those kinds of things. Anything you can do to positively reinforce people.
The other thing you need to look at doing is providing people with a safety net during that post click experience if something goes wrong, so make sure you've got a telephone number really obviously shown or a live chat facility or something like that in case people have a problem. And don't feel that you need to get people to do everything in one go. So a lot of times you might need quite a lot of information from people, and so you create these bloody long forms that are really intimidating. But actually, you're much better breaking it down into smaller steps, okay? Because people still like to feel a sense of momentum. So you're much more likely for them to keep persevering if they're kind of moving on to the next thing, moving on to the next thing, moving on to the next thing, rather than getting stuck on one big thing. So often breaking it down like that works very well.
And then obviously, a big part of any post click experience is getting that form designed right. So all of those principles around good form design are hugely important as well. Now there have been entire books written on form design, so I'm not going to begin to try and talk about all of that now, but there are a few things to mention. For start, have really good defaults. So for example, if your post click call to action involves people specifying a country that they want it delivered to, and you know that 80% of people are ordering from the United Kingdom, please make sure that drop down list defaults to the United Kingdom. Don't have it defaulting to Angola because that's the first one on the list. And also, only have things in that drop down list that actually are countries that you are going to deliver to. Don't put Antarctic in your list just because you copied and pasted a country list. Anyway, I'm getting into, I'm getting off track now and just ranting about country drop down menus. But that idea of having good defaults is a really good one, right?
Marcus Lillington: It is, yes.
Paul Boag: Then make your forms forgiving as well. So I went to a website once where I entered my post code, DT11 7PP. You now know my post code. Well done. Probably shouldn't have announced that on the podcast, but there you go. So I typed that in, and it didn't work, right? It said you have not entered a valid post code. So I typed it in again. DT11 space 7PP. Still didn't work. And I went round and round, and I typed it all in capitals. Still didn't work. I typed it all in capitals with a space in. Still didn't work. And the problem was is it wanted it all in lower case, but I was doing it on a mobile device that was automatically capitalizing the first letter. So it didn't work.
That is what I call an unforgiving form. Don't make that kind of mistake. Remove the spaces. If you want it in the database all nice and clean, remove the spaces at the back end. Don't force the user to do that. Don't split telephone numbers over multiple fields. Don't even split names over multiple fields. Do the work at the back end. Make it easy for the users.
Another thing with form design, don't use multiple columns. Makes it much harder to scan, and don't have the label and then the field next to it. Instead, stack the label above the field. It's much easier to scan, and it's much easier to navigate between fields that way. Don't forget to clearly distinguish between your optional fields and your required fields. Or even better, drop the optional fields. Only have required fields. Validate your form as it goes so that people don't get to the end, hit a button, and then get all the errors thrown back to them at once. That's horribly intimidating and depressing. Instead, validate as they complete each field.
Marcus Lillington: I had to do an inaudible 00:34:07 form recently. My inaudible 00:34:08 ran out. That's a lovely one where you have to declare that you're not a drug dealer or a terrorist and all this kind of thing. But it is literally, it might have seven pages. Every single one, error. And then you have to hunt around for where the error was.
Paul Boag: Yes, absolutely.
Marcus Lillington: I think it's deliberate. I think they enjoy it. It's meant to make you feel-
Paul Boag: Well, there is actually an argument for it in certain situations because what they're doing there is they're increasing cognitive load by making the form hard to use. And that means you're likely to make less mistakes. So anyway, that's beside the point. So yes, so things like validate as you go. When you validate as you go as well, don't just go, "Eh, you've got it wrong." Also put a little tick next to it if they've done it right. Positively reinforce them as well.
And I could go on and on. People in the chat room are asking all about labels that are within the field, like placeholder text. Yeah, placeholder text is fine, but not as a label. Use a placeholder text as an example of what they should be entering, not as the label that then disappears when they click in it. Just all of these nuances. Form design is an incredibly, it sounds really, really boring, but it's an area that I get really excited about because it's actually really challenging to get right. So yeah, hugely exciting area. There's some great books out there as well that you should check out. But think about that post click experience and how you optimize it. Spend as much time on that as you do on the main experience. Right, I think that's all I've got to say on that one.
Marcus Lillington: Good stuff that was, Paul. I love form design as well. Obviously, we work with a lot of charities, so.
Paul Boag: Charities.
Marcus Lillington: Getting their donation forms right. It's something that continues as well. You think you've got it right, but the RFPF one, for example, that you did the kind of UX work on years ago.
Paul Boag: Yes.
Marcus Lillington: Has changed and changed and changed and changed. It keeps being refined. So that's-
Paul Boag: And that's why, what that signals is the value of AB testing, right? Because I don't consider myself a thickie. I've been doing this for a while. That form that I designed crosstalk 00:36:29
Marcus Lillington: Such an invitation, Paul, but I'll try.
Paul Boag: Resist it. That wire frame I did all the way back then, it was good. I remember it still, and it was a good design, and I was really proud of it. But nothing stands up against the reality of real users in a real situation. So you know, that's why these things will continue to evolve and change.
Marcus Lillington: Cool.
Paul Boag: Right, talking of monitoring, evolving, and changing, oh, I'm proud of this segue. Let's talk about Fullstory! Fullstory is the next generation of analytics, in my humble opinion. In my opinion, it's the best analytics tool that I've ever used because it kind of combines the great power of statistical large-scale analytics with the ability to look at individual sessions as well. It's kind of got this page insights feature in it, which is like a tool kit for you to learn everything you need to know about how users interact with a specific page on your site.
So it's got click maps. So you can see a heat map, but without the kind of splotchiness. I never did like that splotchiness where it shows red and green and yellow, and it's like, uh, what's that mean? Red is good, I guess, but how good? Well, they have click maps, which are much more accurate, so you can see what people have clicked on, how many people have clicked on it, all of that kind of stuff. And you can look at rage clicks. You can look at errors. You can look at dead clicks, whatever you fancy. And if you see something interesting, you can add it to your search, and that allows you to dig in even more.
Then of course there's inspector mode, where you can watch and replay any session and decide if you want to add a new button or text field to clarify what you're doing. You can enter that inspect mode directly from search or from a click map or anywhere else. So it's so powerful. I really do love it as a tool. You can sign up today and get a free month of their pro account. No need to enter a credit card. You can continue using it even after that month up to a thousand sessions per month, but obviously if you want to pay for more sessions, you can absolutely do that. So you go to fullstory.com/boag to try that out.
So we have established how important testing is. That was the last thing that came out of Marcus's mouth, and he has segued beautifully into the next part of what I want to talk about today without even realizing it because he never reads the notes.
Marcus Lillington: Such a pro.
Paul Boag: Yeah, but are you? Or was it just luck?
Marcus Lillington: Of course it was luck. I haven't got a clue. I didn't read the notes.
Paul Boag: No, exactly. I'm glad you admitted it. So everybody bangs on, "Oh, you should do testing." Right? But it's so easy to say, isn't it, and it's so hard to make a reality and project. I know the project that I've been working on recently, it's going to be hard to get them to test it. And so some of the testing I've just done under the radar, but they really need to do some more as well. But often I find if you do a little bit yourself, if you experiment with testing and you just do, even if it's not very accurate, not particularly good, if you just do it on your own dime and your own time, then it kind of gets them into that mode of thinking, and they buy into it. So instead of speculative design, try speculative testing, the future of the web. There you go. I like that.
Marcus Lillington: Oh, you've come up with a new term, Paul. I came up with a new term the other week.
Paul Boag: Did you? What did you come up with?
Marcus Lillington: Well, I think it's a new term. It probably isn't, and everyone's going to laugh at me. I coined the term research sprint, which-
Paul Boag: Oh no. That sounds good, yeah. Yeah. A research sprint, I like that. It's better than a discovery phase. The problem that I have with the discovery phase is it always sounds like "Yeah, basically, we want you to pay us a lot of money for us to work out what the hell is going on."
Marcus Lillington: We've got no idea, so pay us while we work it out.
Paul Boag: We're clueless. Yeah. So we need a discovery phase, please. Yeah, so I prefer a research sprint. I like that. Anyway, so yes.
Marcus Lillington: Testing.
Paul Boag: So what type of testing could you do to get the ball rolling? Well, you could actually test right from the very beginning. So let's say you're working on a fairly boring, typical project. So you don't get to work in an agile way, and you don't get to do any of these kinds of things you know you're supposed to do, but you never really get to do. You've been asked to produce a design comp, to go into Photoshop, to go into Sketch and produce a design. Well, if you get yourself into that kind of situation, you're inevitably going to end up in that conversation of, "I don't like the green. Can you change it to blue?" And that kind of thing.
So one piece of testing you can do to help with those kinds of aesthetic opinion type disagreements is something called a semantic differential test or a semantic differential survey, which is a very, very pretentious way of describing a very, very simple idea. So what you do in this survey is before you do any design, right at the beginning of the project, you get them to write a list of words that they want the design to communicate. Now actually, Lee came up with a really good exercise to do that, which is a reception rumor exercise, where you get them to design a reception room, what the furniture looks like, what the art is on the wall, what music is playing, and all that. And out of that will come a set of words like minimalistic or relaxing or those kinds of words.
Marcus Lillington: Clean, lots of space, yeah.
Paul Boag: Yeah, yeah.
Marcus Lillington: What we've learned over the years, we do that with every single client on every single kickoff, is what you're hunting for are the different words, the kind of things. Because everybody says they want it to sort of be clean and airy and all of that kind of stuff. But occasionally you'll get some gems that you really can as a designer kind of pull into your process and make something that is slightly different to the competitors.
Paul Boag: Yeah. But even those minimalistic and other words, you need them as well.
Marcus Lillington: From a testing point, yeah.
Paul Boag: From a testing point of view. So what you'll end up with is a big-ass list of, hopefully not too many, because if you end up with too many, it's like, we want the design to be everything! So a small list of words.
Marcus Lillington: Prioritize.
Paul Boag: Yeah. Well, I don't care so much about the prioritizing, but we take the top number. I'm not saying you're not right about the prioritizing, Marcus. I'm just saying that from a testing purpose, we want, I don't know, four, five, six, something like that number of words. Then what you do is you write their opposites. So minimalistic, busy, etc. then what you might want to do is throw in some other random words that you're worried that you might end up going down this wrong line or whatever else. You end up with a whole bunch of words. Then you do your design. What you do at this point, is this is when you do a semantic differential survey. And all you do is you pull up the design, you put those words underneath it, and ask as many people as you can, which words represent the design? Now if they select the words that the client said they wanted at the beginning, then the client suddenly has no reason to turn down your design because they personally don't like it.
So that is a great way into testing, the idea of testing, because it'll save you a lot of hassle, and so you can take it on yourself. And also, that's not that difficult to do, to throw something like that together and put it online. It only takes a few minutes once you've got that initial list. Equally, once you produce that design comp, there are a couple of other tests as well that you can do that are really, really useful.
So you could do something called a first click, test, where you show them the design. This is what I did recently in the Slack channel when I had to design that I was unsure where people would click. I said to them, if you were going to do dot dot dot, what would you click on? And used a tool called Usability Lab, where I put up the design, they click on the static design where they would next go, and if they click in the right place, if that would take them in the right direction, then you know that the design is working. Because something like, I think it's something like 86% of people who get their first click correct are likely to finish the task they're trying to complete. I can't remember the exact number, but let's say 86. That sounds good.
So there's first click test. Now you could also do something called the snap test, where you show them the design for a few seconds, and then you ask them what they remember about the design and note the order they remember it because that will give you an idea about the visual hierarchy of page.
Marcus Lillington: I haven't done one of those in ages. We used to do those. Ooh.
Paul Boag: Yeah. They're really good. I still like them. The other thing is you can add some additional questions around that. So you can ask questions like, "What was the site about?" To make sure we communicate the key message very quickly. "What would you do next on the site?" All of those kinds of things. So there's a huge amount of testing that you can do just with a mock up and asking a few people on social media. And that is so easy to do. When I did it in the Slack room, yeah, they weren't target audience people, but with usability things like a first click test, that doesn't matter so much. We all kind of struggle with the same things. And that immediately gave me something solid to take back to the client and reassure myself to be honest that the design was going in the right direction. So absolutely use that kind of approach wherever possible to get going.
Then with things like information architecture, obviously you can do things like card sorting is a really good exercise to do. We've talked about that loads on this show before. There's a great tool called Optimal Workshop that you can use, and their tool Tree Jack, which you can help to manage that kind of thing. But again, if you just get a small group of people and sit down with them for a half an hour, no, you're not going to end up with the full information architecture, but it's better than nothing. Something is better than nothing. Even a little bit of testing begins to establish it in the culture.
And then obviously you could do things like testing prototypes, where you do usability testing. Now we're getting a big heavier, maybe a bit more work involved. But again, you can use a tool like lookback.io that allows you to do remote usability testing, and even unfacilitated usability testing, which means that you don't have to sit while people do it. You set them a task, and then watch the videos back afterwards. You can also use tools like usertesting.com, who will actually source people for you that match your demographic. And that's another thing to say about usability lab that I mentioned. They will do the same thing. If you haven't got an audience, they can provide the audience. Now obviously they charge for that. But again, that makes these things easier. And you can get results turned around very, very quickly.
And then finally, once your site goes live, you should be doing ongoing testing like session recorders like Fullstory that I mentioned earlier, AB testing, a multivariant testing using something like Google Optimize. So none of this needs to be really hard work. I think we make it much harder than it needs to be. All right? So that's really all I wanted to say I just start doing something, even if it's not perfect. Yes, you'll hear all these people at conferences and stuff talking about the amount of work that they put into doing user research and testing and how they've got these hugs labs and two way mirrors and they hire companies to find exactly the right kind of participants. But if you're not Facebook, if you're not Google, if you're not Booking.com or Amazon or somebody like that, then just doing something is better than doing nothing, right? And start with testing because it starts to build into the culture of the organization.
Marcus Lillington: One thought from me.
Paul Boag: Yes.
Marcus Lillington: I've found with testing, of some of the best and most valuable and useful testing I've done, obviously this won't for every client, but I'm thinking of when we worked for Southampton General Hospital. I went round, clipboard in hand, and sort of tapped people on the shoulder, and sort a quick introduction, sort of a "Hi, I'm working with the communications department here, blah, blah, blah, blah. Can you give me five minutes of your time?" That was some of the most useful feedback I've ever gotten. And even though you do feel a little bit embarrassed for the first one or two, you just get into it after a while. And it was just a simple process.
Paul Boag: That's how universities are great for that because you've got people, you've got your target audience wandering around outside the door.
Marcus Lillington: Exactly.
Paul Boag: And that is always the big challenge is often getting at the target audience. So the technique that I tend to use is don't use the target audience. This is naughty of me. I'll try, and then I will meet resistance. So then I will go and use anybody basically, anybody outside of the company who doesn't know the project. And I use them for usability testing. I mean, usability testing in particular, most people are struggling with the same problems. Then eventually, but I will use it with other types of testing like card sorting and aesthetics. Now in those cases, it is more important to have to correct target audience, but if I don't have the correct target audience, I'll use anybody.
What then happens is somebody will turn around and say, "Well, yes, but you weren't using the right audience." And I'll say, "Absolutely! We weren't, so let's use the right audience and do it again." And it's kind of, by using the wrong audience, you get people to criticize it, and that gives you the impetus then to use the right audience, which is very devious of me. I'm not a devious person normally, but that does work, actually. So anyway, there we go.
Marcus Lillington: Cool.
Paul Boag: That's that subject. So Marcus, do you have a joke to finish us off with?
Marcus Lillington: I do. Every joke for the rest of the series is going to be from Paul Edwards, so thanks, Paul. Well, I say that. I might get a better one in between now and then, but at the moment, that's how it's going to be. So I went to the circus at the weekend. One of the acts kept doing back flips and then offering us updates. Turns out they were Adobe acrobats.
Paul Boag: Oh, ow, burn!
Marcus Lillington: I'm just repeating what is in front of me.
Paul Boag: Yeah, yeah, yeah. I have to have to say mine, a very justifiable burn. It wouldn't be so a problem if they just did the updates invisibly in the background. That would be kind of fine. It's the notifications. It's like, ugh. Don't ask me. Just let me set kind of some rules. Update in the middle of the night, or only update if it's a critical security bug, or whatever, and then just leave me alone.
Marcus Lillington: It was like Windows used to be. I imagine it still is.
Paul Boag: Yeah.
Marcus Lillington: Is it? I don't know.
Paul Boag: Not, it's not. It's much better now, much better, much more crosstalk 00:53:22
Marcus Lillington: Every time you turn the machine on, you've got three critical updates, and it never told you how long. It was usually 20 minutes. Paul says Windows is a happy place these days.
Paul Boag: It is, actually. They've come a long way. The trouble with us Mac users is we judge Windows by the last time we used it, which would have been probably 15 years ago in my case.
Marcus Lillington: What was the operating system, there was one. Yeah, XP, obviously was a famous one. I can remember 3.1, going back to the chat room. But they had one that had a name that was awful.
Paul Boag: Vista, was it Vista? Vista?
Marcus Lillington: Yeah, it could have been.
Paul Boag: Or there was also Windows ME was a particularly bad one as well, as I remember. But they learned their lessons. XP I thought was a pretty solid operating system for its time. As for 3.1, no. I'm sorry, 3.1, that was before multitasking, as I remember, which we're doing the nostalgia old man thing, aren't we? So on that note, I think we'll wrap the show up. Thank you very much for listening, guys, and we will talk to you again next week. Bye bye.