 Okay, so hi. Thank you for coming. My name is Dekaterina Moraru and I'm an interaction designer for Xwiki. I'm going to talk about open source design feedback and it's going to be a panel mostly and these are my colleagues from the open source design community. I wanted to be a very interactive session but because we have only 25 minutes and 25 minutes and topics very very broad I will encourage also the audience to participate. So if you want to participate to the questions that are being asked because I don't know maybe we will not have time to ask everybody you can use the QR codes and the surveys there and we can see also what do you think about the topics. And the first question are who do you represent so that would be an easy question for you like if you are designers or developers or other things and I will also start when you introduce yourself and I will ask the panel members to say their names and the community they're representing. So Bernard. So hello I'm Bernard the guy from just before. I'm part of the open source design community. I'm a user researcher and interaction designer and I'm trying to sort of get more involved in more open source projects. That's me. I'm Jan and you probably already know that I'm from the previous talk that I am at MixCloud and I'm mainly interaction designer and yeah I'm also active in open source design and a few other open source projects. Hi I'm Elio I'm a visual designer. Yeah let's go a bit closer. I'm a visual designer mostly doing stuff for Mozilla and tour project and I'm representing URA where we help many other open source projects with design. Hi everyone my name is Victoria I'm an engineer with interest in usability. I represent first open source design and I try to work on Valentina project. Participate us to the survey. Okay so we have five designers and five developers that's great. This means that it's very equilibrated that's all. So the first questions that I will ask the panel it's what do they think that understanding designer motivations improves the feedback and what I mean by that. The audience we need to discuss and to say what do they think motivates a designer to participate in the open source and some example of options are money, fame or sharing experience or not. And for you guys do you think it's important when you provide design feedback to understand why the designer it's contributing or you want to keep it professional it doesn't matter. So do you think that if you know that a designer wants money in open source you should treat it different or if you know that it's his I don't know doing this pro bono you should maybe be more polite to him or is it changed the approach for communities when. So I think that design contribution and no difference from any other contribution to open source and it's very important to play by the rules of the community. So if you are wanted to be a part of contribute of the open source project you need to explain how you came to this decision and it's a difficult topic usually. So in UX design especially the most important process is explain the journey why you make these decisions and then you have a chance to succeed and make your contribution accepted. I wanted to add something about that as well. So when an open source project is born there isn't probably there is a need for something new and the founders of the project understand the importance very very clearly. So one of the problems which comes up when a designer comes into the game is that the communication of the importance of the mission of the whole thing why the people are doing this is not translated well to the designer. So this is why there might be a lot of technical contributors because they understand the need for the project while designers might lack that understanding. And I think there's a gap between the communication between the technical leads of the project and designers because it's like it's like telling you why I love that particular kind of coffee. It's like no one will understand that unless you explain them because the coffee beans are roasted in that way and because it's fair trade blah blah blah. If you talk in that process like you can you can ah that's why you like that so much. Okay I understand why this is so important to you and if you are doing especially if you are doing this pro bono this is something a designer needs I think. There's something the audience said that designers are motivated to gain experience and to share experience and are not really motivated by money and fame. What do you think about this? Yeah I mean I would agree so I also wanted to say something like touching on what Victoria said I think it's like because design or we shouldn't treat design as art of course because it's quantifiable and it's basically any designer whatever they do like if they do it full time or if they do it pro bono or if they're just a volunteer they're just kind of a voice for for the user basically or for whoever is using it in the end so usability is quantifiable so it doesn't really matter in what capacity you contribute to the project so it's like you're just a channel for better usability for making better design happen so yeah that shouldn't be part of like who you are or why you contribute to the project. Question for audience who is the target in open source project and the options are the owners the designers the users and world and this is an interesting question so the panel should ask how understanding the panel improves the feedback the community gives. One example I could give is that when a committer looks at the design thing he doesn't think about his users he's just providing subjective feedback so who is the target in open source and how is that important and how does that influence. I think the first question who's who's the target the target I mean a target audience of your project of your open source project and how understanding that helps you provide better feedback. I think it's probably the world I mean and the world contains the users and everybody else. What do you think about designers that consider themselves to be experts in a certain domain should the designer be the one that provides the most important feedback. No it should also be the user well it should be the users ultimately and the designer is the voice of the user. The contributors who like code are also possibly the users possibly so you have to take into account everybody's feedback. I mean I just think it's important that it's we don't see like or we don't say the target audience is everyone because then we don't have particular focus right so we have to we have to first focus on like a specific group and then maybe maybe maybe specifically cut that up into into different groups of target audiences so yeah I definitely don't think it's the world because like I don't know not like only half of the world is using the internet or something so for example that right so it's definitely not the world and yeah. I don't know about the 14 said the users. The options are a bit blurry. For example when you say the world you have to say that when you do a design feedback or a proposal you can put it on Twitter for everybody to see it and that could be considered the world. Either you just show them to your community. I'm not sure if it's on on topic that I just wanted to add it's easy to say for whom we build software for users but it's very difficult to follow this and we sometimes assume oh I'm the user I know everything so if you build a project just go out and see people use your product that's the only one way we can learn. So the users whoever you see using your project and then you learn and improve. So very hard to make it very specific because if it's the world you are not surely who you're targeted are they advanced users are their normal users are they from most specific geographic region and this might be or not important when when you propose something. We have is who makes the final decision. And this is one of the important things and this should be clarified from the start. So options for the audience are all designers users in the world so they're the same options from from before. So I have some personal experience with that. I guess I think I mentioned that before. So when someone asked you for for contribution. It's hard to understand who makes a final decision. And doing that in the beginning right in front can avoid a lot of misunderstandings in the in the later because sometimes people want to work in the open doing request an open source design. But they want to have the final decision. So if you're an open source project you are the founder of the project you want to create it. You want to have the process in the open. But you want to have the final decision in the end. So OK I can understand that. But that would be great if you can say that sometimes you want the community to have the decision. So this creates this can avoid quite a lot of conflicts if it's in the brief if because open source design is quite niche yet. It's nice to have a clear communication and. But designers are not committers. So I believe that community have to decide always and community will balance itself and please please give your opinion. So I think it's those who make the software. And those are committers and designers all together and they have they as a community make decisions. We cannot separate it. Thanks. I think like in many cases it will ideally become a discussion between all of these groups. I suppose that like only one of them only one person is responsible would be sort of very classic management. And I hope that in our projects we can have a discussion together and make sense of it together. Not a combination of everybody. Sorry. On the other hand I think that designed by committees some is a way for things to go certainly wrong. So there is I think that there is one reason that you might decide that OK after all the discussion if you haven't reached some kind of consensus. Somebody has to make a final decision hard decision. And in my opinion that should be the designer. And since you said that I would expect if there was a design made there was some research or some testing done with users and I would look for the data. And if there was no data then it's more difficult. But if you've done usability testing with X number of people here's data. There's no data. This is the default would be my. Yeah. I mean it's difficult to make a decision without any like if it's just opinion against opinion or if we treat design as an opinion. So again research basically trumps these these factors like objective factors. I just think it's important not to think of design as an opinion because I mean you you go to school you learn a profession. And that I mean you can't always have statistical data saying it's a good design. It is a profession. And yeah. Anyone else. The next question is how does time influence the feedback process. So something very problematic I've seen is bike shedding like people talking about maybe that color should be a bit more purplish or something. But because I like purple. So that's not the right thing to approach things and bike shedding generally takes a lot of time and this waste of time. As again I said. Oh sorry. Yeah. Hey camera. As again as I said depends really on the who makes takes the decision so takes depends on the question before. So the bigger the community or decision making committee is the longer it takes. So if it's only one decision maker obviously takes much less time but it's less transparent. So it's a compromise always. One thing to know is that in open source design process and feedback can take like couple of months. So even in our community we've seen proposals that they didn't receive for I don't know five months responses and etc. And for designers can be very hard to go back in that mindset and remember what they've been there and create another iteration. So yeah. But oftentimes the time also helps to rethink and like get out of the maybe the thing you were stuck in back then. So you you can get removed from like your baby that you created as a designer and you're so attached to and yeah you get detached a bit and you can think about it more clearly again. So and another thing that is very important when you request design work. It's to also mention how much time that designer has to work or not because for example when requesting things for free. There might not be an urgency and if you want something very fast at least tell that designer that I don't know that OK it's free and it's fine but you need detergent or or not. No. OK. Well you want to say yeah. What would be great sometimes like often people seem to be unsure what they what they need and that's like super well it if you don't know how to approach a design problem. If you're not a designer yourself and in that case I think it would help for example communities like like ours a lot of people would be just frank about it and say I would like to have that improved. But I don't know know why so please first help me to to make a good decision about that. I think that's really important because design isn't just about going away and doing something in a in a in your tower and coming back and saying here it is. It's also talking with the people who have asked you and if they don't know what they need then it's your job to go back to the start and say OK what is it that you're looking for. And let's talk in the simplest of language. And then you get to the point where you've got a better understanding of the design thing that you're trying to do. OK now I understand. And it'll save pain and hurt. Make a summary of the things we discussed and it was if you were to pick one of the factors that is the most important design process which one would be. And the options were knowing who is the decision maker and or knowing what is the motivation for designer or understanding the need knowing the target knowing time constraint or any other thing. And currently for example the most important factor from the audience they consider to be the need so understanding first the need when you do a design. So talking to people. Yeah I mean like of course I agree it's the need but unfortunately some most often the reality is that you actually don't have time to do usability testing especially in open source. So unfortunately it ends up being just a whole bunch of opinions of a whole bunch of people on your issue tracker. So I think that's actually a good point that understanding the need is the most important point and doing usability testing or any kind of testing is a very important thing in design as a whole but especially in open source projects. Yeah it's been mentioned before it's I think it's the most important thing is that design not to treat design as an opinion because like people look at it as a form of art which it isn't. So for example you cannot say I like red so let's make the logo red because you need to understand that red might be aggressive it might in some countries it might have a different meaning. You might want to know that sans serif as font is different than serif font because blah blah blah. So you get to have arguments I think I can understand if you don't have the background to to to get that but comments like I love it or I hate it because man are kind of like unconstructive so I think this kills the process of feedback. Final question and when should the feedback the feedback process stops and the audience has options like after X number of votes or. I forgot. When the committee decides to when the designers decides to after a number of iterations. The designer. So the main questions was do you need to do like exciterations or do you need to wait like seven months or do you need to make the designer happy do you need to make the commuters happy the world or I don't know. I mean if we talk about it on a broader scale I think the feedback process never stops because software is ever changing and so that but that also helps making the individual feedback processes stop because we say OK what's the best for like the next. Half a year or what's the best for right now and then we also have things for for more future iterations so I think yeah at the same time it's it's good to realize yeah this will change in the future maybe anyway and five years ago it looked much different. And yeah but but that also helps for the immediate decision to say this is going to change in the future maybe anyway but we can always so we can always revisit it but for now let's let's decide on something which works for now. So I see that the winner is when owners are happy. Are they ever happy. So I think that it's very important to say kind of know that there should be time for several iteration because the first result would never the best would be never the best one. So when you plan to design something just just accept the idea that it should go through several iteration and even if you're not happy happy with the first one move on and iterate again. So the process never stops because we improve software constantly and it's never gets to the best point because everything is changing software has to change as well. So process never stops. I strongly disagree with this result. I'm sorry and I just want to do a comparison with that like there's a reason there's a CTO there's a reason there's a creative fleet. So imagine like a designer taking on the CTO position. I don't like this line of code like please don't do it like that. I don't like that. So it's that equivalent of the owners not liking or liking the decision. So if you have asked a designer to help you what's the point of asking a designer when you're doing the decision yourself anyway right. You just need a robot to implement the design for something which you have in mind because that's not how design works. So I think like everyone has their own skills and this should be respected of course in a more open and transparent way. So let's yeah that's a nutshell because we're late. So I sorry I completely disagree with this result as well. The software is being developed I presume for users. The designers opinion doesn't really matter if the users are happy with the software and they're using it more and there are more users and everybody is happy. That's a win. That's my opinion. Thank you. Maybe we just didn't have the option when the users. Yeah maybe there's no option. Katharina was being intentionally provocative. Okay. So thank you so much. We also have the please provide feedback for the sessions and thank you so much for participating.