 Ymlaen i'r graflwnydd yma, a dyna'r swyddfa i'w gwnaeth mwneud trwy'ch yn tyniol hwnnw i'w'r dd deedol i'w gwirionedd. Ond oes oedd am gyd yn ffynnus oherwydd rwy'n gwybod. Fynd i hefyd, dyna dwi'n gwneud. Dwi'n gwneud a'n gwneud gyda rhan oherwydd. Mae'r ddedech chi'n meddwl i'r ddau math o'r enghven yw'r fwylo'n gweithio ar gwerthu. Well, I guess I've come from the tradition of user-centred, people-centred, human-centred design. Human-computer interaction is kind of up in my field, and I am halfway through between interaction design and the social sciences. So I'm a bit of a weirdo. So I guess the first thing I need to do is to clarify what I mean by design and what I mean by researching this talk that is titled, No design without research. And what I mean by design is mostly, for the purpose of this talk, is mostly interaction design. And interaction design deals with the behaviour of any interactive thing in the world of software. It deals mostly with the structure and behaviour of software interfaces, which means that when you make decisions about which features your software should have, or how those features should behave, you are doing interaction design. And understood in this way, interaction design applies to all software and to all kinds of interfaces, and not just the graphical ones. And what I mean by research in this talk is any kind of activity that ends up involving users in the process of making software. So, basically, it's about getting your users to be part, to take part in the interaction design process. And the question that I keep on encountering, and I keep on having all these conversations about, is can interaction design exist without doing research, without involving users in the process of making the software? I'm doing a PhD at the moment, and when I hand out in the university, I am surrounded by a lot of people who believe that you should not be doing design without doing research. But then I also spend some time with the free software and the open source software communities, and in those places I run, I encounter people who are somehow wary, nervous, and sometimes quite hostile to the idea of human research with users. And those people I've come to call in a kind of joking way, the naysayers. And based on their arguments against research, I've come to classify them into four groups. You have the itchessclatchers, we have the scornful, we have the dismissive, and you have the defeatist. So I want to go through them one by one if you allow me. So let's start with the itchessclatchers. Now these are people who believe that they're building software that is exclusively tackling a problem that is their own, solely their own. And their argument goes, well, since this is my problem and only my problem, the only people I need to do research with is myself. Other people can use the software, but in the understanding that the software is about solving my own problem and it might not be ideal for their problem. I kind of understand this argument, but I think it's somehow detached from reality. Because this is the thing. Your itch is only your itch as long as you are the only person using the software. The moment one more person starts using your software, your itch becomes only 50% yours. And it's also 50% that each of the other person is using the software. When a second user comes along, your itch is now 33% yours. When a third user comes along, the itch is 25% yours. Did you see where I'm going with this? By the time you reach 50 users, your itch is 2% yours. So sure, these people can keep on telling themselves, well, this is my itch, but that doesn't change the fact that it really is not anymore. And the thing is that the only way of keeping your itch your own is keeping the source code to yourself. But the moment you release the source code, the source code to the world for anybody to use, you need to come to terms with the fact that you have also released your itch. So that's the itch to Scratchers. The second guy is the Scornful. And this is a type of people that we call you Henry Ford. According to these people, human beings really are very good at articulating what they need and what they want. And the designers are better positioned to do so than themselves. These people seem to believe the designers have some kind of superpower. The designers are somehow a more evolved type of human being that has overcome this incredibly human limitation of articulating what it is that we want and that we need. Obviously, I'm sure I need to convince you that these people who believe the designers are in any way superior are kidding themselves. The only superpower designers have is the recognition that we human beings are really by articulating our wants and needs. And that there are some things in the design process that can help us overcome those limitations through all sort of work, things like iterative prototyping and also design research. The third type are the business if. And basically these people say that every time you ask other people anything, any opinions related to design, every single person will tell you a different thing. And then the designer is left to fix the mess, to try to, you know, make sense of all these conflicting requirements that are probably unreconsilable and that relate to either design paralysis or God says us all, designed by comedy. These people research is about asking people what they think about stuff. That design research to us is about asking people about their opinion. But actually this is not what design research is at all. Design research is a highly structured activity that is carefully set up in order to answer certain questions. What we call research questions is stuff we want to know more about. Okay, so it's nothing about people's opinions. And what it is about most of the times of certain human behavior. So there is a lot of research that may involve asking people questions, but those questions are normally not directly related to the stuff you're designing. They are about the problems you're trying to solve with your designs. The circumstances and the context in which those problems take place. And also the ways people go about trying to fix the problem themselves, which are very often highly imaginative and quite quirky. But a whole chunk of design research that's not involved asking questions at all, it involves observing, observing how people think about their business, observing as well of course how they use our software. So design research is not really, sorry, anyone who starts observing human beings in this way will realize that we are all slightly different. We go about our business in slightly different ways. But there are also striking commonalities across the differences. You know, these common patterns, these similarities. And it's those similarities that ask designers who should be looking for, because they're normally very useful to the work we need to do. So design research is not about making sense of people's opinions. It's about uncovering the common patterns that underpin our very individual human behavior. And finally we have to be fittest. And this is the people who think that design research is a research that just takes too much out of you. You know, it takes too much time, too much money, too much effort. And because of that, it is not suitable to free software projects. I think I imagine that when these people, the fittest here in the world research, these images come into their catch of really expensive labs with one-way mirrors and fancy cameras. And these very long longitudinal studies or these years-long endographic endeavors that end up becoming like 10,000-word research peer-review papers. And this is the standard academic study. And they do it because they develop theory. But we are not developing theory. We're just trying to make some software. And in order to make software, our research can be a little bit different. So this is the reality of research for the purpose of software making. Let's talk about time first. How long does it take to do this type of research? Well, apparently if you want to do anything that involves talking to people inspired by interview approaches, six interviews is enough. If you're doing anything that involves getting your users to interact with any artifact, five sessions is enough. These sessions should never be longer than 45 minutes, which means that you can run an interview study in four and a half hours and a usability type of study in three hours and 45 minutes. I don't know about you, but I don't think this is that long a time. What about the money? There are certain costs that are often involved in doing this type of research. For example, you might have to travel to meet your participants, or your participants might have to come to you when you need to cover the costs of travelling. But luckily, a tone of research nowadays can be done remotely with things like gypsy for zero euro. Another cost that is involved in doing research very often is that you need to capture it somehow so you might need audio recording equipment or video recording equipment and stuff like that. Nowadays, capturing research can be done for zero euro with stuff like OBS. Finally, the last extent that you often have with research is compensating your participants. When we do research with people, it's a common practice to give them a little bit of money as a thank you, but money is not the only way of compensating people taking part on research. It's communities of users that are very committed and very engaged and very often they will be willing to help you without any money involved. We have to start looking at research, at taking part in research as a form of contributing to free and open source software. And there's also other ways of compensating your participants As part of WEPHD, I recruit a lot of people to take part in my research through an organisation called the University of the Third Age and in exchange for that help, they don't want any money. What they want is training on the stuff you're interested in. So far, we've given them training on Facebook's privacy settings on GDPR and also web third party tracking. So talk to your users, talk to your research participants and find out how they want to be compensated for their help. So here, it turns out that research can be done actually for zero euro. And I actually do this all the time. And finally, how much effort does it take? A big chunk of the effort that is required in this type of research is making sense of the results, making sense of what the research is trying to tell you. And this process is coming on very effectively in teams, in activities like this, what we call an affinity diagram. And that makes it way more fun and also much faster. But because our studies tend to be quite small, it's also very likely that you can make sense of the results by yourself in a couple of hours. And that's how it took me, how long it took me to make sense of this particular study that we did recently when we did a piece of video software, the processing software. And then the other thing that takes a lot of time, sometimes research is communicating the results. But to do this, you don't need to write these very long research reports that nobody reads in the end. The research output can be communicated very easily and very quickly in video calls, creating videos or podcasts or just writing in the mailing list or wiki page like we did in this case. So it doesn't need to take that much effort either. And finally, just a couple of common sense recommendations where you want to do research for your free software project. Keep these studies small. If it looks like your research question cannot be answered with a study that looks like the ones I've just described, break it down. Break it down into simpler, smaller questions and run many smaller studies instead of a single huge one. In any case, you're going to learn way more from those several mini-studies down from the massive one. So just keep it small. Do research periodically. And instead just small. Maybe maybe you do one user interview a month. That's it. That's your target. And for a long time that was my goal. And that was fine because you see a free open source software project. We're not in a hurry. You can be your knowledge about the user base as you go along as you go on more and more of these interviews. So you can take your time with your research. That is fine. And finally, what I think we all should remember is that research is not really about activities. Research is an attitude. It's an attitude that you bring in every single encounter with your user or your prospective user base. An attitude that is about genuine interest, active listening and keen observations that come out of that attitude. And you can do, you can bring these attitudes with you and everywhere you go. So for me, this type of approach that is inspired by ethnography meant, for example, that when I was designing tools for software engineers, I started to use IOC. I learned it. I learned how to submit patches to the project I was contributing to. I used text editors, played with electronics, learned how to solder. And most importantly, every single day, I sat down with engineers in my office to have lunch with them. So this type of research doesn't cost any money, and it can be genuinely a lot of fun. So don't let the ages cratchers, the dismissers, the scornful, at the fittest to stop you from doing research for your project. Put on your upsetting hat and get out there to watch the perks of your user base. Because you see, I think we can't design just software without doing research. But if we want to do good software, the type of software that makes sense to the people who use it, we just cannot do it without messing around with the research bits. Thank you very much everybody.