Qualitative Research In Startups

Catherine Descure at UXDX Community: Copenhagen. Video: https://youtu.be/SLI-v2gAxrY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From consultancy process to startup reality

[00:00:00] I come from industrial design education, with a lot of theory and how you should do things and processes. And I've tried writing[?] consultancies as well, different kinds of consultancies, some of them more focused on user research, ethnographic research, trying to impact marketplaces through understanding people. That's been the biggest influence so far, as well as interaction design. So, inspired from ethnographic research into building viable solutions for our clients.

[00:00:49] And all in all the whole process has been about that beautiful rainbow. The process is more or less that one. Ideally you would explore who the users are and you would draw conclusions from all the users you've met, identify their needs carefully, and then make sure that there is a business out of that. You design a nice flow, you test them carefully before you launch, and then you develop, and then you have a great product.

[00:01:25] And in some way that's what I experienced consultancies doing. They have their own part of the process and they sell part of the process, and that's what you buy. It's a piece of process, and you buy it within your means, and it's always frustrating because it's never enough and you always want more user research, but it's always a process you sell.

[00:01:49] And when moving to a small startup that has started from an idea and a business potential, the reality is that you have to move fast. We need to build something to sell it, because they are ready to compete with each other with money, and in that period there is no money. So you have two great creative entrepreneurs. They have a great idea, they know there is a business, they find the developer to make it, they find the UI designer, they pay to make it super cheap if they are not themselves entrepreneurs.

[00:02:31] And then you launch, and then you get the money, and then you iterate on that. Where was the deep understanding there? The one that is so dear to me, understanding the market. Then you have to try to fit it in there, but the product already exists and it's really hard to make it happen.

[00:02:51] So that's what I'm going to focus on today: trying to build qualitative research into tech startups, agile startups that want to move fast and cut costs and shorten costs. There are some good quotes I heard when I started in startups. "We have developed this feature already, developers are ready, we have to research to find out how people are going to use it." A bit sometimes putting a stick in the spokes, let's say, what I'm provoking. Also, "but we are user centered, we build stuff fast and then when people complain, then we iterate."

[00:03:38] What I like to keep in mind is that so that people complain, people have bought a product and they are disappointed. So they have reached a moment of frustration that's so big that they have to complain to customer service. And that works for features and to tweak functionalities. But I don't think that works for user experience. It has to be a little higher up, it has to be better than that.

GenieBelt and transparency in construction

[00:04:04] So currently I'm working at GenieBelt. It's a good sum-up. And it's a company that I chose because they want to build a user centered product. It's not a fight, it's a solution. Sometimes it's easy to say, it's always a word that sounds good. But it's also a company that works on agile premises, and that's the challenge, and that's why I think it's fun.

[00:04:40] So what the company does is bringing transparency to the construction industry. It says it all. It's impossible to do. Well, our founders decided to take the challenge. So if you have, for example, a couple that ordered a house, or contractors on site, there's weather or something that creates problems, and then the windows are delivered on site and we can't put the windows in because there has been a problem. And people haven't been able to communicate, and they blame each other. The project takes more time and more money. So we are a tool that's supposed to be used for all parts of the construction process.

[00:06:01] So they want the value of transparency to improve their efficiency. Efficiency is their core. So there are the buyers, there are the contractors and developers that manage the whole building process, and there are the people that make things happen. All these levels have to communicate. And they are all bound by contracts that protect them against a lawsuit that will follow them one day or another. So it is that opacity that we have to harness.

[00:06:38] So that means not only providing a tool that people can use within their current workflow, but it also means changing people and bringing a new agile mindset into their processes. It's tricky. We are doing it. Maybe in 10 years we will see our collapse, but hopefully we are going to do it right. And I believe we will do it right by understanding people.

[00:07:10] So this is how our tool looks like so far. Waterfall. But this is a Gantt chart. This is the tool that's accepted in the construction industry. When you build a house you need to build the floor before you build the walls. That you can't change, so we have to work with it. But this is a live Gantt. You can see I'm actually a bit late in my project of building interviews. I've used my current project in our tool because it's a project management tool, it's nice to use it a little bit. It shouldn't take my experience as the experience because I'm not the right user, but it's nice to show you how the tool looks and how I'm working, which is going to come from our next steps.

Fitting research into a three-and-a-half-designer team

[00:08:00] So you can see that I'm trying to bring back my rainbow here. Where we go, make sure of the contact, make the analysis at the same time, make some ideation workshops, design flows, test them in a parallel way, develop the product. But of course, in a small startup, again, the problem is that in a small startup we don't have a big team. We are three and a half designers. Half time.

[00:08:40] So that holding interviews part, that's possible when you have a full time researcher, which is great, which I've been once and it's amazing. But it might take more time. Therefore the whole waterfall will expand, and that's not working with startups, agile startups.

[00:09:01] But I'm still doing it, because I also try to feed the day-to-day requirements. So I try to feed the sprints. It all happens in two weeks. The developers are developing this new feature that has been required by the customers. It's simple, we understand that it's within our global strategy, our roadmap, we build it. But here I am advocating for the users that I've met last week. And here always is the voice of the advocate of the users. If the executives are also building the roadmap, I can also support this a little bit.

