A transcript of Episode 236 of UX Podcast. James Royal-Lawson and Per Axbom discuss why “designisms” are a problem and how to write user reasearch insights.

This transcript has been machine generated and checked by a human.

Transcript

James Royal-Lawson
UX Podcast is funded by me and Per, together with contributions we get from you, our listeners. Help support UX podcast and the UX community! By contributing financially to keep the show running, visit www.uxpodcast.com/support and contribute as much as you can.

Computer voice
UX podcast, Episode 236.

[Music]

Per Axbom
Hello, I’m Per Axbom.

James Royal-Lawson
And I’m James Royal-Lawson.

Per Axbom
And this is UX Podcast. We’re in Stockholm, Sweden, and you’re listening in 194 countries all over the world from Slovakia to Nicaragua.

James Royal-Lawson
It’s been a while since we mentioned the weather Per. But, I think this is the first time I can remember, that I’ve recorded this podcast in a thunderstorm.

Per Axbom
Right, care mentioning it.

James Royal-Lawson
Yeah, and I can hear it and when it thunders I definitely can hear it. So this is one of those podcasts now we’re gonna have some like atmospheric sound possibly in the background, at least my microphone.

Per Axbom
And today, we have for you a link show. And a link show is where we have two articles lined up to talk about, that we found during our digital travels. The first one coming up is Why designisms are a problem.

James Royal-Lawson
And this one is by Josh Munn, who is an experienced designer based in New Zealand and has spent the best part of his design career working in healthcare environments.

Per Axbom
And our second article for you today is How to write compelling user research insights in six steps.

James Royal-Lawson
And this one is by Nikki Anderson, who is @producttherapist on Twitter, and she is a user researcher based in Berlin in Germany.

[Music]

Per Axbom
So I know you have a bit of a backstory to how you found the first article, James.

James Royal-Lawson
Yeah. Well, basically, the first thing I came to contact with, in connection to this article was a poster. A poster about people and listing a number of roles within our design work and defining what they are and what they kind of really mean. So the UX designer, UI designer, service designer, front end Dev, back end Dev and users, and I really like this poster. It appealed to me and appeals to the kind of like, side of me that likes the plain speaking, user language.

And I backed up and realised this was one of a set of three posters. And when I realised it was a one of a set of three posters, I then saw that in itself was a follow up article to another article. Talking about designisms, or the jargon and the complicated language we actually use. So I backed up three steps from what I found to actually what we’re featuring as an article today.

Per Axbom
I like this one, because I have sections that I agree with, and I have sections I disagree with.

James Royal-Lawson
Oh, interesting.

Per Axbom
First off, what is the designism?

James Royal-Lawson
Well, I’ll tell you what, I’ll start off by reading first a little bit of the article. So, Josh, he opens up by writing or describing a general conversation he says he has almost every other week. And he says it goes something like this. “Hey, so what do you do for a living?”

Per Axbom
“I’m a UX designer.”

James Royal-Lawson
What’s a UX designer?

Per Axbom
UX stands for user experience.

James Royal-Lawson
Deathly radio silence…

Per Axbom
I basically design apps and websites for a living.

James Royal-Lawson
Oh, so you know how to code and stuff.

Per Axbom
Now I can’t code. I kind of do everything up to that point, you know, like, look and feel of the app. What you see, how it works. I work with developers, though.

James Royal-Lawson
Oh, so what do you actually do? I mean, all of us, all of us recognise that conversation. I mean, we’ve, we’ve all had it probably regularly as this as well. And, if not with people in our own branch, with relatives, with your mother, with friends. It does happen an awful lot. Because what we do when you describe it as a set of a UX designer, doesn’t really say very much.

Per Axbom
And I think we have talked a lot about this on the show as well. We’ve sort of almost gone tired on UX podcast with the term “UX” because it’s not self-explanatory in any way. But it is a term that we can throw around to find our tribes. So, you’re in UX, I’m in UX. And that’s how sort of we find people who are of the same mindset as ourselves, even though we may not know, if we work with exactly the same things, we know that we have sort of the same types of goals with helping users with the default terms often.

James Royal-Lawson
Yeah, we have discussed that before how UX is used almost as a kind of a signalling element within our industry to say: “Hey, look, I’m one of your tribe”. But as far as the overall user experience of the phrase user experience, it’s really badly designed from a user experience point of view. It doesn’t really cater for other groups of people who might come into contact with it.

