Per: And welcome to the show.

Jens: Thank you! Thank you for having me here.

James: Was that intro long enough or short enough for you? I’m being a bit mean Jens. Jens is one of our listeners as well and he actually is someone who has mentioned about how long our intros used to be. I babble at the start and we cut it down after Jens’ …

Jens: But many times, I listen to the podcast I think two or three in a row and I don’t listen to them kind of directly when they come out. So that’s probably why I think they’re long because you listen to them after each other and then I guess …

Per: All right. Yeah, so you hear the same thing over and …

Jens: Yeah.

James: Yeah. But now we have the right short music at the start, so you don’t have to listen to the theme tune in its entirety. Unless you want to at the end, then you can. I give you the choice.

So today’s show is going to be about design research. Now, Jens, I know that you held a presentation about this a few weeks ago.

Jens: Yes.

James: Which is what gave us the idea of bringing you in to chat about it. From what I understand, it went down quite well with your presentation.

Jens: I think so. I try to – I’m doing a series right now of different talks where I talk to – I talk about user experience on different levels, on different parts of the user experience and how to work with it. So I have done three now. So I have one every month and I normally start having a brown bag at Valtech where I work.

James: Your brown bag. What do you mean by that?

Jens: Brown bag is where we share knowledge within the company. So if somebody would like to talk about for example design research, you present it to your colleagues and everyone who would like to listen to it, at the company.

Per: The brown bag, is there something in the bag?

Jens: Yeah, brown bag is a lunch.

James: Because I was thinking like booze in a bottle that you’re going through.

Jens: Yeah, that would be nice though. Yeah. We have lunch and somebody is presenting something.

James: So it’s lunch in the bags. Yeah, right.

Jens: Yeah.

Per: I’ve actually seen some adverts for your brown bags and there was actually a picture of the brown bag as well.

Jens: Yeah. So mostly the brown bags are for just internal, for our colleagues, but we’re starting doing it for all sorts of customers that can come in.

James: Oh, OK.

Jens: But then I use – reuse the same presentation for my clients. So when I’m trying to also present the same things for my clients.

James: So the client’s education.

Jens: Yeah, exactly.

James: You work normally as a UX consultant. How would you describe yourself?

Jens: Yeah. I would probably say that I’m a user experience consultant. It kind of depends who you’re talking with. Sometimes you say you’re working with data.

James: Yeah.

Jens: But sometimes you say you’re working with people. So it kind of depends on who you’re talking with. But normally I say I work with user experience and web technology.

Per: Yeah, I completely agree because you never know who you’re talking to and what they’re going to interpret what you’re saying as. So you usually use these words that you think they will understand somewhat.

James: Exactly, and then you’re met with that kind of look when you’re like oh no, it’s the wrong one. This wasn’t a UX conversation. This was a data conversation.

Per: Yeah. I find that it’s easier to have someone else describe a person and what they’re doing. So I actually found a quote on your LinkedIn profile from someone who recommended you and I thought this was pretty good and it’s actually from a woman who I had worked with back in the day as well, Elizabeth Tofen.

She says that, “Jens is one of the few who managed to combine the knowledge about user needs, deep technical skills and the making of user-friendly and tasteful graphical design in one person and that makes Jens unique.”

James: Unicorn!

Per: That’s pretty good.

Jens: Nice words.

James: It’s a nice one.

Per: So you’re kind of like – we say that we talk about a lot that we balance technology and the soft sides of graphic design and users. But you actually do a lot of graphic design as well, right?

Jens: Yeah, because from the start when I start working like in the web, it was in the 90s, 2000s, somewhere around there. You were a web designer and you did frontend development. You did graphic design. You did user research but you didn’t call it that.

You just did web design and you needed to do all these things to produce something. So I have a background and I’m interested in it. But I’m trying not to do too much of the graphic design in my professional work.

If I do design, it’s mostly kind of the interaction design part of it and I leave graphic design to the graphic designers mostly.

