|Mahtab||Welcome to episode 013 of The Crux of It. I am Mahtab Rezai. I'm the Principal and CEO of Crux Collaborative. We are a user experience consulting firm, and we specialize in regulated industries. Today I'm joined by my colleague, Mike, who is our Director of Design and Development, and we've been doing this podcast for a while, but this is the first time you're doing one with me, so hi, Mike!|
|Mike||Hi, Mahtab. How are you?|
|Mahtab||I am glad that it is Friday, how are you?|
|Mahtab||All right. So today we are going to talk about prototypes for usability testing and how functional they need to be, so we're going to talk about just different things we've observed about when it makes sense for something to be functional, when it makes sense for it not to be, and some things to consider, so let's just dive right in. Let's first talk about what do we need to do at the outset when we decide we're going to be doing a design step usability study?|
|Mike|| Absolutely. So first, we really have to define the objectives and the use. Will this prototype be used only for usability testing? Will it also be used by the development team as an example for how the interface behaves and functions? Because that will change how we actually develop them. Typically, if it's going to be what we call a smoke and mirrors prototype where we just want to build it so it acts like the real website, but really the code behind it isn't something you could use as a foundation for building code, that would be smoke and mirrors type website or prototype.
Any time you're building something as the foundation for code for an app or for a website, it takes a lot more time, it takes a lot more thought about how things are going to get built out, and when you're creating a prototype, a lot of times you're discovering things like, "Hey, this isn't going to work," or we have to go back to design or go back further to solve some problems. It's tricky to do them both at the same time.
|Mahtab||Okay. That makes a lot of sense. So first is that overall project objective of: what is this deliverable going to be used for? Just usability testing, or usability testing *and* as a foundation for coding, but then the next thing we do is look at the research objectives, and what are we trying to learn. That informs a lot about whether things need to be functional or just simply there and present. So let's talk about our process for doing that.|
|Mike||Yeah, excellent. With any sort of prototype, there has to be kind of a limit in terms of how far it's going to go, how many pages or views exist. It can't show every page or view that's going to be in the final website, that's not realistic.|
|Mahtab||Mm-hmm (affirmative). And a lot of times, what informs that for us is our research objectives and the test plan. So we'll work on the UX side to put together the outline of the test plan, and then we'll share it with you and sort of work together to define how many pages or views. Alright, so let's talk about some of the things that we have found where we actually need to build it. It needs to active when we're doing the study because it's important. So what are some scenarios that need to be active?|
|Mike||Obviously getting the main navigation of the site built out in terms of how the hover states behave. Also, if there's a mobile usability prototype, that's going to have a little bit different behavior because we're testing on a mobile device. We want to get that as realistic as possible because that's something that can really become a hang up for users if it's not done correctly.|
|Mahtab||Yep. Especially on studies where we are starting out, and we don't necessarily know ahead of time, but we're starting out by asking the participant, “Do you most often do this type of thing on your computer or on your phone?” and then based on their answer we start with that device, so we need to make sure that it's working at the different breakpoints. I think another thing that has to be real when we're doing it is form fields, dropdowns, anything that's pertaining to a specific scenario. So not every form field or dropdown in the prototype has to be functional, but if we're asking them to go down a particular path or complete a certain task, all the associated functionality with that task, we try to replicate and make functional to the degree that we can|
|Mahtab||I think another thing in addition to them noticing these functional things as they go through the scenarios that we have found makes a world of difference if it's real and we've built it out for that scenario, are the error messages and resolutions. When we are able to, in the course of a scenario, create the prototype so that if the user does have an error or puts some information in incorrectly, they encounter an error message representative of what they would see in the actual experience, we're able to learn a lot about everything from: “Can they even see the error message?” to “Do they know how to resolve the error based on the language we're using in displaying the error?”|
|Mike||Yep, absolutely. The other thing, one of the ways we build prototypes is we typically build in HTML, because creating those error scenarios is a lot easier and more realistic in an HTML prototype. We can talk too, about kind of the other ways that prototypes can be created.|
|Mahtab||Absolutely. Let's skip to that. There's paper prototypes obviously. There's prototyping tools, everything from just low, low-fi, right? PowerPoint, to actual prototyping tools like Proto.io or Axure, and then there's HTML. We prefer HTML for some of the reasons you just said, and what are some of the other reasons that we prefer HTML prototypes?|
|Mike||I think kind of the main reason is once you're building it in code, and we've got HTML and CSS for the styles, you're kind of proving that this can be built, this will work, this design actually could be created. Because it's pretty easy in Photoshop or PowerPoint to build something that isn't really producible, so kind of by building it in code, we know, all right, this is going to work. Especially with a prototype that maybe is desktop and mobile, we can take advantage of some existing responsive libraries versus having to fake it all with screenshots or something from Photoshop. That's one of the big ones—is getting the realism.|
|Mahtab||Yes. The other thing, I think, that's a big component of why we like to do it is because we have the luxury of having our own usability lab here, and we work so collaboratively during the day of the study. We actually have the full project team observing, so we actually make a lot of decisions as themes are emerging to make edits to the prototype in real time. And what we have found is it's a lot easier to do that with HTML prototypes than it is with some of the prototyping tools or even some of the low-fi things, is in between one session and the next, if we're noticing that a highlight color we're using for some help text is just not being seen, it's much easier to have you change that color in between one session and the next, and then just refresh the browser. Then also, I think let's talk about some of the things that we have discovered and we change in the prototypes during the test days. So I mentioned colors. What are some other things?|
|Mike||Sure. Well, a lot of times it's content. It's labels on the page, a headline, or even navigation items that people are getting hung up on. It's so easy for us to go in and, even during the test, make that change, hit save, and once the user gets to that page again, it's already been updated.|
|Mahtab||Then to validate, yes, this solved it, or nope, this is still a problem. We're going to have to continue to work on finding the right solution.|
|Mahtab||It helps reassure us and the clients when we're spotting something that's an issue, and then we try a solution. When we've got the right solution, everyone is reassured because the next three or four people don't encounter that same stumbling block. Then we see that they get through the task, and we're confident that we've solved it, versus having to wait until after the study and put it in the recommendations. You're not as confident or as assured that the solution worked if you're not able to change it in the prototype during the study.|
|Mike||Yes, agree 100%.|
|Mahtab||Then I think that the other thing that we try to consider is how much we can change too, to reflect the findings of the study in the actual prototype, so when the test day has come and gone and we're writing the report, we try and also edit the prototype to reflect the recommendations we're making. Again, especially when development teams are using as a foundation or basis to begin constructing the site.|
|Mike||Yep, absolutely. The beginning parts of building the prototype, kind of recognize those places where we're like, "This could actually be tricky in testing. It's probably going to change a lot," and built it in a way so that when we have to change it, it's not a start over, something like that.|
|Mahtab||Awesome. Let's review some of the things we covered. First, when it comes to building prototypes for usability studies, figure out: is it just going to be for the study, or are the development team going to use it as a foundation for building the site. Two, figure out what are we trying to learn in the study, and what components need to be live and active, and what can we get away with simulating. Three, build it in such a way that you're able to edit it and modify it during the study and then after the study. I think I got it.|
|Mike||That is it.|
|Mahtab||All right. Okay. Well, thank you for listening. Let us know if you have any feedback about what we shared or other questions. Our contact information is on our website, and you can find us on SoundCloud, on iTunes, Google Play, Stitcher as well as on our website cruxcollaborative.com/thecruxofit. Bye.|
Want more of our Point of View?
Sign up, and you’ll be the first to know when we’ve published a new article or podcast.
Hosted by: Mahtab Rezai
Principal & CEO
With guest: Mike McClure
Director of Design + Development
Mike has been involved with user experience work since the early nineties. He worked on the first CD-ROM medical encyclopedias and video game guides. His background in 3D animation, digital video and music production has served him well into the current state of UX development.
View Mike’s Bio