So Josh, though, he is focused, he isn’t really kind of bitching mainly about UX as a phrase. It’s actually a bit broader than that. And he’s talking about design jargon, design phrases and things that we use and we throw around in our work and what we produce. That aren’t necessarily easy for people that we work with or stakeholders or users of the products we design can understand. And Josh would like us to develop alternatives and to try and put an active effort into using those alternatives, instead of the convoluted phrases that we have adopted.

Per Axbom
And he describes the background to how he came upon this really as seeing it as a growing problem was when he was at a conference and someone started talking about not only UX but also CX and BX and PX. And people just love playing around with that term because it’s so… it’s sexy in some way. I mean, it’s short, it has the X letter, and so that’s fantastic. It’s I would say customer experience, and I don’t even know what the other two are. Product experience, PX probably.

James Royal-Lawson
Business experience maybe? Don’t know what the BS was.

Per Axbom
Must be. But that really doesn’t help us at all. It just creates more confusion. So that’s going in completely the wrong direction. So what he’s saying here is “Let’s go the other direction and go move away as far away from as possible from these terms”. And try to be as explanatory as possible, use simple terminology, and give background to the terminology. And really not use it at all.

And here’s maybe where I, disagree with some part of parts of it. He’s even saying that we should not be using it with our peers, with the people that we work with. And I think I understand where he’s going with that, because not using it with our peers helps us to always use the user-friendly way of explaining things.

But on the other hand, it’s when you work within an industry, within a profession, having the same terminology as a shortcut for talking about things. I mean, it’s true for all different types of industries. And I think that that can be really helpful in itself. So I’m not sure that you should always avoid it, but you should always be concerned about: “Is the peer person I’m talking to understanding me? And how can I become better at describing the work I do? And the value I bring, really?”

James Royal-Lawson
Yeah. Because I mean, this is, I guess the essence of communication that all communication is trying to do is reducing the amount of guessing the other party is performing in order to understand what you’re going on about. And by using simpler language, we’re reducing the complexity, we’re increasing the chance that we can communicate in a way that’s understood.

Per Axbom
Right.

James Royal-Lawson
Exactly what you’ve said, and I agree with you that some sometimes it’s going to be correct to say, personas, or MVP. In other situations, no one is going to have any understanding what MVP means or they’re not gonna have the same understanding as you even though they understand the phrase.

Per Axbom
Exactly.

James Royal-Lawson
MVP is a pretty good example of that. I mean, this is almost everyone’s got their own definition of what MVP means.

Per Axbom
That is a good example. And in fact, in a project I’m working in now (I’m just starting up a new project). We’re taking time and putting effort into putting together a glossary of terminology, because even the simplest of terms, people do not agree about what they mean. So that’s why we make sure that we make a list of these terms so that whenever we use it, especially in documentation, we know what we mean. And I mean, I think that’s a recommendation for most projects. That’s something to do. We’re not specifically in this project doing it for UX terminology, but for healthcare terminology, but it’s the same principle I think.

James Royal-Lawson
Well, I think that’s a principle that any team would need to work on. We’ve discussed that before, as well when you have a shared vocabulary within your team or Design System or whatever it is you’re working on to make sure that everyone around you is on the same page when it comes to the phrase you’re using. And then everyone, at the other side of any communicating edge you have, also is on the same page, whatever language you’re using outwards from your group, your tribe, your team.

Per Axbom
Exactly. And one thing I might feel like I’m missing from the article, perhaps is this opportunity for actually listening more to people. So I agree with that we shouldn’t treat people like toddlers and explain it like basic-basic, but we can also have the opportunity of asking people, what do you think this means? And start learning about what do different words mean for different people? Because then it turns into conversation instead of me just trying to explain something to you, without also constantly checking: “Do you understand what I’m saying?” Because even in some of the examples he’s using to simplify, there are still words and phrases, like even the word interface. I know a lot of people don’t understand that word. So, with different people, we have to use different levels of simplification as well.

James Royal-Lawson
Yeah, in essence, it’s like peeling an onion, isn’t it, I guess?

Per Axbom
Yeah, exactly.

James Royal-Lawson
I mean, one of the examples here was “mood board”. And yeah, that’s a phrase that maybe a lot of people don’t know what it is. And then describing that as a collage of images, fonts, interactions and icons, you might need to even explain what a lot of those phrases mean. Interactions, what’s an interaction? So yeah, you’d have to then sense and respond. Kind of feel how is the person responding to that? Have they understood the language? Okay, I need to peel another layer off the onion and go one step simpler.

But if you’ve already prepared the onion, you’ve already kind of come to an agreement about not just kind of what’s the high level, convoluted phrase that we’re going to use within our need, within our little clique. How do we describe that to people who have a little bit of understanding of the sphere of work that we’re working within? And then how would you describe that to people who have absolutely no idea?