[00:09:42] But in the background, when I have met enough users at the same time, I would implement my manual process. Make a presentation. Show patterns of five users saying the same thing, and say, okay, maybe that's not something they have complained about, but that's their motivation. And suddenly you may be able to make a product that helps, that results in three methods for them, because you have understood where they come from.

A day on site: full immersion

[00:10:14] So that's the first step of exploring all this. It's about spending the effort of one day, full immersion in someone's workplace. Last week I was in the UK, in the province of Manchester, on a dating[?] site. It was very hard for me with the accent, I'll tell you. But I followed that guy around all those days. And I expected to see a site manager in his office telling people what to do, but two minutes after that he took also the hard hat and the vest and the truck. Let's take proof. And I spent the day with him.

[00:10:55] I had in mind what I wanted to figure out for our future, which was resource management. How do they do it? How do they assign tasks to each other? That's a small thing. Yeah, I could have picked up the phone to find out these answers. But the fact that I spent the whole day there made me the advocate of the users in a general way. I'm doing that every second week or something, according to how people are available and how I am available.

[00:11:28] But suddenly I'm coming from the field with videos. I film the whole thing. I film also when they argue together, or what are actually the things they do. They stack fine, nice beams on mud because the project is delayed. This is an issue we face. He would never have told me that on the phone, because it's not too good for the beams. But it's okay, we're going to manage. This is a recurring problem of materials being damaged. And suddenly you have to find them here. This is not what he had in his mind to tell me about what he wanted with my project. But this is what I needed to see.

[00:12:14] And then observing patterns. So it was nice with the beams and saying, look, he had a problem with the wood. But you can also find small things that you might not even notice in one technique. There was another project where people were talking about a map for you to message with the doctor[?], and they were very happy with it. But that person said, I'm not the advisor, I'm not sure. Maybe it was that person, maybe she was not fit for the product. And then you only have three people saying it out of the five people you need.

[00:12:54] No, it's not quantitative data. No, you can't just prove it to your investors and say, see, we have three people saying that. But this is design insight. And this is something you have to consider when such a big pattern emerges. There is an issue about people not feeling comfortable writing. So we can actually consider that from another project as well.

Workshops, flows and prototypes across three locations

[00:13:19] So out of all these insights that I would present in terms of movies and how might we, and all these things you already know, how might we solve the issue that they all face. I got all the different stakeholders of the company into the room. And then, all the people that I used to say, make the flow better: well, we are all designers today. So it's getting all the people that are not designers to start to design, and first of all get engaged. So politically it's a good idea, because then they get on board with the design processes. And then you get all the expertise on the table, all the right expertise that you need to make a viable product.

[00:14:02] That's a developer showing how he made it. Of course, if you make developers design a whole product, then the interface may look data oriented, it might not fit the flow, but his voice was so important to design the right flow. We also design the flow with post-its, our favorite tool, here in the room, sure. But from the post-its, of course, that requires everybody to be in the room and then these post-its get lost. But what we use at GenieBelt is a tool called RealtimeBoard. I don't know if anyone uses it.

[00:14:48] Come back a little bit. GenieBelt is located in three locations. It's in the woods[?] in Poland, it's in London and in Copenhagen. So we had to fly people in for that workshop. But it was crucial that it happened the paper way, that everybody was in the woods[?]. Once the workshop was done, we took all the pictures, and then the workshop continued online. That was amazing. That was, I think, what made me happy to be a designer at this age of time, because we managed to keep collaborating. And it did not move water from there on. The developers were still involved in designing the flows and addressing what needs to be done and how we can do it and helping us prioritize.

[00:15:33] So, moving from flows. These are the people. We are helping real people. We keep them in mind, because there were also some other projects in the room. Steps. Steps they have to do. Blue depths[?] are what needs to be added to our current flow, and the blue depths[?] are organized and prioritized. So great to get the whole company on board with real teams.

[00:15:59] From then on we moved to Figma. And it could be any design tool. But again, about the agile process, it's about designing wireframes and then screens that people can still be part of. So Figma is a great design tool that is also a collaboration tool. So all you do is that there are comments from everybody in the comments. You can do what you want with them, you don't have to write, but you have heard what people have to say.

[00:16:31] And then with Figma you can also test prototypes. So this was with a Figma prototype, that's not this one. But Figma is also great if you have your computer next to you. You have to provide a task in that way, so you complete that task and if people fail or complete it, then you validate or refuse the prototype. So the tools would be that live screen mirroring, plus two cameras that would also show both the face and the hands. So you can also communicate about why we have to spend two more weeks on the prototype, why is it not done and I'm just like, oh, we're still working.

[00:17:27] And then we develop it. And then we also use another tool again. We just implemented Canny. Canny.io, that allows people to request features. Some tools have that, and we're just trying it. So we are using the commercial team to tell us about what people are complaining about, but we're also trying that directly into the project. So this is one of the things we're trying, I still don't know. We are trying that qualitative research in the process. I'm convinced. Maybe I'm too convinced, maybe I should give up some of these fights, but we're trying as we go. And it's very nice to hear from you guys also. So that's our rainbow process. Thank you.