 Shall we give it a start? Okay. Awesome. So, hello. We are Jan and... Charlie. And we're going to talk about finding user needs. We both work together as UX designers and UX researchers at Wikimedia Deutschland on two products, which is Wikidata. And Wikidata is a semantic knowledge database, saving stuff like the things you see right hand side in this info boxes on Wikipedia, like how many people live in Berlin and so on. And much more awesome stuff, which you can do with that. And also German Wikipedia, where we mainly improve functions catered to heavy users like authors, administrators and so on. Yeah, as we saw in the panel discussion, user needs was similarly rated as very important. And luckily, that's the topic of our talk. And let's right dive into it. So the first big question in that regard is why do we need to know user needs? I mean, it sounds like pretty good, but when does that come to be important? And naturally, I would say it's always important, but I think in two cases, it's sort of most obvious in the course of a product, which is like when you want to enter into a new field, which is sort of the ideal thing you would first do the research and then create a product. And actually, like in the most cases, there is already a product idea. And then with that idea, or slightly after you start the research and then guide the course of the product and its features and add new ideas fed by the user research. And by that, it also helps the creativity in finding what the product should do. And an obvious question now would be like, why don't you ask just what users want? But that's like a very tricky thing. Here, like an old and overused quote on that, if I had asked people what they wanted, they would have asked the horses, attributed to Henry Ford, who never said that. But it neatly demonstrates that just asking, okay, what shall we build, please tell us, may not be the ideal way. And if you want to tackle it on a more abstract, less figurative level, knowing wishes of people and what they imagine to be good for them is not the same as understanding. And having an understanding of users, of their activities, motivations, problems is very important to build a coherent product that is not just a collection of features but a thing that fits together. So we want to understand the how and why of the user's work. And that is a very important point. And during the course of the talk, it will be about how can we do that and how can we do that together with the team. As I said, we want to know about the meaning of things, about actions of users and go beyond single issues and make them fit together to a product that helps the user. And naturally, you don't know when you start with the research about the house and why it's yet, so it is a very important principle in user research to allow for discovery. What does that mean? It means that you want to discover new things you don't expect yet to be the case. One important principle that we often use in our research methods is asking open questions. So typically what often pops up, let's do a survey, let's just ask single questions but those are often so-called closed questions that allow only a small range of answers. Like do you do this or that or would you like that and then you get like a single word answer, like no. But what we actually want to get to know new things that we don't know about yet and be surprised, we strive to ask open questions in a sort of conversation and observing the user's style. That would be like please describe how you started your work today and that demands a story-like answer in which you get potentially many new informations and the users can talk like paragraphs over paragraphs if transcribed about how they started their day. So how does that look in an actual project if we do that? Well, to get to know about users, you need first the data like for example what people answer to these questions. And there are several ways to do that and we show you some methods and examples of it. And usually we kick off our user research with preparing and collecting the knowledge that already is in the team. It's anyway impossible to start with a totally blank slate so it is good to collect some knowledge and assumptions of the team first. And what we do in that case, for example, is creating a mind map together with our colleagues, together with some expert users, for example. And for example, here on the right-hand side, we collected a still incomplete but huge map of things you can do in our image database Wikimedia Commons like uploading images, commenting on images and so on. And we tried to see in which problem space we are moving in researching the needs of comments users. And based on that we can create a guide on where we have information needs where we want to know more about the workflows and so on. And when you collect the information you already have that was in the heads of your developers of like expert users you may have access to, you would create a research guide where you write that down what you want to ask and you would then go as it's called in the field to your users and gather that data. And the typical method which we apply most is like talking to users and observing them, having demonstrations of their work. But before we can do that naturally we would need to find the users. Currently we do mostly research with expert users that are part of our communities. So we recruited a lot via mailing lists as if people would be interested and also may transparent what we hope users can gain from that research. But there are like several other methods you can get participants in that research. And then we hopefully gather interesting insights and data and Charlie will introduce you to some examples where we did that in projects. Alrighty. So one thing we try to do is to meet the users in real life and not remote, which is not always possible and you obviously don't always want that as well if your community is maybe very international. But if you talk to them in person then you can see finer nuances and their responses. And I did this for one of my research projects where in our office we have a bi-weekly community meet-up of the German Wikipedia community, editors mostly, only actually. So I go there regularly and talk to them even if I don't have specific questions just to find out what the current problem is because they chat about are this one wrong and blah blah blah. But if I have specific questions I can always ask them about it and even conduct a little research. And yeah, like I said, if your user... Oh no, right, sorry. Another thing that we once tried is to gather insights on a topic with a specific scope was to do this in an open online format. So since Wikipedia is a wiki, people are comfortable with the format of a wiki and after we conducted a research we posted our scenarios that we came up with there and asked the community to comment on those scenarios and contribute to them. So kind of as a feedback loop to see if they can identify with them and if they represent the issue at hand well. And then what Jan already mentioned, remote research is very useful if you have a large international community that Wikimedia Commons does for example which is this media repository where you can upload all your Creative Commons media files to share with the world. And there we usually do like a Google Hangout or Skype depending on whatever the user is most comfortable with that's usually the easiest way to go. And also the thing is this can be restrictive though since the user needs to be comfortable enough with the computer and with this video chatting so this already kind of restricts your user group that you can talk to. But yeah, but we do ask them to share their screen if they're willing and guide us through workflow and we try to ask those open questions that Jan mentioned before and find out their motivations and how they work. Okay, so what you now have after having conducted five to ten interviews would be typical. You have like a lot of data usually we write that down in notes we made during the interviews or even transcripts of the audio. And having the data in that form doesn't mean that you can use it well because it's basically like a long long text structured by sort of the time, the linear timeline you went through there. And to have it in a better accessible form for use by designers, by management you need to make sense of that data and structure it in an accessible way. This is partly based on interpretation so it is empirical since it uses like that gained data but it's also subjective because there are different ways to interpret something a user said. And I often compare that to building a Lego house. So you would have some material you start with and then you put it into a coherent form. There's also a bit of creativity in that and there are also like many different ways for example to build a house but it's like not an arbitrary process. Just taking that bunch of Lego bricks and throwing it somewhere else doesn't make it a house, doesn't make it a coherent structure. And also there are like certain rules on that kind of interpretation and so on. Question is like a nice abstract metaphor and nice Lego bricks, how does that look like when we do that? And typically and also like the form we know shows since it's like most visually it's clustering nodes on a big wall. So like on every of these sticky nodes there would be like one assertion a user made like a little clipping and you end up with like I don't know 100-200 nodes of these often and then you start to put them up and you put up more and more and like then you see some share similarities and you already like maybe have some headlines for them and then over the time you also improve the headlines. Usually you start with some labels like maybe images or upload or something like that and later on you may come up with a more with a title that's more closer to a design principle or to a problem like uploading images is difficult or if I added I do edit a bunch of images instead of one or something like that and so like over the course of the research you would like make the clusters more clear, redo them, redo them again and so on like you would do if you built with Lego and then at the end maybe like find out some sort of general themes that you hold as very important and that's what that looks like then and sort of as a photo on the wall. So that will result in a list of themes like general principles, stuff that repeats for the user in a way that has like an important meaning for you or them but like still it isn't like it's a form that's very well accessible for you as a researcher but maybe not for management or programmers and so on so you will bring that into different formats that you can use well in design and some of these formats and examples for them will be introduced by Charlie now. This is good. Right so you've got your structured data now and you want to communicate it to your colleagues or colleagues or community members and one thing you can do is you can use personas so those are profiles of functional users and they have a role, they have a name, they have specific problems, they're in a specific place in their life, they have specific activities and this helps when developing to relate the things you're doing to someone so you're not doing it for some generic person but you try to envision like I'm programming this for Melissa because she needs this exact function and yeah so this is usually a very helpful tool and we want to find out how exactly Melissa works or any of the personas and one tool we use is story mapping so this is workflow visualization where every specific step is lined out and for every specific step you can have very specific notes which are the ping post as you see as well as motivations and also putting it out like this can help the developers and anyone come and comment and get a better feel for the workflow the other thing that's really helpful is paper prototyping so you can do this really well with people that are also not very experienced because it's very interactive you can change things really easily you don't get too attached to the actual mock-up that you're making and you can even click through it like replace papers and envision how it could look later so there are some challenges where we still want to improve our research and I will give you a very brief introduction on what would be future topics for the next year one of them is increasing contribution culture so as we talked about a lot already like open source software development is often very focused with all its tools and workflows on coding and we would like to have the possibilities that you as a developer can do like submit a patch, something like that also for our community and to design with them instead of just for them also we try to go into the realm of finding different design tools that for example is dry-o which is basically like an other pad for diagramming and wireframing that we want to use more in the future because there we can easily collaborate with other internet users and I just want to add to that that we did that because putting everything out in open source or like as a creative comment license using open source tools is helpful but that's always like post-process like the community can then after the fact edit and use it but we are trying to more collaboratively work with them so what we also do is maybe do workshops with them where we not teach them stuff but we develop prototypes with the community actively another thing is right now we're having like when we recruit users we do this individually so we ask every single one of them if they would like to help us which works maybe if we don't need so many for a big quantitative analysis but sorry, qualitative, there we go but if we need doing shorter usability tests we need more people and we don't have a participant pool right now and we're trying to build this but there are many legal issues and so we're actually talking with a lawyer right now to set up a paperwork that is like legally sound and when we're done we're hoping to publish it so anyone with an open source project can use this to then have a sound base for a participant pool because of like data security issues, you know the thing another thing is we want our stuff to work for everyone and right now finding users is only easy with expert users because those are the ones already on mailing lists and IRC and on wiki but how do we get the ones that are like passive like readers of Wikipedia, it's hard to get to them so the thing we can do is what the English Wikipedia does is have banners for non logged in users but we're also thinking about just contacting people on Facebook or Twitter so where people that like the product but maybe don't contribute can see it here are some useful links if you're interested in more research methods and those are all under creative commons as well and right so that's our email and Twitter handle and you can find more open source design things on open source design.net and please give us feedback and also a hiring so check that link and yeah if you want to talk to us we're here and the key data product managers here as well as well as community manager that's it sorry you had to rush the last minutes do we talk too fast? another question of a mailing list just to ask and collect information we've done this on wiki so we have this thing called project chat and so we opened an issue like a thing and just asked what do you think about this issue what are your problems do you generally yeah what do you want to because we knew we were going to work on it but we didn't exactly know where to start and this was actually quite helpful so it was a very open question and you can get a lot of stuff that maybe is not useful but it was a really good start like pre-research thing to gather some first information usually it helps to provide some structure with it like the scenarios we gave to give people some form how they can answer them but there we already had like scenarios already was after the research but we do have like questions that they can then answer not just like tell us anything it's helpful I would be always afraid of the huge amount of people that could answer those questions but we want a huge amount of people I'm sorry yeah oh sorry do you want to say something else no it's fine okay yeah because it's like if they share their screen for example that's something and we do anonymize them so when we talk to them we don't use their name or something or maybe not even their user name because you know and what are the issues are there I don't know because we needed to be legally sound like they need to right now we're just doing it kind of we're just kind of talking to them but when we have like a participant pool we need them to sign that it's okay that we talk to them and that we can use the data in an aggregated way and so forth it's just that people need to consent if you use their data right now we're doing it like each person yeah yes well that Vicky data is developed mainly in Germany and that's where our research goes if we do research that concerns Wikipedia we share that with our colleagues and are in close contact with them to discuss that research and our methods they're very likely not doing that because they have no software stuff and then certainly nobody who does specific user research on software the most sharing occurs with the Vicky Media Foundation who they are like the biggest chapter and we are in an open discussion with them all the time so we do share a lot yes of course thank you so much you can always catch them if you have any questions for them