James: That pretty much is the same …

Jens: But I’m interested in it, interested in photography and colours and drawing and so on.

Per: But that’s interesting you’re bringing that up about the background of where we’re all coming from and a lot of us talk about usability and UX. We brought the user into the mix and user-centred design but when we’re talking about today’s subject, you mentioned it as design research rather than user research. Why is that?

Jens: Because many times, I see that user research is just a small part of the user experience work because mostly it’s about trying to achieve something in an organization or with a client and it’s mostly about talking to the business, understanding what you need, and trying to match that with the user’s expectations.

But understanding the business side of it is many times half of the work or even more and getting the buy-in from their organization and from the clients. It can be lots of work. So instead of calling it as your user research which is mostly for customers or users, I think design research is like a broader term for it.

James: I like how also it kind of – oh yeah, it positions it quite nicely, not too close to the actual look and feel part and not too close to the development, the creation part. It feels like it’s nice in the middle there to the client.

Jens: But it could be – like where I’m working right now, I’m working very close to the development teams and they can sometimes be a bit scared when you talk about design and because it’s a vague term. You really have to explain because technology and performance for me is also design. So you need to try to explain that also when you’re talking to developers and the ones who are going to build the solution.

So it’s – I think it’s important to kind of describe what you’re aiming for when you’re meeting people or meeting different roles in an organization.

Per: Exactly, it’s the end goal and it’s not how you do it. I try to think of design, the word “design” as synonymous with problem solving.

Jens: Yeah.

Per: Which is really what it is, just thinking back to Leonardo da Vinci and design for me then is something that anyone on the team actually does as you were saying.

Tell us a little more about the talk that you have been giving around design research. What’s the problem? What are people struggling with? What are the problems they’re coming across in approaching design research?

Jens: I would say that firstly, like my own process when working is that defining the problem is a big challenge especially if you’re in a big company. You really have to understand what you’re trying to solve. Many times you start with designing a solution quite fast and then after a while, you understand that you’re just solving maybe a part of the problem because you haven’t talked to the whole organization or a bigger part of the organization, so understanding the problem, scoping it.

I think that’s something you really have to start with in the design research and then I would say after that, you try to – the next phase would probably be understanding the user needs and then to see if – can we solve the problems and how should we solve them by talking with users or customers?

James: I was just relating to the fact that that’s – when you’ve been brought in to do something, then the company has already taken a step to bring in design research or user research or whatever it’s called. You can take one step but then when you come inside these projects, that’s when you realize that the step may be isn’t as big as you thought when initially you brought in. That needs to be reframed.

Jens: Yeah, reframed I think would be …

James: The actual organizational needs inside the project. It might be the case that well, it’s first stage. It’s all about – in fact, actually talking to users and doing user research. The first stage is about team building and that I need to get my – if it’s an agile team or it’s bringing something or it’s project team, I need to get this team on my side first before I can start taking the next battle in this war.

Jens: Yeah, exactly. I agree and I think that as you say, the team is one part of it and getting them to work efficient and a good collaboration within a team and so on. Then understanding the business part of it because there are – many times there are kind of the other side where they’re not so close to the development, and then the authorities of course understanding the user needs. You have different parts. You need to get a grip of. That’s really what – that’s why I think it’s good to call it design research because you’re kind of everywhere.

Per: Yeah. I think though because you’re touching upon something there that there are expectations maybe sometimes from the client that you are supposed to produce something. You’re supposed to produce wireframes. If you’re doing research for two, three weeks, a month maybe, what are you giving them? They’re looking at you and they’re asking, “Why aren’t you giving me results?” How do you actually communicate that to the clients so they understand?

Sometimes you’re brought in to do design research and in that case, the client is mature enough to understand what they’re buying and sometimes you come in and you need actually to convince the client that the problem they brought you in to solve is not the problem you should be solving.

James: Yeah, they bought 100 hours of design research and they’re expecting a bunch of wireframes.