Per Axbom
Exactly.

James Royal-Lawson
But if you’ve gone through those different layers in advance, then it really helps you, I guess, present one as a united front to us, who are you communicating to.

Per Axbom
And I think this really is a call to action. That’s what I really like about it and I want to take away from it is that it actually encourages people in teams to make this effort and that’s what the posters are for you put them up to the office, you remind yourself that we can’t always talk like we’re talking right now. We need to find other ways of explaining the work we do.

James Royal-Lawson
Yeah, and that’s an excellent point prior to where I started by seeing the posters.

Per Axbom
Yes, exactly.

James Royal-Lawson
I was really attracted by the fact that I said in the beginning of the podcast that the first poster I saw was one that said “People”. So, keep it simple. Stop using designisms. And then people listed these roles and described them. Try to describe them in a more simple. Now the other two posters in this set of three are things and methods. So methods are like “persona”, “AB testing”, “agile” and so on, “MVP”. And things are, I guess I’m gonna use one for myself now: “deliverables”, “mood board”, “service design blueprint”, “wireframes”, “prototypes”.

Per Axbom
Yeah.

James Royal-Lawson
But if we ignore the content, the process for the things that are listed, but just keep it to those high level titles of methods, things and people, that’s a really good starting point for these discussions and like you’re saying about building up vocabulary or at least just doing a stock-take of what you’ve got and working out how you are going to describe these phrases you use in different levels of complexity.

Per Axbom
Exactly.

James Royal-Lawson
Because all these, because I look at this list, there’s only what, six on each poster? I mean, we all know there’s a lot more than six within each of these categories in our design world. Yeah, you could add a zero to some of these, and you probably still wouldn’t run out of phrases. But as as as buckets of types of phrases, then I think it’s a really good starting point.

[Music]

Per Axbom
All right, let’s move on to the next article. So this one is titled “How to write compelling user research insights in six steps”. And it’s written by Nikki Anderson. And it really ties into what we were just talking about with words and what they mean because what Nikki has realised is that just the word insight, we talked, I mean, we talked about this thing all the time, we do some research and people go back at the office: “So what insights that you get?”, “Oh, we learned this and this”. We haven’t really decided how to express insights to make them valuable, which I find really funny.

So what she starts out with is that she’s realised, well, all the user research in the world doesn’t matter if you don’t produce insights that organisations can use. So in essence, an insight has to be something that the organisation can use, of course. And it has to be based on research that a team can use to make better decisions. We know this, that’s generic definition of our user research insight. But then she goes on to also explain, well, that’s isn’t necessarily wrong, but it puts the idea of an insight into really small box.

And the thing, the difference is, how do we make insights be user-centric, instead of product focused? How do we make sure that what we communicate about what we learned how do we communicate that in ways that we understand that it’s a human being having a special needs or demonstrating a special certain behaviour?

And, of course she’s throughout the article always stressing that: “There are no insights, if we actually don’t do the research, we have to have conversations with users to actually get any insights”. It’s not, we can’t sit around at a meeting, in the office with our colleagues and have insights about users. That’s just not the way it happens. Insights come from talking and engaging with users themselves. And so she goes on through some things that are not insights, listing “an observation”. An observation is interesting. You can observe a user doing something that may be interesting. But the observation by itself is not an insight, because it doesn’t tell us why they’re acting in a certain way. Why they’re performing what you’re observing them doing? Which ties into…

James Royal-Lawson
Ah, what I was waiting for is like: “Okay, what is that added little sprinkling of fairy dust that makes the observation into an insight?

Per Axbom
And it’s like you and I always talk about when we talk about quantitative data, it’s really interesting to see that we have this bounce rate. But always when they come to this page, they leave. But that’s not the insight. The insight is why they leave. So we have to dig deeper.

James Royal-Lawson
Oh, what was fascinating… Sorry I’m cutting in the middle of your experience. Well, what I’m actually working on today is an analytics report, where I need to deliver a lot of insights based on quantitative data. And this is fascinating to see that: “Okay, they’re not insights unless we do actually have real user contact”. I’m not going to have that in this bit of work I’m doing. I’m just looking at the data.

But I’d argue that there are some insights that I can come to by looking at a combination of things that are there in the data. I mean, okay, maybe it would be nice to validate them even more by talking to them. But certain things you can see. A certain type of behaviour is evident from the data. And you can even infer…

Per Axbom
Ah, but then you’re saying “evidence”as well.

