97 UX Things

Assess Usefulness and Desirability Early in Product Development (feat. Mike Hawley)

July 27, 2021 Mike Hawley & Dan Berlin Season 1 Episode 8
97 UX Things
Assess Usefulness and Desirability Early in Product Development (feat. Mike Hawley)
Show Notes Transcript

Mike Hawley discusses his chapter about using design artifacts to get more out of your formative user interviews.

Sponsored by Watch City Research
Watch City Research is your trusted UX research partner

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Dan Berlin:

Hi everyone and welcome to another edition of the 97 UX Things podcast. Dan Berlin here, your host and book editor. This week, I am joined by Michael Hawley, who wrote the Assess Usefulness and Desirability Early in Product Development chapter. Thanks for joining me, Mike.

Michael Hawley:

Thanks, Dan. Nice to be here.

Dan Berlin:

Yeah. So can you introduce yourself? Tell us a little bit about yourself?

Michael Hawley:

Sure. So I've been in UX for a few years now. And I'll get to that more in a second. But currently, I am serving as VP of Experience Research and Strategy at Zero Degrees, which is a UX professional services consultancy. And as a side gig, I also teach in the Human Factors Information Design program at Bentley University, for general UX students. So try to stay pretty active in the community and glad to be here.

Dan Berlin:

Great. Great. Well, thanks for joining me. And I want to start off with hearing about folks' UX trajectory. So how did you discover UX? And how did you wind up where you are today?

Michael Hawley:

Well, probably like a lot of people who are doing UX before it was called UX or kind of learning that there was a thing. My undergraduate degree actually is in cellular molecular biology, which is not much to do with UX directly. I knew I didn't want to work in a lab just mixing test tubes all the time, so I got a job out of college, it was in software. This was early 90s. Software for hospitals and my job was to go around the country and be that liaison and trainer for what was going on in the back office and the software that was being developed, and then actually working with the people who are going to use it. It was before I even knew what UX was before it was really popular. But I was developing a sense of empathy for people. And using things and seeing the juxtaposition between what somebody actually does in the field and using a piece of software or an experience versus what people back in the office were thinking they were doing and developing things. And I remember one story very vividly. Part of my job was to travel around to different hospitals and help them on the go live date; when they were switching from their paper system or from some other package. I would be there to help people manage the software and make sure that they knew what they were doing. I was doing rounds, checking in with everybody making sure that they knew what to do. I got to one of these nursing stations and there was a nurse who was really breaking down crying, almost crying, because she was afraid that she wouldn't be able to figure out the software and she would lose her job because of it. So talk about a very acute kind of experience of UX at that point. That really started me on a path of developing that empathy for people and seeing the the impact of our designs on real humans, real people. That got me really exposed to the impact of designs on people actually using them. From there, got caught up in the .com boom a little bit and worked for some software companies. At that point, I found myself sticking with the product management side of things, being that middle between the developers and the people making decisions about the software and the customers. At that point I learned about that UX was growing as a field and got got involved in it went to school and from there kind of took off with it. I was lucky to be involved and learn from some of the people who started some of the original thinking around usability testing user experience processes and learn from them. I spent a couple years in working as an innie within a company working on products. But the most of my career has now been with professional services as an outtie. Working from the outside.

Dan Berlin:

Great, great. Are you concentrating in any particular domain these days or any specific area that you'd like to focus on?

Michael Hawley:

Well, it's an interesting juxtaposition with professional services because clients and companies need you to bring a diversity of experience and a variety of different perspectives and bring best practices from other industries to theirs. But you also need to balance. You need to have some level of depth understanding of the trends or the considerations in any one given industry. So I find myself working with a lot of, let's say post login experiences and healthcare and education, technology, those types of things, so less on the marketing communication, side more on when you need to develop a long term relationship with a customer and interact with them over time. There's a lot of commonalities in that across industries. So I find myself working with that.

Dan Berlin:

Yep. One of the things that you said resonated there. One of the things I love most about agency life and consulting is when you learn about a particular domain, there are certain things that you can bring to folks in other domains that may they may not have considered at all that could positively affect their customers experience, but they just never came near to thinking about it, because it's not in their domain.

Michael Hawley:

Yeah, it is a fine balance.

Dan Berlin:

It is.

Michael Hawley:

Yeah, you need to show expertise and have a background in and understand like... what are HIPAA regulations in healthcare? What do people think about in financial services? How does financial wellbeing play in. You have to have some sense of the trends in an industry, but bringing other perspectives is helpful and clients really look for that. So I enjoy the professional services side of it.

Dan Berlin:

Yeah, likewise. Great. So thanks for that. Moving on to your chapter. Can you tell us about your chapter?

Michael Hawley:

Sure, I'll give you a little bit of background of how I even thought about this. And I know you and I, Dan, have been talking about this topic for a long time.

Dan Berlin:

Quite some time.

Michael Hawley:

Yeah, having worked in professional services, people come to an agency or consultant not necessarily to just advance an existing product over time, but really, for new ideas for new opportunities for something to break through and be innovative and unique. So we get to work on those types of things a lot. In that process, we're very early on thinking about doing formative research with customers and target audience members. And you're really trying to suss out between different ideas, which ones might work, which ones are going to be most compelling to the target audience, which ones are going to be the most valuable and most useful, potentially, in their lives. And so, you and I, our default reaction is to say, "Well, let's, let's sit down with people one on one." Right? And talk about the ideas that we have and see if they might resonate. And when we say sitting down and talking to people one on one, that looks a whole lot like usability test.

Dan Berlin:

Right.

Michael Hawley:

Right? But I think about the people who I learned from in terms of usability testing, and I was very fortunate to work with, let's say, Joe Dumas, who helped write usability testing protocols in the early days, or Beth Loring, who you and I both know, or I would follow Jakob Nielsen and other people who were very much into the practice of usability testing, and a lot that I learned from them is really focused on behavior. You know, there is a think aloud protocol. But watch what people do, figure out where they get tripped up on tasks, can they get from point A to B? And what's stopping them? Right? And so I have that on one side of my brain. But then I have on my other side of the my brain... I'm really interested in what people think about this. Is it compelling? Is it useful? How does it reflect on the brand? And the best practice from usability testing would say, don't ask people for their opinion, necessarily, or what they think. Don't ask, "What do you think of this homepage," that doesn't really get you anything. So I challenged myself to say, you know, there's got to be some other structure or some way to do this, some way to leverage these one on one conversations, early informative research, so that we can get at the questions that our clients have like which direction should we go? Which idea is going to resonate? If you're using a metaphor or an example in the interface, does that make sense to people or not? Less about can they get from point A to point B and are there usability bugs. So that's really the impetus for this kind of usefulness testing or value assessment; concept resonance is another term I like to use sometimes with clients. Are the ideas going to make sense? But, that said, what I did take from some of those teachers and some of the protocols is that you can't just wing it, right? You have to have some type of structure. You can't just ask, "What do you think of this?" That's not going to be helpful because they might not get what you want and it's going to be very preference based. So that was the that was the impetus for thinking about this and the content of my chapter.

Dan Berlin:

Yep, yep. That's wonderful. I remember us chatting about this back in like, 2011. I think that's when we presented at UXPA Boston on this. And the folks that we learned from were very strict in their way of thinking about usability and the functionality. As you said, getting from point A to point B. And there was this opportunity to get that additional great, deep qualitative data. Part of what we do is researchers to maximize the ROI of research, we want the money spent to maximize the time we have with participants. So sure, we can do some usability, but maybe we also get at other things like usefulness.

Michael Hawley:

Yeah. And I think what's unique, maybe not unique, might be a strong word. But some people might say, well, sounds like just formative research. You're doing in depth interviews and talk to people and maybe get an understanding of what they value or what their current flows are, what pain points are, and all that's valid. What I found is that in an Agile world and a world where people like to react to things, there's an opportunity to bring early sketches and early ideas to those formative in depth user interviews. And so instead of just having an interview that is, let's just talk. Using a design artifact to help really dive deeper and help inspire the participant to think of other things or have ideas or react to something it's a lot easier for them, I found, to react to something. If we're doing a design workshop early in the process and we have some ideas, maybe different ideas, let's take those and assess the usefulness or the value with customers one on one.

Dan Berlin:

Yep. Yep. Do you have any examples of when this was particularly useful, where there was a project where you've found this to be instrumental?

Michael Hawley:

It happens a lot I would say. I think back of a project you and I worked on, actually, we were working for a music service. They were considering a new business model, right? Maybe couples might listen together, right? What does that look like? How does that feel? And there's a couple different ideas. Do they create playlists together? Or are they inspired by your tastes versus my tastes. So we had some design artifacts and some ideas of Option A, Option B, or Option C. We were able to sit down with those people one on one and get a sense through their own storytelling and through their own reaction to the ideas that we put in front of them, certain interface ideas, we were able to use that to launch questions about which things they might use or not. I'm working on another project right now, actually, that is for veterans and connecting them with other veterans and peer support and helping them manage things post deployment. There's a couple of different ways that could go, right? There's different aspects of community are connecting them with, different events. And so we're doing exactly that. We have some early stage, prototypes and ideas. We are looking for usability feedback, but also for which parts of this is going to resonate, or what are some unforeseen considerations that we wouldn't have addressed just thinking about this ourselves. That's the power of testing and user research. But doing it early in the development process, such that we're focusing in the direction or the concept where this thing needs to go.

