Finding your users’ needs
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 611 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/42017 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2017 |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Archaeological field surveyRight angleCASE <Informatik>DatabaseSingle-precision floating-point formatRange (statistics)Product (business)Musical ensembleQuicksortLevel (video gaming)Field (computer science)Semantics (computer science)Data conversionInformationSystem administratorGroup actionArithmetic meanProjective planeCuboidWordAuthorizationFunctional (mathematics)Surjective functionPoint (geometry)
05:02
Electronic program guideExpert systemHypermediaFile formatInterpreter (computing)Tablet computerShared memoryLevel (video gaming)AbstractionComputer programInformationRule of inferenceProjective planeDisk read-and-write headText editorArithmetic meanDifferent (Kate Ryan album)Electronic mailing listDependent and independent variablesData structureData managementFeedbackProcess (computing)Digital photographyReal numberBitGroup actionSpacetimeQuicksortVideo gameGene clusterMedical imagingComputer fileOnline chatMereologyRepository (publishing)Similarity (geometry)Functional (mathematics)Multiplication signProfil (magazine)Field (computer science)VideoconferencingCASE <Informatik>Right angleEmailSoftware developerSet (mathematics)WikiDatabaseOpen setControl flowSinc functionOffice suiteTouchscreen
14:17
Open sourceFrame problemGoodness of fitDifferent (Kate Ryan album)EmailProcess (computing)InformationInternetworkingOnline helpFacebookPatch (Unix)TwitterPhysical lawCodeSoftware developer1 (number)Product (business)Personal identification numberElectronic mailing listData managementVisualization (computer graphics)Multiplication signSoftwareInformation securityMappingComputer programMusical ensembleFunctional (mathematics)FeedbackProjective planeKey (cryptography)Link (knot theory)Shared memoryLatent heatUsabilityMathematical analysis.NET FrameworkSoftware testingTouchscreenPrototypeData structureWikiStaff (military)Random matrixRight angleDataflowOnline chat
23:31
Computer animation
Transcript: English(auto-generated)
00:00
Shall we give it a start? OK. 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
00:23
at Wikimedia Deutschland onto products, which is Wikidata. And Wikidata is a semantic knowledge database, setting stuff like the things you see right hand side in these info boxes on Wikipedia, like how many people live in Berlin, and so on, and much more awesome stuff, which you can
00:42
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 simulated as very important. And luckily, that's the topic of our talk.
01:03
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 pretty good, but when does that come to be important?
01:23
And naturally, I would say it's always important, but I think in two cases, it's most obvious in the course of a product, which is when you want to enter into a new field, which is the ideal thing, you would first do the research and then create a product.
01:41
And actually, in the most cases, there is already a product idea. And then with that idea, you start the research and then guide the course of the product and its features and add new ideas fed by the user research.
02:03
And by that, it also helps the creativity in finding what the product should do. And an obvious question now would be, why don't you ask just what users want? But that's a very tricky thing. Here, an old and overused quote on that, if I had asked
02:21
people what they wanted, they would have said faster horses, attributed to Henry Ford, who never said that. But it neatly demonstrates that just asking, OK, 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
02:41
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 your users, of their activities, motivations, problems, is very important to build a coherent product that is not just a collection of
03:00
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 a team?
03:22
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
03:41
research about the hows and whys 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
04:00
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 a single word answer, like no.
04:21
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 style. That would be like, please describe how you started your work today. And that demands a story-like answer in which you get
04:42
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
05:00
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.
05:21
It's any way 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.
05:42
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 Commons users.
06:05
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
06:24
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
06:41
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, asked if people would be interested, and also made transparent what we
07:02
hope users can gain from that research. But there are 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.
07:22
All right. 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
07:41
finer nuances in their responses. And I did this for one of my research projects where we have, in our office, we have a biweekly community meetup of the German Wikipedia community, editors mostly, only actually. So I go there regularly and talk to them, even if I don't
08:01
have specific questions, just to find out what the current problem is because they chat about, oh, this went 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 you're a user, another thing
08:25
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
08:43
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.
09:01
Yes, so 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
09:23
depending or 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.
09:41
So this already kind of restricts your user group that is that you can talk to. But yeah, but we do ask them to share their screen if they're willing and guide us through a workflow. And we try to ask those open questions that Jan mentioned before and find out their motivations and how they work.
10:04
OK, so what you now have after having conducted five to 10 interviews would be typical. You have like a lot of data. Usually we write that down in notes we made during
10:20
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
10:41
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 you use a set.
11:02
And I often compare that to building a Lego house. So like you would have like 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.
11:21
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?
11:44
And typically, and also like the form we now show since it's like most visually, it's clustering notes on a big wall. So like on every of these sticky notes there would be like one assertion a user made
12:00
like a little clipping and you end up with like, I don't know, 100, 200 notes 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.
12:23
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
12:42
or if I edit, 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
13:01
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
13:22
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
13:42
will be introduced by Charlie now. Right, so you've got your structured data now and you want to communicate it to your colleagues or colleagues or community members
14:00
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
14:20
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
14:46
or any of the personas and one tool we use is story mapping. So this is a workflow visualization where every specific step is, sorry,
15:03
yes, is lined out and for every specific step you can have very specific notes which are the pink 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, yeah, the workflow.
15:26
The other thing that's really helpful is paper prototyping. So this is really, 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,
15:41
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 yeah, envision how it could look later. So there are some challenges where we still want to improve our research
16:01
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
16:21
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.
16:41
Also, we try to go into the realm of like finding different design tools that for example is a dryo, which is basically like an other pet for diagramming and wire framing that we want to use more in the future because there we can easily collaborate with other internet users.
17:01
And I just wanna add to that, that we did that because I'm putting everything out in open source as like as a creative comments lessons, you've been using open source tools is helpful, but that's always like post process that like the community can then after the fact, edit and use it, but we are trying to more collaboratively work with them.
17:20
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
17:41
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 were actually talking with a lawyer right now
18:02
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, you know the thing. Another thing is we want our stuff to work for everyone.
18:22
And right now getting like 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 a thing we can do is what the English Wikipedia did
18:42
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. Was that it? Yeah. Here's some useful links if you're interested in more research methods.
19:00
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 opensourcedesign.net. And please give us feedback. And also we're hiring. So check that link. And yeah, if you wanna talk to us, we're here
19:21
and the key data product manager is here as well, as well as community manager. That's it, sorry, you had to rush the last minutes. Do we talk too fast?
19:55
Right, an open question over a mailing list.
20:00
Just to ask and collect information from one of them. We've done this on Vicky. 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? Have you generally, yeah, what do you wanna,
20:21
because we knew we were gonna 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
20:42
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. Me, it's helpful.
21:01
I would be always afraid of the huge amount of people that could answer those questions. Yes. Go through them. But we want a huge amount of, I'm sorry. Yeah? Yeah, there. Oh, sorry. You wanna say something else? I don't know, it's like, no, it's fine. Okay, yeah. What legal issues do you have
21:21
like collecting data from the users? Can you collect this data and only mostly, I mean, there's no personal data more or less that you're collecting like the user needs or the user like flows or user stuff. Why is it really an issue when collecting this data? Because it's like, if they share their screen, for example, that's something and we do anonymize them
21:43
so when we talk to them, we don't use their name or something or maybe even not even their username because, you know, and what other issues are there? I don't know. Because we need it to be legally sound
22:00
like they need to, right now, we're just doing it kind, 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 has a person.
22:22
Okay, yeah, verbal. Yeah, yes? Do you share with, well, that. Maybe all the Wikipedia countries are doing the same. Wikidata is developed mainly in Germany and that's where our research goes. If we do research that concerns Wikipedia,
22:44
we share that with our colleagues and are in close contact with them to discuss that research and our methods. They are very likely not doing that because they have no software staff and then certainly nobody who does specific
23:02
user research on software. The most sharing occurs with the Wikimedia 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. So the foundation knows. Yes, of course.
23:22
Yep. Thank you so much. You can always catch them if you have any questions for them, that's all good. Thank you.