Per: Exactly.

Jens: Yeah.

James: It’s not really what’s going to happen.

Jens: Right now, I’m very fortunate to work with a client that has brought me in that and I’m resourcing a team with a team coach and so – and I think that’s really mature where you’re working with user experience because when they – when I came, it was that I should come in and do two weeks of user research, talking to the user of the system we were going to build and then do some wireframes and then I was going to say bye-bye and go off.

But after two days, I said to the clients, “We can’t work like that.” Of course I could draw up some nice wireframes but after four weeks, it’s going to be – it’s not going to be worth anything because then the requirements have changed.

So I think that’s a really mature way of working. They understand that they need more of a resource that can work with the team, getting them to work better and more efficient and getting the stakeholders also to work more efficiently because many times they don’t really know what they want.

James: That’s very true and the project you’re working on and the case I’m – the project I’m working on just now is that both of them have existing systems which need to be modernized, taken to the web or whatever you would like to say.

So the clients I think – now we’re speaking in behalf of your client. I don’t really know but I’m guessing that they have a picture of OK, we’re going to convert. We’re going to try and slip this existing thing into this new thing. That involves basically just talking to a few people and doing some wireframes and now we can just – now we’ve gotten a new web version of it. I mean it’s the same products and then when you start – when you get in there and you start working, actually you’ve got like 15 years worth of poorly strapped on GUI user interface things and ideas and you’ve got kind of – you’ve ignored user flows. You’ve ignored what’s actually trying to – you’ve ignored the problem.

Jens: Yeah.

James: And this is your chance to actually look at this and reworking from the start.

Jens: Yeah.

James: So the education process when you come in.

Jens: Yeah. We try to minimize just kind of a – I would say it was an experiment that it would reduce my work in one of my projects. I came in and I worked for a while and I helped the product owners to define the problem and understand what we’re going to build and doing design work, working with the user stories and defining them and so on.

They work quite well. Everybody starts to understand what we’re supposed to build and then we try to remove me or I decrease my work in the project to see what happened and they noticed often maybe a month or two that all the requirements that came in were really undefined. It was just like scrapping out on a paper. The developers didn’t really know what’s supposed to happen when you click this and should you come to a next or another screen or should it be like the interaction part of it.

But they cannot really understand what’s really the problem because it was just the kind of – just the small things. But after two, three months, they understood that maybe that guy, that user experience guy, did something good here.

Per: I love that example actually because I mean that’s what – I realized that my main thing that I’m doing right now in the project is actually sitting in the same room as the developers and when they had questions about the wireframes, talking to them about them and that’s my biggest input in the project because if they don’t understand the wireframes, they will start building in the wrong direction.

Jens: That’s one of the articles that I sent to you is kind of what I try to explain is that about wireframes or designing and the work that you do is that – is that something that is – should you – is the deliverable a good thing or not or is it a communication problem that you need wireframes for example or is it better to sit in the seat of the developers?

Per: Right.

Jens: So sometimes – of course that article talks on both sides.

James: The collaboration versus one …

Jens: Yeah, the collaboration. Yeah.

Per: Article on huge matters where lots of people were thinking about how wireframes help them out or not.

Jens: Exactly. And there has been kind of bashing about wireframes that wireframes are bad. You should communicate and I think of course that’s – I agree on that and some projects I work really close to the developers and we have a really good collaboration.

But sometimes you don’t have that opportunity and sometimes you need the wireframes for the product owners or the stakeholders. So they should understand and you can’t send it on their lap and maybe just talk about a solution and then you need to kind of build a consensus and so on with the science. Like always, it depends on what you’re …

Per: Yeah. So you can’t really talk about the wireframes as yes or no. You talked about the whole consolation of the team, the whole project. No two projects are the same and then it all depends on how are you using the wireframes. Is it like your example there where you were expected to leave the wireframes and then just leave the client or are you sticking with the client and using the wireframes as a communication tool?

Jens: Yeah.

