Steve Krug, usability expert and author of “Don’t make me Think”, shares with us his unique approach to usability.
Paul Boag: I’m really excited to have with me today Steve Krug. Good to have you on the show Steve.
Steve Krug: I’m really glad you asked me.
Paul: So, do you know what made me think to get you on the show was the fact that one day I went along to Amazon and there it said under Recommended Reading “Steve Krug has a new book out called Rocket Surgery Made Easy” and it was an instinctive reaction! I couldn’t help myself! I just did that 1–click ordering and before I knew it, it turned up on my desk! I’ve been such a fan of your original book Don’t Make Me Think that it was just an instinctive reaction to buy the new one.
Steve: Thank you! I wish I could count on more of that reaction! That’d be great!
Paul: That’s the glory of Amazon 1–click ordering; it’s just to easy, isn’t it?
Steve: Well, I know! I even mention in the book that people often say to me; they send me comments about Amazon as though I had some in with Amazon, because I did mention Amazon in the first book and they think I have Amazon’s ear somehow. I have never talked to anybody at Amazon and it’s said a lot in the book, but I do have an Amazon Prime membership, which is as close as I come to being connected; but they’ve hooked me! I’ve been with Amazon prime for… I don’t even know! What is it? $79 or something a year here and you get second day delivery.
Paul: Yeah
Steve: And so they completely eliminated the thought process for me.
Paul: Absolutely.
Steve: If I’m interested in buying it at all, I’m going to buy it at Amazon because history has proven to me that if I shop around I won’t find a particularly better price and with the second day shipping y’know; it’ll be here in two days!
Paul: Yeah, I mean the other thing that gets me is; have you seen their iPhone app? I can be out in a shop and I can look at the thing sitting in front of me on the shelf, look at it on Amazon and go “Can I be bothered to wait a couple of days?” and I go “Yes!”; click and it’s ordered. Talk about don’t make me think!
Steve: I have experienced pangs of guilt being in a Barnes and Noble here and seeing something on the self and opening up my iPhone and clicking on the Amazon app. I feel a little bad about that. I will tell you, I actually did the same with your book last night, which I didn’t know about. I went to your website to check on what had changed about your podcast since the last time I listened and there was your book! Although your book is not actually on the homepage of your consulting firm’s website.
Paul:No, no it’s not!
Steve: I sense some… [Laughs]
Paul: No! There’s nothing untoward there!
Steve: There haven’t been any discussions about taking up crucial homepage space with your book
Paul: Well, it’s difficult. You see, the secret is; you don’t actually make a lot of money out of books, while you do make a lot of money out of web design!
Steve: Ah! So you know that too!
Paul: [Laughs]
Steve: You see I’m odd ball data point, because I have made some money from my book, but nobody makes money from those books. Which nobody knows…
Paul: Exactly! I mean, that’s the thing to say about ‘Don’t Make Me Think’, it was incredibly popular. Why do you think it became so popular?
Steve: My theory is because it was profusely illustrated! I love profusely illustrated books! [Laughs] No, I think it was… It’ the mix! The fact that it is a mix. That it’s approachable.
Paul: Hmmm…
Steve: And it sort of boils a lot of things down. It’s very short, so it’s a quick read. For the most part it’s been; it’s life story as that it was the book that people gave to other people.
Paul: Yeah
Steve: Whether their boss, or their coworkers, or their client, whatever, to explain what they’d been trying to explain to them for years.
Paul: Hmmm…
Steve: So they could hand it to these people and because it was profusely illustrated, it was, you know, engaging I suppose.
Paul: Useable even…
Steve: That I’d go that far! [Laughs] That people would read it! I have people say “My father-in-law was visiting us over the weekend and it was lying on a table and he picked it up and read it”. His father-in-law has no interest at all in websites. So it is this kind of thing that people can read fairly casually, but it does seem to make… You know, I say over and over I didn’t make this stuff up. I’m not really saying that other people haven’t been saying for years, including a lot of the people that buy the book, but they’ve trying to say it to other people who’s business is not usability. So that seems to be what it gets bought for is to make the case to other people.
Paul: Hmmm. I mean, I’ve found it an amazingly approachable book and one that, exactly as you say, that kind of, that I could pass on to other people and that, you know, it is the one book that I say, tell everybody to read before anything else. You know, people, especially students, come to me an they say “What should I be learning? Where should I start?”, and actually before I recommend HTML and CSS books and all that kind of stuff I say “Read Don’t Make Me Think” because everything else builds off that. If you create a great user experience then, you know, the technology should be second really.
Steve: Well, I appreciate that! That’s very nice! And it’s actually been picked up for a lot of courses, which I never would have anticipated. I had know idea that that would ever happen.
Paul: So, lets talk about your attitude and approach to usability testing…
Steve: By the way, we’ve got to do a plug for your book…
Paul: [Laughs]
Steve: …which I am now eagerly awaiting; The Website Owners Manual, which strikes me as a really good idea! I’ve thought for a long time that; what do people do? You know, there are all these people that are faced with the prospect that “Gee! I’ve got to get a website together!” and they are faced with a completely blank slate. They don’t have any of these skills and they don’t even know who these consultants are, or who they should be hiring and they have no idea of what they should be paying for. So I think it’s great idea for a book. I’m looking forward to reading it.
Paul: Well, Thank you! I’m a bit nervous about you reading it when you get to the chapter on usability that you might realise how heavily influenced I’ve been by Don’t Make Me Think. [Laughs]
Steve: [Laughs]
Paul: There is a nice big picture of Don’t Make Me Think and a good plug in there, so you’d be fine! [Laughs]
Steve: Like I say; I didn’t make this stuff up. So, you know…
Paul: Yeah. Let’s talk about your attitude towards usability and in particular the one thing that strikes me from reading your original book; I haven’t read you new one yet because it’s only just arrived, but…
Steve: It’s even shorter!
Paul: I know! it looks great! That’s the kind of book I Like! So, you’ve got this attitude of ; it seems to be all about making usability as accessible to people as possible and about keeping it low cost and light-weight. Why do you feel that’s so important?
Steve: Because it’s so valuable, you know, the funny thing is anybody who does some, usability testing on their own stuff, on what they’re working on, I find that inevitably the reaction is ‘Wow! We learned an incredible amount from that in a very short period of time” so it produces fabulous actionable insights. It points out to you with very little effort things that are going to cause you serious trouble. You know…
Paul: Yeah.
Steve: So while you could get the same information, you know, even a little more efficiently, hire somebody who works in usability to do an expert review for you or something, that’s expensive and usability testing, the kind I’m describing, the do it yourself discount usability testing, just mean bringing a couple of people in and having them try to use what you are building and having them think aloud while they do it while you watch and thats kind of all there is to it. So it’s so simple that I think everybody should be doing it. If you hire somebody to do it who has the experience then in order to justify them being hired they kind of have to make a production number out of it.
Paul: Yeah.
Steve: Now I’m not saying there isn’t value in hiring somebody to do it. There’s people who do it for a living can do a much better job of it than amateurs ever will and they will provide a lot more value and it is worthwhile, but most people can’t afford it. You know. Most people just don’t have it in their budget to hire consultants to do usability testing for them even though it is enormously valuable. So I’ve sort’ve decide over the years that it’s something almost everybody that has a website or is building webapps or apps or whatever should be doing some usability testing. It should jut be part of the design process. I think it’ll end up that way. I think it’ll start getting taught more and you know… If you’re in a design program i think inevitably you are going to end up taking one short course on usability/user experience and that’s kind off all you need if it’s not your focus, but one short course is enough to get the basic principles across. So I think we’d all be a lot better off, I think, if everybody who was building websites included a small amount of time during the development process to do a little bit of usability testing, then I think, you know, the stuff that we’re out there using would be much, much easier to use in general.
Paul: Hmmm.
Steve: It doesn’t take an expert to do it. I mean, have you had that experience? You’ve sat through usability tests…
Paul: Oh yes!
Steve: And i just think that they’re eye-opening.
Paul: Oh, absolutely! The thing that really strikes me about, you know, you could get an expert in to do it and, you know, we do usability testing for our clients, but there is something about seeing it for yourself. You know? No amount of reports will replace that experience of sitting in a room and, you know, seeing the fact that your usability test person doesn’t know how to use a mouse ’cause they always use a trackpad or laptop.
Steve: Exactly. I describe it as a conversion experience. There’s this seeing is believing effect to it. If you sit there; you are actually sitting there watching somebody use the thing. People’s eyes just open, they just, they get it! They suddenly understand how different the user perception is of what they’ve been building from their perception and they understand where there were oversights, where things that they did’t anticipate or they didn’t understand and they suddenly understand the people who are using this don’t see thing the same way that they do. I describe it as conversion experience and in fact as you’ll see… I mean in one sense the new book is, you know, an expanded version of a couple of chapters I had in the first book, but in another sense it’s not, in that I wanted to spell it out as a detailed how to. So I wanted to kind of give everybody the information that they needed to sit down and do their own usability testing and in thinking it through, I actually realised a bunch of things and one of them was to become kind of adamant about the fact that you really want to have people come and watch these tests.
Paul: Yeah.
Steve: That they really have to sit there. Everybody who is involved. So the people on the development team; the stakeholders; any management that you can convince really should come and watch some of these test because even just watching one or two users, it give you that eye opening experience. Then you want to watch more. And as you say, reports don’t do it. reports don’t give you the same experience.
Paul: No. I mean another thing that you talk about, which I guess is a problem when you hire an expert to come in is that; if you are spending a lot of money on usability there’s this danger that you will only do one round of testing.
Steve: Right
Paul: And that’s something you warn against. Why is that such a big concern from your point of view?
Steve: Well, because it doesn’t need to. To get the information that you need, to get the information that you can use at any given point in time, you don’t have to make a big production number out of it. And if you don’t make a big production out of it then you can do it more than one. You know usually if you hire a consultant you are paying $5000, $10000, whatever, for this project, then you are not going to do it half-a-dozen times during the course of the development of the website. You are going to do it once and you are probably going to do it nearer the end. I explain in the book why it would make sense to wait ’til the end when the thing is almost what people are going to see, but the fact is you get so much more value out of doing testing early than late, because if you do it near the end, basically you discover these major problems but it’s pretty much too late to fix them. Whereas, if you do it in the beginning you actually can discover the major problem very close to the beginning of the project and fix them right away and so not build anything out based on these mistaken assumptions or whatever. So, you only need a couple of people. At this point I argue for doing only three people…
Paul: Really?
Steve: Yeah! [Laughs]
Paul: That’s really getting more and more extreme isn’t it?
Steve: I like your reaction! It is extreme, but there are a lot of reasons for it. If you keep it that simple then you can do all the testing in one morning. My suggested serving is that you do three test in one morning and then de-brief over lunch. And that way you’re team’s investment in usability testing; and you do it once a month.
Paul: Right.
Steve: And so that way your team’s investment in usability testing for most people other that the people (person or people) who are running the tests is half a day a month. And that’s it! And at the end of lunch, you’ve decided what the major issues are that are problematic at this point and that you are going to fix before next months testing. There are a lot of reasons for this. One is, if you keep it that simple and you limit it to three users then you want to do it onside, you want to do it in a conference room at your location someplace and get people to actually attend so you can say; “Ok, the third Thursday of every month we’re going to do a morning of usability testing”, put it on your calendar, you know, have that expectation that on the third Thursday of every month you’re going to come and watch usability tests. And that way you can get as many people as possible to actually come and observe in person. If you are doing a whole day full, you are doing eight people to kind of justify that it’s really legitimate, then who’s going to come and spend a whole day watching eight users. The fact is by the time you’ve tested three users, you start to get diminishing returns basically after three where you start to see the same problems again and again. Everybody who has sat through a whole day of user testing behind the two-way mirror or one-way glass or whatever, knows that you start to see the same problems over and over so you get less value out of it, but I also would argue that in fact if you do more than three users, you are probably going to turn up too many problems. You are going to turn up more problems than you can actually deal with and in fact with three users you are probably going to turn up more problems that you can actually deal with, because the problems are so easy to find that almost everybody’s resources for fixing the problems is less that their ability to find problems, you know. So how many times have you seen the site where you’ve done testing for a client where you present them with a report that has all these problems in it, many of which are actually serious problems, and then you come back a couple of months later and the most important ones haven’t been fixed.
Paul: Yeah.
Steve: So the less important ones have been fixed, perhaps many of the less important ones have been fixed, but the most important ones may be a little harder than the less important ones, you know, they require more thought, more effort, but it clear to everybody that they are the most important ones. Sometimes you have something that’s just a deal breaker like nobody can find their way through our shopping cart. Well that’s [Laughs] problematic! But it may not get fixed. You know, there may be people saying “Well, that’ll get fixed in the next version”you know “We don’t want to put the effort into that right away!’. So I spend a lot of time in the new book talking about how you really have to just focus on the most significant problems and you figure out how many of those problems you are actually going to be able to fix in the next month and then cut the list off right there. People come and watch and then over lunch you have a discussion where people compare notes about what really were the most serious problems and it’s kind of fresh on everybody’s mind, they just saw the people have trouble with it, it has that kind of emotional charge to it.
Paul: I mean what the argument that you would get I guess opposing a viewpoint like that would be that when you’re testing such a small number of people, is that really representative of the real problems and perhaps those people aren’t as demographically accurate as they should be, you know. Do those things really matter?
Steve: Well, they are very legitimate questions. I mean, it takes the question very seriously and you are right, tat is one of the first objections that people are going to raise. I phrase it as, you know, people are going to say is this statistically valid?
Paul: Yeah.
Steve: Is there validity to this? And the answer that I give, actually one of the things I’m very happy with in writing the book was I put frequently asked questions at the end of each chapter. It’t a great literary device, because you don’t really have to figure out how to work all of these issues into the fabric of the chapter. You know from writing your book it’s hard…
Paul: [Laughs] Yeah.
Steve: …but if you have a FAQ list at the end of each chapter, then you don’t have to work them in. So my suggestion to people when someone questions whether this is still statistically valid because you’re only sampling three people is no; it’s not statistically valid. There is no validity to it whatsoever. There is no statistical validity to it at all, but it obvious to everybody who’s there watching that these are real problems. You know the worst problems are just obvious to everybody when you are sitting there watching. There’s no argument. I mean you can argue about, well would our actual audience, you know these people may not be who we think of as perfect representatives of our actual audience but it’s actually very easy for people to say “Well, but they’re close enough, if these people had a problem then our actual audience would have a problem too”. Because the problems are so bad that you look at them and say “Anybody would have this problem” you know. So I find while that’s a great argument in the abstract that people are going to ask you, I think once people sit in the room and actually watch, they loose site of that argument. They don’t worry about whether it’s statistically valid because it’s so obvious to them that these are the real problems to the things that we need to fix. But I just tell people “Don’t get into that argument”, just say “Nope, you are absolutely right! There is no statistical validity here at all”
Paul: So the next question I’ve got is an unfair one really because I’m basically going to ask you to summarise your new book in a couple of lines [Laughs].
Steve: Okay! [Laughs]
Paul: In the sense that, what advice would you give people starting off in terms of running their own effective, low cost usability test session? Where do they start? What’s the key things they need to look for? Other than buy you book, obviously! [Laughs]
Steve: Well, buying the book is good, but I, you now there’s actually some chapters from the book on line. There’s actually a demo usability test online that people can watch that kind of shows how I do a test and how simple I think it should be. Yeah actually it’s at Peachpit.com, my publisher, if they search for Krug, or they can go to rocketsurgerymadeeasy.com and in either place they’ll find links to this demo video; it’s about 25 minutes long and I want everybody to have that, you don’t have to by the book to get that. I think you can get a pretty good idea… ’Cause I really do thing everybody should be doing this. So, what would I tell them? I’d say “a) It’s really simple; don’t be intimidated by it at all. Just try it, you can try it without an audience first, just to convince yourself that you can actually do it. You don’t have to worry about embarrassing yourself in front of co-workers or whatever, but grab somebody and make up some tasks that are the tasks that are important for people to be able to do on your website and write them down and hand them to this person and say could you do these and think out loud, tell me what is going through your head, what you are thinking about, what you are looking at, while you try and do them. That’s kind of it I would say. Just try doing that and you will see how easy it is to do and and how in watching that one person that you see what’s wrong and I think that would give you the incentive to go ahead and learn more. There’s my book, there are other great books; on my website I have my recommended reading, but there are several other excellent books about how to do a usability test. Dana Chinsell and Jeff Rubin just did a revised version of his book. You can still get Joe Dumas and Ginny Redish, that’s a very good one. Carol Barnum is coming out with a new one. So there are plenty of books out there that are very good. The benefit of mine I think is that it’s only what you need to know. If you actually get into it, I recommend that you read one of the other, ’cause they’re all very good and they cover the topic in more detail, but mine makes the assumption that this is not how you make your living and this is maybe not even part of your job description. You know, you are taking this on as a past time because you think it’s important that somebody be doing this for your product, that somebody [should] be paying attention to your users. So it’s the least you need to know. Which is why it’s so short! [Laughs]
Paul: I mean that’s great, isn’t it, that at it’s very basic level this is not a complicated thing to do; it is something that anybody can do.
Steve: Well, you know, it’s not rocket surgery! [Laughs]
Paul: No. Exactly.
Steve: That’s where the title came from for the book and I think it really is something that anybody can do and should be doing and once they try it, they’ll get enthused about doing it because they will see how much you learn in how little time. When I do my workshops, I teach workshops about the same thing as this point about do-it-yourself usability testing, and when I do the workshops, even if I’m doing a long presentation, if I’m a presentation that’s more than an hour, I’ll try and do a live usability test where I’ll just grab somebody from the audience and and in the workshop I take a site that belongs to somebody who is attending and I’ll make up a task and I’ll do a fifteen minute usability test, where all I do is hand the the task and say “Okay, go ahead and try and do this and think out loud while you do it.” The reason why I love doing the live ones is because it shows that there’s no magic to it. You know, I don’t have anything up my sleeve, this is not canned, and when you watch somebody do it you just say “Well I could that! All he’s doing is giving him something to do and keeping him verbalising what they’re thinking.” So I really am worked up about trying to get as many people as possible to try doing this because I think once you do it you get hooked on it. You know, you’ve done them, I mean they’re alway interesting.
Paul: Yeah, completely.
Steve: Even after years, they are always interesting.
Paul: I’ve been working in the web for, I don’t know, fourteen years or whatever it is, and you’d think by now nothing would surprise me.
Steve: You would have seen it all… [Laughs]
Paul: But no. There’s always somebody that just does something and you think “I’ve never thought about it that way!”
Steve: And yet in a way, that makes perfect sense. [Laughs]
Paul: Yes! If you’ve got a certain mind set. Completely! But of course actually running a test session is only half the battle, because then you get all of this information back. How do you understand the results and prioritise what to do?
Steve: That’s why I think it actually all sort of fits together under this, you know, limiting it to… The phrase I have in the book is, I have these maxims in the book, and one of them is; ‘a morning a month, that’s all we ask’ to try and get you to say “Okay, we’re just going to do this one morning a month and we’re going to try and get as many people as possible to come and watch in person and get them all to come to lunch and do the debriefing together.” and the debriefing, I actually have a worksheet for people to keep track of what they saw, but you really get people to, each person to, focus on what were the three worst problems I saw in each one of these three test, So they have a list of somewhere between three and nine things that they think were serious problems and then over lunch you compare notes. You put them up on a board and you find that a lot of people, you know, have the same things on their list.
Paul: Yeah.
Steve: And in that context then you talk about what do we as the team, with all the knowledge that we have, the people who you’re watching aren’t the experts at all, you’re the experts, about what this site needs to do and what needs to work and what resources you have available to make it work and what your priorities are at the moment. So that’s why the team is where the intelligence lies and they exercise that over lunch. I think you’ll find that if you say “We’re only going to walk out of this room with a list that’s only as long as what we can get done in the next month with the resources that we have”, then you don’t come out with a long list. Part of it is that you have to focus ruthlessly on just the most important problems. On just what you saw that struck everybody as “Well, we can’t have our site working like that, you know. That’s something that we just have to fix that.” and there always are a bunch of those. So by limiting it to three people you’re not generating tons of information. You’re not generating hundreds of problems that people saw, hopefully. I mean sometimes you maybe with three people, depends on what shape the thing’s in. The other bad thing about testing eight users at a time is that it’s overwhelming. I mean at the end of the day you have this huge list and you have this sense that nothing is working! You know? That we have an impossible amount of stuff that really should be fixed.
Paul: Yeah.
Steve: And that’s disheartening.
Paul: I mean the other thing that I love about this once a month thing is that because you’re including as many people in that as possible and as many people are coming in and seeing it, you’re not just doing usability testing, you’re shifting the whole culture of your organisation to be user focused, which is what I was going to come on to, you know. How do you create a culture of user focused user testing in your business, but this kind of does that because it makes the user testing process accessible to a lot more people.
Steve: Exactly, but by keeping it short, keeping it on site and having it a a regular fixed time each month, I think you maximise your chances of actually getting people to come and attend in person. I also highly recommend the highest classes of snacks that you can get! [Laughs] Snacks are very important!
Paul: [Laughs] Absolutely!
Steve: If you have to figure out where you’re spending your budget whether it’s on recording or recruiting or whatever, spend it on snacks! because one of the maxims I have is; ‘make it a spectator sport’. You really want to get as many people as possible who are involved to actually come and watch in person.
Paul: Yeah.
Steve: And take part in the debriefing. Some places actually require that if you want to take part in the debriefing, you have to come to the sessions and watch, which is interesting. I recommend that, but only to the extent that it’s politically feasible in your context.
Paul: Absolutely, yeah.
Steve: You may not be able to get away with that. The other thing about a morning a month is that if you specify a regular interval like that, then you’re not basing when you’re going to have something ready. So you don’ build a schedule around the points in your development timeline where things are going to be ready because you will alway have something you can test once a month. You know, there will always be something that you can test. It may not be a perfect match of “we just finished this version with our dates coming up next week ”, but it’s much more important that you commit to do it regularly, because if you make it a routine, then you remove that decision of “when are we going to test?” and if you’re still facing that decision of “when are we going to test?” then as the benchmarks seen in your development timeline creep, so does your usability testing schedule and you end up doing less testing and so i think it all works together
Paul: Absolutely. I mean, yes, I love it. I love everything you are saying. It makes perfect sense to me. Just before we wrap up, ’cause we really ought to wrap up soon, I do what to ask you about something that really I haven’t made my mind over either, so I’m really interested in what you think about it, which is that there seems to have been this explosion of remote user testing services; these things where you can video users remotely. What do you think of them? What do you see as the pros and cons of them?
Steve: I actually put in a very short chapter about that and it’s about two things. One is about moderated remote testing where basically you’re doing the same thing that you would in a normal test, only you’re not in the same room as the person. So you’re using something like GoToMeeting or NetMeeting or whatever, but you are still facilitating the test. You’re still watching what they are doing in real time and you are still able to probe, you’re still able to keep them thinking aloud. It’s exactly the same except you’re not in the same room and that’s what most people think of as regular remote testing, which is fabulous because it certainly make recruiting so much easier. Recruiting goes from people who live in walking distance of our facility to everybody, basically. You’re talking about unmoderated remote testing where you’re not in contact with the person while they are doing the test. Basically, you give them the tasks and they do the test but they create some kind of recording or some kind of record, whether it’s automated or whatever. I actually think some of that can be quite valuable. I recommend in that chapter, I talk about usertesting.com which is based in the UK, or am I right about that? they are, right?
Paul: I’m not sure whether they’re based in the UK, but I’ve heard of them.
Steve: Oh, no. They’re in California. I’m wrong about that. There are several people following that model now, but they were the ones that I was familiar with doing it first, where basically you send them the URL that you want tested, the task or tasks that you want the person to do and they would take somebody from their pool of vetted people, who were vetted on the basis of they’ve proven pretty good at doing tasks on a website and thinking aloud while they do it. You tell them how many people you want, people from their pool sign up and say “Alright, I want to do this one” and they have a microphone and they’re basically doing a screen recording while they do your tasks and for $29 a head you get back a fifteen minute video of somebody doing these tests. I find they’re actually quite good. They’re surprisingly good in that they are effortless. Basically you don’t have to do any recruiting, you don’t have to do anything except spend fifteen minute watching the video tape that comes back. So for thirty bucks, you actually can get a nice little amount of information. For one thing, they are perfect for piloting tests before you actually bring people in and do them yourself. You can take the tasks that you’ve written up and send them out and have one or two people do hem through a service like that and you’ll learn a lot about whether you wrote your tasks well or not for people to use.
Paul: Do you see them more as a complimentary tool rather than a replacement?
Steve: I do. They’re not a replacement, but they’re also quite good if you have you know something that comes up in between your monthly testing and you say “boy, it’ll be great to have a couple of people try using this.” Then you can just use that, you know and the nice thing about it is you can usually get your video back within a day. So you submit them a task and the URL and a day later, or even less sometimes, you will have your fifteen minute video that you can watch and get some kind of quick read on whether people are going to run into a problem that you think they might be running into. So I recommend it quite highly actually.
Paul: Oh okay. Do you not find that they end up becoming professional usability testers where they’re not representative?
Steve: Well there are dangers and certainly the people at usertesting.com I’ve been in contact with them, just ’cause I like what they’re doing, and they’re certainly aware of that danger and the danger is the people may feel like they need to not say anything bad about the site so that the people who are paying for the test won’t be unhappy, but I think they are aware of all those dangers and try and head that off as much as they can. I just have been very pleasantly surprised by the people who I know that have used it have been very pleasantly surprised at how useful it can be, especially because it’s zero effort.
Paul: Zero effort is always good. I think then at least it happens. It’s better than nothing isn’t it?
Steve: Exactly, you know, it’s even quicker and dirtier than what I’m recommending so there’s lots to be said for that.
Paul: Yeah. Thank you so much Steve for coming on the show.
Steve: It’s a pleasure.
Paul: It was absolutely wonderful to have you and I’m really looking forward to getting stuck into the new book, Rocket Surgery Made Easy.
Steve: Yeah, I’d love to hear anything you have to say about it. I know that there’s going to be a lot of very interesting feedback about it.
Paul: [Laughs] Beautifully put! [Laughs] Okay. good to talk to you and we’ll talk again soon.
Steve: Thanks Paul.
Thanks goes to Simon Banyard for transcribing this interview.
If you recognise that the mobile web is important and you need help deciding on a strategy, then book a mobile consultancy clinic.
Book a consultancy clinic or contact Rob about a more in-depth review.
