We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Finding your users’ needs

00:00

Formal Metadata

Title
Finding your users’ needs
Subtitle
Researching motivations, activities and problems of your users
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
Publisher
Release Date
Language
Production Year2017

Content Metadata

Subject Area
Genre
Abstract
UX Design is often understood as creating an interface and testing if it isusable. But it can also include finding out what would be useful and servesusers’ needs. Methods to analyze user needs exits, however, they may assume a lot ofresources or don’t consider community driven work. We want to demonstrate methods we used for Wikidata and Mediawiki to *research user needs * use the findings to improve our software We want to particularly highlight * How to do this with few resources * How to involve an open source community * How to involve team members who are not designers
17
Thumbnail
24:59
109
Thumbnail
48:51
117
Thumbnail
18:37
128
146
Thumbnail
22:32
162
Thumbnail
23:18
163
Thumbnail
25:09
164
Thumbnail
25:09
166
Thumbnail
24:48
171
177
181
Thumbnail
26:28
184
Thumbnail
30:09
191
Thumbnail
25:08
232
Thumbnail
39:45
287
292
Thumbnail
25:14
302
Thumbnail
26:55
304
Thumbnail
46:54
305
314
317
321
Thumbnail
18:50
330
Thumbnail
21:06
333
Thumbnail
22:18
336
Thumbnail
24:31
339
Thumbnail
49:21
340
Thumbnail
28:02
348
Thumbnail
41:47
354
Thumbnail
26:01
362
Thumbnail
18:56
371
Thumbnail
13:12
384
385
Thumbnail
25:08
386
Thumbnail
30:08
394
Thumbnail
15:09
395
411
Thumbnail
15:10
420
459
473
Thumbnail
13:48
483
501
Thumbnail
32:59
502
Thumbnail
14:48
511
518
575
Thumbnail
25:39
590
Thumbnail
25:00
592
Thumbnail
23:32
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)
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
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
Computer animation
Transcript: English(auto-generated)
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
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
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.
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?
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.
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.
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
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
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
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?
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 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
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.
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
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 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.
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.
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, asked if people would be interested, and also made transparent what we
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.
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
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
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
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.
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
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.
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.
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
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 you use a set.
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.
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 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
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.
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 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
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. 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 a workflow visualization where every specific step is, sorry,
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.
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,
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
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 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.
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.
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 were 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, you know the thing. Another thing is we want our stuff to work for everyone.
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
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.
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
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?
Right, an open question over a mailing list.
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,
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
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.
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
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
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
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.
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,
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
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.
Yep. Thank you so much. You can always catch them if you have any questions for them, that's all good. Thank you.