Per: In which case, it’s actually helping the communication.

James: We’re talking about – this is effectively a discussion about return on UX investment. I mean is it worth your investment of time producing a full suite of detailed wireframes compared to using wireframes as a communication tool when you see the need for it? Wireframes can be something you’ve scribbled up on the whiteboard during an impromptu meeting or it can be a clickable product that you’ve made spending maybe half a day doing it?

But again, I hope that you’ve made a decision that yeah, this is an investment of four hours that is worth it to get this project moving to the next step or to communicate. It develops or communicates to the management, whatever. We need to do this investment to get that.

Jens: Yeah.

James: Whereas you get these questions about, “Can you do wireframing for a month fulltime for an agency?” My heart sinks.

Per: Exactly.

James: No. Actually, I want to because I’m not convinced by the return on investment.

Jens: Yeah, exactly.

Per: And actually it all depends on whether you look at the wireframes as something that is through or a suggestion. Is it black or white? Well, most of them are black and white. But I’m thinking about how they’re perceived as – if you’re looking at it as a frontend developer, sometimes you’re expected to build it exactly like the wireframe. But in the project I’m working in right now, people see that wireframe and they’re seeing it as OK, so that’s Per’s suggestion but I’m allowed to challenge it and we can talk about it.

James: Exactly.

Jens: Yeah.

Per: Which is a much more open way of approaching wireframes, I think.

Jens: Yeah. I try always to say that this is my suggestion and it’s just a sketch.

Per: Exactly.

Jens: And many times, the developers come up with much better ideas.

Per: I know, exactly.

Jens: And I love it and I try to push them to like do something better if you can and I always see the – you should really see design as – for me, it’s a language more. Sometimes it’s easier or for me, it’s easier to draw something out on a piece of paper on a whiteboard than trying to explain it. So for me, it’s designed as more kind of a language trying to describe a problem.

Per: Exactly. It’s a visual language which puts some – everybody on the same page so they have something to talk around. That’s really something that makes people talk.

Jens: Yeah.

James: You could say that it’s an advantage maybe with not taking on too much of the end design of the art direction side of things as a UXer because by sticking to your suggestions, your wireframes, whatever they are as suggestions and not producing final designs, then you strengthen the understanding from others in the team that these are suggestions. These are not the end of things. You can clearly see this is not how our product is going to be. So let’s work with this rather than look how pretty this kind of final design is and then they get stuck on that.

Jens: Yeah.

Per: Yeah. We’ve sort of deviated from our design research topic.

Jens: Yeah.

James: We have.

Per: But I love this discussion that we’re having. But there was one question that sort of popped into my mind when we’re talking about design research and getting the mandate to do research is there are lots of different types of research.

Jens: Yeah.

Per: You can spend as little or as long as you want on it. How do you actually decide how much time is enough and how much money is enough to spend on it and stuff like that? How do you get started?

Jens: Yeah. My angle on that is that on my slides poster, it’s – there is a book about how much – I can’t find the title right now, how much is enough design research for something, how much – yeah. I think it’s – because many times, or I come from a background where you did lots of research either in the beginning of the project. You did a big pre-study with lots of research and lots of design and that’s one way of doing it and the other one is that you put a lot of research in the end of the project like validating, quality assurance and so on.

Right now, I see that user experience and design research are more of a part of the development process which is where you’re really learning something, all about the technology and I think it’s the best way to learn something about the business side of it and the user side of it. It’s in the development process and so, you’re saying when is enough.

Per: Yeah.

Jens: I would say that the answer is when you answer a – or when you ask a question, and you don’t learn anything new, then you’re done.

James: You’re definitely done.

Jens: Yeah, but that doesn’t really happen too often. Normally, doing like traditional usability testing, you start with like one user testing a website and you learn a lot; the first user, testing the site.