Dan Berlin:

Yeah. So and you mentioned earlier that we can't just sit down and ask folks,"What do you think?" How else can we get at that? What other questions can we be asking folks during these usefulness studies?

Michael Hawley:

That's what I've been constantly trying to think about, as we as I do these studies, is what types of structures? I'm a big believer in having a structure. I'm very curious about different interview techniques or structures sometimes for the reason to have something that we can all rally around and have a structure. So that doesn't go off the rails and just oh, what do you think about this, or how's the homepage? A couple of things that I applied, not necessarily all the time, but depending on the nature of the project, and the concept that we're testing, I do like to start with a lot of storytelling. Before we even get to the design artifacts, to have the participants tell stories. This gets at the pain points. Then I'll reflect back on those stories as we go through the prototype or the concept and say, thinking back on that story that you told about how you had trouble connecting with that other veteran before? To what extent do you think this would help or not help in that? And so connecting your questions in the prototype walkthrough to the stories, I think is a is a big piece of that. Yeah. So another another technique that I like to use is, instead of asking people what they think of something, I ask them to describe it, in adjectives, in words. This is inspired by the Microsoft product reaction cards, if anybody's heard of that method, and the idea there is to have participants really try to articulate what this is, what this feels like to them, or what this means to them in adjectives, and not just do you like it or do not like it. And then what we can do is we can reflect on the adjective as they're using, and compare that to what we were intending the concept to do, right? If this concept was meant to be connecting people, do we get that vibe in terms of how they're describing it and the adjectives that they're using? Or do they describe it in another way? And if so, that's insightful for us.

Dan Berlin:

How are you going about analyzing that data? What do you how once you collect this information? How are you sorting through it and finding those trends?

Michael Hawley:

Well, if we're talking about some of the story aspect to things, what I tried to do is code the intent of the story, or the purpose or the pain point that it's talking about, what's the theme there? Then I have a comparison for what people think of the concept according to that theme. Similar with adjectives and words to use to describe it. I have very explicit questions around that and I capture those adjectives or the voice. Another variation of that is, I might ask if this concept were a person, how would you describe this person? So it's putting some characterization to it. I'll code those as well, collect those examples and use those with the team to say this is getting a feel of a really helpful, supportive person, so that's good. Or this concept is getting the theme of it feels too much like shopping to them for whatever reason. I'm using a short, weird example, but that helps articulate that with the team.

Dan Berlin:

Mm hmm. Great. Any other thoughts about your chapter before we move on to a piece of advice for listeners?

Michael Hawley:

Well, I think with regards to the chapter, the idea is when you're doing formative research, to think of structures and methods that can help you with the ultimate outcome and make some decisions about the direction of the product. Don't just go into it saying we're going to do interviews; have some way to leverage a design artifact, a concept prototype early on, but do it in a thoughtful way that has some structure that will guide you towards some decision making. A lot of formative research I find is, we learn about people and their needs, and that's helpful. But when we need to accelerate it, which is often, use that design artifact to get you further down the path of design. You can always do more detailed usability testing and fine tune certain interaction mechanisms and labels and things like that later. But the overall lesson is you can combine that formative in-depth research, needs analysis with some concept testing and moving things along in your project.

Dan Berlin:

Can you tell us a little bit more about that structure? Is there a little bit more about the way you approach a given study and the structure of how you approach it?

Michael Hawley:

Yeah, I'd say that most all of the studies that I do, in this early concepting phase, have a very explicit opening section that is about that needs analysis is about the storytelling. It is about setting the context and priming the participant to be critical in their thinking. A lot of what you find when you put a concept in front of people is they might be inclined to say, "Oh, this is cool," or "I hadn't thought about this looks good." So I think about having a structure and using that opening interview and discussion to really prime them to be critical so that I can, in a constructive way, I don't mean to say that I just want them to be negative, but I want them to use a good lens, their own perspective to really evaluate this concept. So if I have them tell a story, or if I have them relate a pain point they're dealing with, I'll mark those down in the outset. And then I'll refer back to them as we're going through the concept. I'll allow them to have their own experience and to say,"Oh, that's cool," or "This might be helpful in this way." But then I'll explicitly go back and say, "Well, remember you told this story," or "Remember, you said this pain point was here?" Or "Remember you said that you use some other app or other experience that wasn't helping you in this way? How would you compare that to what you're seeing here?" They have a hard time going back on themselves to say, "Oh, yeah, you were right. So maybe I should be more critical. Maybe you could do it this way or that way." Leveraging that first opening set of questions and referring back to them is a key part of this usefulness testing.

Dan Berlin:

Yep. That's awesome. I love that. Setting setting the stage for them. And people don't like to contradict themselves. So if they get out that honest feedback in the beginning, comparing it is just wonderful, that's great.

Michael Hawley:

Yeah. And you need to do it in a friendly way. I'm not saying well, "You said this before. So now you can't say that this is the best thing since sliced bread." But doing that in a constructive way?

Dan Berlin:

Yep. Yep. Great. So thanks for all that, that was really helpful in terms of how to get this done. Next up, I'd love to hear a piece of advice for listeners, whether it's breaking into UX or continuing in UX, what piece of advice would you like to convey to folks,

Michael Hawley:

I think the big thing for me is to talk about UX. And so I'm doing this podcast here, right? You're doing this, and we've been active in the professional community. That has really helped me in my career because it forces me to be critical of my own thinking. It also forces me to have a vocabulary. A lot of people have opinions about user experience design, apps, everybody has, it's ubiquitous in all of our lives, right. So everybody's got an opinion. The way that we can differentiate ourselves as UX professionals is to have an understanding of the rationale, is to be able to describe why something works, or why something doesn't work. To be able to describe and give a sense of trends or articulate why something is working for the target audience or not. And so, continually talking about that just reinforces that skill. If you think that you're going to be a UX designer and be in Figma and Sketch all the time, and that's rewarding, and figuring out problems in that way is helpful. You're not going to be a great designer if you can't articulate to the rest of your team, to the marketing person, to the developer, why something is working or not. You can't do that. They're gonna have their own opinions and it's just going to be a big mess. Same thing for researchers. You can do the best research that you can do, and you can have this vision of what's working and what's not, but if you can't articulate that to your stakeholders it's just not going to be as valuable. So whether that be leading a workshop with your team, doing a talk at a conference, being the presenter of research, whatever it is, just continuing to practice, articulating the rationale findings and important concepts to others is really helpful.

Dan Berlin:

Yep. And something that jumped out to me there is the vocabulary. The vocabulary that one group uses may be very different from another group, but you may be talking about very similar things. So learning others' vocabulary helps with that storytelling.

Michael Hawley:

Yeah, I think you have to adapt to other people's vocabulary for sure; you have to understand business language, or technology language and things like that. At the same time, you also have to throw in just a couple of one or two key UX terms or phrases. I wouldn't talk about cognitive load too much, right? But every once in a while, it helps to differentiate you and show that you have some background in the academic underpinnings of this and what's the background and the psychology of how people come here, or with color theory, how things work, or grids or whatever. If you have a little bit of that, it can help separate you. You don't want to overwhelm people with that stuff, with the UX buzzword bingo, but a little bit doesn't hurt.

Dan Berlin:

Yeah, dropping the word that helps build credit a little bit there.

Michael Hawley:

Exactly, exactly. And it's legit too, right? So keep studying all that stuff. You and I, we went through a master's degree program, you don't always have to do that, but I think forcing yourself to learn some of the psychological principles that are involved, the visual attention, the visual theory, all that stuff is helpful. I'd say also on the process side as well. There's a lot of process, that's what I've run across a lot these days. It's like,"Okay, we got this big team. And we've been talking about things a lot." If UX people can be thoughtful about the implications of running things in an Agile framework or what innovation practices are, those are all helpful things to talk about as well and to articulate.

Dan Berlin:

Great. Well, thanks for all of that. Is there anything I didn't ask you about today that you're hoping to convey to folks?

Michael Hawley:

You didn't ask me my opinion of the book. I think it's great that we can offer these tidbits. And there's a lot of lessons to be learned. I love the how we can share these in a compilation like this. So much knowledge all in one condense space and it can can lead you to different things that you can explore more. So for those listening, use the book for that reason. I think it's an awesome concept.

Dan Berlin:

Great, great. We're very proud of the way it came out. And as you said, it's just those little tidbits so you can go off and go deeper elsewhere.

Michael Hawley:

Yeah, right. There's more to be found on each of those things.

Dan Berlin:

That's for sure.

Michael Hawley:

This is your as your entry point into a lot of different topics. So thanks to you Dan for putting it together.

Dan Berlin:

Oh, my pleasure, it was wonderful. Well, great. So thank you so much for joining me today. Mike. It's been a pleasure chatting with you about your chapter about usefulness and desirability. So thanks for joining me today.

Michael Hawley:

Thanks for having me. And if anybody's interested in following up on this topic, I'd love to connect with them. I think it's like this mix of... Is this slap in your face obvious that you should be asking questions about this stuff? Or is there a structure, is there more to it, and I'd love to continue the conversation.

Dan Berlin:

Wonderful. Great. So reach out to Mike if you want to continue this conversation with him. Otherwise, thanks for listening everyone and have a great rest of the day.