James Royal-Lawson
You could infer evidence and infer why they’re doing it.

Per Axbom
Yes. Which takes me on to this point because this is one that I really actually, I did a double take and I realised, well, I’ve been under…. Well, I don’t have to, we don’t have to say that she’s right in every aspect of the article, but I do take to heart everything she is saying in the article. And when she’s explaining this about the difference between a finding and an insight, that’s when I realised a lot of the stuff that I’m calling insights are just findings. Because something with a short shelf life is her point. Insights tend to have an impact over a few months or even years and they can influence the future product strategy.

But if you have something, information about something you want to solve today, that you see people making mistakes in a checkout form, or checkout process. That’s just a finding, and you fix that. That’s not an insight. It’s just something you write, that it’s almost like a bug. Okay, so we see that’s the problem as we fix it. That’s a finding. Insight…

James Royal-Lawson
Yeah, I can see that, I can get that. Yeah, with findings, if you’re looking more within what’s going on and seeing something that you can tweak within it.

Per Axbom
So the findings are still really important. But they’re not insights. And also, back to, of course, the point that we always make when we do user research, just because people tell you that they have a preference or they like something that’s of course, also not an insight you have to dig deeper into the root cause of that preference, of course.

So she sort of goes into really identifying things that I would probably in many projects have called insights. But if we are to declare an insight and finding insights is something useful to the project and to the organisation. We probably should agree like we were talking about in the previous article agree about what an insight is.

James Royal-Lawson
What an insight is? What a finding is?

Per Axbom
Yes, exactly.

James Royal-Lawson
All these other variations of things that are very close to each other. Yeah, interesting.

Per Axbom
What she’s saying here, she’s breaking it down into: “So it has to be a discovery about human behaviour that leads to, gives you a new understanding”. “It’s information that challenges what we believe”. So, maybe it perhaps negates or changes the way that we’ve viewed users in the past. Or it’s knowledge that reveals fundamental principles that drive us towards seeing users in a new way.

So understanding the user’s mental models on how something should work. So it’s always coming back to the user and how they’re behaving and how they’re thinking. The thinking behind their behaviour, really. Why they’re doing stuff? Those are the really interesting insights that you can use to design things that are sustainable across a longer period of time. So it’s not just about finding stuff to fix. It’s not like doing a usability test. In usability tests you often have findings, but in research you have insights. Is what I’m sort of taking away as well.

James Royal-Lawson
One thing I really like from what she’s written and something I try to bake into my work, even if I am doing insights that maybe aren’t really insights sometimes. Is this whole thing about recommending the next steps?

Per Axbom
Yeah.

James Royal-Lawson
It’s really valuable that, for me, it helps even helps you in the situations where sometimes you can’t give a concrete next step. I can’t say, fix that, do that. Design, do this design or change or so on. Sometimes the next step is more research, for example.

Quite commonly, I’ll recommend more research and this is ideal in quantitative analysis and analytics. And I need the qualitative research to go on top of that, sometimes. I can’t say why. And to help me communicate that, then I will I will recommend and I’ll maybe even recommend a type of qualitative research to do. To help you understand the why behind what I’ve seen.

Per Axbom
Exactly, yes. And then she goes on to have a specific structure and that’s the number six from the title of the article. Is the six steps to actually explaining an insight. And without using her example, I was going to try and see if I had an experience earlier today because, I’m looking to buy a printer. Like one of these that you can scan with and print with obviously, and copy with so.

James Royal-Lawson
You’re buying a printer Per, you’re so old fashioned.

Per Axbom
And it has to have an ADF, an automatic document feeder. So I did some research and realised that this is probably the printer I want and I found a really good price for it on a website. And I went to the website and says: “Well, we don’t have any stock but we think we may have one ready for delivery in two days”.

So there’s a chat button. I click the chat button and I go. So I see that this printer is maybe being able to be delivered in two days. Can you give me more information? Because that’s just two days away? And he’s “Oh, no, I have no information”. “Okay, thanks”. And as soon as I said, “Okay, thanks”, he closed the chat, which was hugely interesting to me, because I was expecting “Is there anything else I could help you with? Is there any other product that you’re interested in?” I mean, what you would expect from a salesperson?

And I realised that from this, I realised that I actually was interested in buying from this company and if he had asked me about it, so what is it that you were looking into, and why I was looking for that printer, I could probably have sold me another printer with similar specs.