Then you try with a second user from the same part of the group. You learn probably lots again but maybe not that much. Then after a while, it flattens out, that curve of learning. I have one slide in my presentation that kind of illustrates that and I stole that from someone. I’m not sure who I stole it from but Jakob Nielsen, the old guru, he researched on how many users you really need to have on usability testing and he says that five is good enough. I would agree on that because after five users, you really get bored.

James: That’s right. He says I think 80 percent of the big usability issues are going to be found if you talk to five people.

Jens: Exactly. But you really need to be – it has to be within the target group because if you’re using – if the website or the system has kind of the private customers and the corporate customers, you really need to test with five users from different target groups.

Per: Yeah.

Jens: So you just use five users in total.

James: The whole thing about one is enough. We know that effectively is never enough because your product or your website, whatever, it’s constantly in a state of flux. Your customers and users are changing. Their world is changing. Everything is changing and what we’ve learned over the years is that we’re dealing with an incredibly complex thing.

Jens: Yeah.

James: And for just a few people to understand everything that’s going on and everything that has been built and how it all pieces together is now impossible. So there’s always going to be a question that someone has got or someone can always learn something about what’s going on I think, and optimize it or tweak it or correct it or adjust it or realize how it fits in something else.

Jens: Yeah. That’s really hard. Also what I see done right now with working with clients that they deliver their for example three teams, web teams, working with external websites and they deliver new solutions and new widgets and new stuff on the websites. It’s everyday or every week they deliver something new and I think that’s one of the hard things to – I should say that the site is in flux and it changes all the time that when should you test it because – should you test it every week? How should you follow that up? How should you measure it if you do use web analytics or surveys or meeting people and understanding how they work or how to use the site when they’re at home?

James: How do you feed the validation loop?

Jens: Yeah, exactly. It’s quite hard when there are so many things changing all the time.

Per: I’m guessing it’s about being open all the time to input from users and realizing that you are getting input from users all the time and seeing it as something that is beneficial to the site at all times.

Jens: Yeah.

Per: And stop thinking about how and how much and start thinking about doing it all the time.

James: At the same time, we’ve got the deliverable from us as UXers or web people that we have to put the framework in place to enable this kind of collection of data or observation of what’s going on because going back to the whole wireframe thing, you’re just spitting out wireframes or doing a kind of two-week stint inside a project to design the user interface and that’s not helping the long term – the sustainability of the product whereas other things that we’ve talked about previously, patent libraries or maybe even a framework for how you would – or designing how you – where do we need to collect data to give us more insights?

Not just kind of from a conversion point of view, from a sales point of view with web analytics. But what could be good for us so that we learn more about how people behave when they’re using a website? Which isn’t necessarily the same thing as how did they put that in the basket and how many checked out with that product.

Jens: Yeah. Yeah, I’m interested in trying out – because normally when working with teams today, you have the Scrum board or the Kanban or something like that and that’s kind of a – they have a development perspective on that board. Many times, the user experience work is not included in that because many times, I stand and just listen to what the developers are doing.

They have their lanes and they tend to have – they have some kind of design or research phase before and then you have – you bring the stores into the development phase and they’re doing acceptance and then it’s maybe production. But there’s no design or user research or design research, anything on the board and it would be really nice to try to add kind of any design research stories into the development phase or on the board.

So for example, a story could be learned more about this user X in this situation and it doesn’t have to be me, as a user experience doing the work. Anyone in the team should really – can take that because you really want the whole team to get the knowledge instead of me as a user experience getting the knowledge and I have to tell them or write something down or present something.

Per: Absolutely. I totally agree and I mean that’s how we talk about Scrum boards all the time. Anybody should be able to take anybody’s – it’s hard for me sometimes to take backend and quit the database and that all depends – we’re talking about maturity of clients. We’re talking about maturity of the people on the team as well, how confident do they feel actually doing stuff like that.

James: Actually earlier this year I did some news observations about customer using the client’s products, which acquainted us to the developers because they had had it on their development plan to visit a customer to see the code they’ve been producing being used. It has been on their development plan for years.