And that’s a finding. That I wasn’t satisfied with the service and that he could probably sold me something. But the insight is: “Just because you don’t have the product I want doesn’t mean I don’t want to buy from you”. And if you’ve expressed that as an insight, I mean that opens a whole plethora of different things you can do to actually introduce other products to people even if they’re not finding the product that they want.

James Royal-Lawson
Or, spin-off other research questions from that, because just that fact, that insight that you said there, isn’t the end of the story.

Per Axbom
Yeah, I mean, yes, exactly. You can always go deeper.

James Royal-Lawson
How can you, how you are receptive to what type of messaging you receptive to? What kind of things are you open to? I mean, if someone’s too pushy into sales, that you’re going to be backing off and you’re not going to be interested. So there’s so many more aspects to spin off from from that which is fascinating.

Per Axbom
So always go for the behaviour and not just the action or what’s happening. The root cause is what we’re after.

James Royal-Lawson
Yeah, root cause motivation, communicating the consequences.

Per Axbom
And what is also encouraging here, of course, when you’re doing these six steps and how you want to explain. The insight is that you express it in the first-person voice of someone using the product or service, which makes it feel more personal. This works well with some people and not always with other people. I think the way you present something always also has to be within the context of how you’re presenting it to. Are you presenting it to a design team, are you presenting it to developers, are you presenting it to managers? I think that will also have an effect on how you choose to present it as well. I think designers really like the way that you present it.

So often if you are doing user research and handing it over to designers, I think this would work really well. But I do like how both these articles remind us of how easy it is to throw around words all the time, expecting others to have the same interpretation of them as ourselves, and even the words that we are sure that we actually do have in common. Like, I’m sure that you and I could yesterday have had a conversation about insights and been in complete agreement on what we mean. But then we find a third person who disagrees and we realise: “Well, I’m willing to change some of my perception of what an insight is, absolutely”. So always be able to challenge yourself and how you interpret your own work is really, really important.

James Royal-Lawson
I think that ties in really nicely to the very end of the article, she writes a summary. And the first part of point one of her summary is: “Be grounded in reality”. And what you’re talking about there can have a reflection and considering what you’re doing, is grounding yourself in reality. And by using user research, direct observations of users, then you also ground yourself in reality. And the last point in her summary as well is: “Help solve actual problems users are having”.

Per Axbom
Yes.

James Royal-Lawson
And that as well ties in with what we’ve talked about in the first article, that sometimes the person you’re communicating to, even internally is the next step in your communication chain. And you have to understand the problems they are having, understanding what you’re trying to communicate.

Per Axbom
Oh, you said something hugely important there when you said communication chain. I mean, that’s something we tend to forget because it’s this whisper game. I don’t know what would be the English term for it.

James Royal-Lawson
“Chinese whispers” is what we normally call it when playing at school, yeah.

Per Axbom
I mean, that’s what is always happening in all organizations. So you’d say something and someone else repeats it. But if they didn’t understand what you said in the first place, when they repeat it, they’re going to repeat it in a way that doesn’t make sense to you if they would repeat it back to you. But that is going to be repeated by a third person to another person. And so that again, makes you realise how hugely important it is that you actually check that the person you talked to understood what you said.

James Royal-Lawson
Yep. Which, looping back, grounding what you’re saying in reality. If the other person on the other side isn’t understanding you, then you’re gonna have a real hard trouble getting any further down the road.

[Music]

Per Axbom
James, you’ve added a suggestion for recommended listening after this show: Episode #129, “Beyond user research” with Lou Rosenfeld.

James Royal-Lawson
Yeah, that was actually from almost exactly four years ago. When we chatted to Lou. He was talking about going, like the title says, beyond user research and the importance of combining your research with other data points. So I actually chose his article before we talked about the articles, but it actually feels even more suitable to listen to.

Per Axbom
It does. Fantastic. And of course the links to that show, to the articles. You’ll find them online on www.uxpodcast.com

James Royal-Lawson
And if you’d like to contribute to funding UX Podcast, then please visit www.uxpodcast.com/support.

Per Axbom
Remember to keep moving.

James Royal-Lawson
See you on the other side.

[Music]

Per Axbom
So James, have you noticed that spring is here?

James Royal-Lawson
Yeah, I’ve noticed that springs finally arriving.

Per Axbom
Yeah, I got so excited, I wet my plants.

James Royal-Lawson
Oh! You see, now the problem with that joke is I see the other meaning in my head. Another play on words is what I see in my head. And that’s unpleasant. And I know you’ve just bought a new chair.

This is a transcript of a conversation between James Royal-Lawson and Per Axbom recorded in May 2020 and published as Episode 236 of UX Podcast.