So we eventually get them to come along and they sat there and I mean they didn’t observe of course in the same way as what I did, but they sat down and just were fascinated to see someone using the stuff they created and were blown away by how they did certain things and didn’t do certain other things. The reality of the situation where someone was actually using their products was so valuable, the experience for them.

Per: Have the exact same experience. Really early on just trying out the interface with the client and seeing them struggle with it made the developers go, “Aha! So that’s what they’re doing. I never expected that. Why are they doing that?”

Jens: Yeah, yeah.

Per: It’s amazing.

Jens: They can ask it right away.

Per: Yeah.

Jens: Yeah, it’s really valuable.

Per: So what we’re coming down to really is that maybe we as UX designers, we sort of have the top knowledge or some sort of responsibility about this. But I think everybody on the team should also feel a responsibility for the testing, for the research, for the design, which is interesting and I think we’re moving towards that more and more actually just in the project …

James: UX coaches, rather than UX strategists and UX designers and this other thing. We’re holding hands.

Per: We’re enabling others to do what we’re supposed to do, what we used to.

Jens: Yeah.

Per: Yeah, whatever.

Jens: Yeah, we’re leaving …

Per: Figure that out.

Jens: Yeah, we’re leaving the deliverability of business.

Per: We stopped doing work. We’re letting others do it for us.

Jens: Yeah.

James: We’re mature.

Jens: Yeah, I try to tell everyone that I’m working with that when I meet them, I say I’m not the one who’s going to design the system. You are or we are.

James: It is. I think we’re going to have to start wrapping up but I – don’t turn off everyone. Listen, we’ve got one more question. So if you’re a UXer in a team and you’re – what would your advice be for them to kind of break through and take that step to moving with maybe the wireframes business and being more of a UX coach? What’s your kind of – a couple of tips there of what you …

Jens: Yeah. Firstly, when I meet new teams or team members, I always have a kind of a session with them of what is user experience. I have a slide about introduction to user experience and I try to explain to them how I see on the matter and that I’m not a GUI guy and I try to understand all different facets of user experience. I think that’s a good approach. That’s a good start so everybody gets on the same level. So they understand that I’m not going to draw them nice pictures and colours and that stuff. I’m going to do kind of other stuff.

James: Cards on the table.

Jens: Yeah.

Per: Right.

Jens: Also trying to be – I’m kind of open about how I like to work and say that I’m just – I’m going to try to help the team and the project, but I want ideas and solutions from everyone. I’m not going to sit on a high horse and dictate. This is how it’s always going to work.

Then I try to help them with different tools. For example a design studio I think is a really great way of working, of trying to …

James: That’s a good suggestion for another episode.

Jens: Yeah.

Per: Yes.

Jens: It’s to get everybody onboard and everybody can collaborate on trying to settle problems.

Per: Exactly.

James: Yeah.

Jens: And there are different kinds of tools that you could use and trying to introduce it to the team.

Per: So as a UXer, you have to be a nice person with lots of empathy.

James: And big ears.

Per: You want to bring us out James? Thank you so much for joining us Jens today. It has been wonderful.

Jens: Thank you.

James: It has. Thank you very much for joining us at long last.

Per: Fantastic discussions as well I think.

Jens: Yeah.

James: Really good.

Per: Lots of value for our listeners.

James: We would love to hear from you, feedback. Tell us what you think of today’s show and you can find us everywhere as UX podcast. Absolutely everywhere these days. On UXPodcast.com, you can find that there will be some links. Well, I will link up all the articles that Jens suggested to us and ones that we’ve mentioned today.

If you’ve enjoyed UX Podcast, then well, you can actually tell people. It doesn’t really have to be a secret. What you can do is you can go to iTunes and you can give us a review.

Per: Oh, fantastic.

James: There’s a suggestion for you and – oh no, you go first. Go on.

Per: Oh, yeah. Remember to keep moving.

James: See you on the other side.

Hide the transcript