WEBVTT 00:00.000 --> 00:11.640 Hi, everyone. Good afternoon. I'm Archita, I'm a UX designer from Canonical. They publish 00:11.640 --> 00:17.920 her off Ubuntu and I am so happy and a little bit nervous to see the whole room for people 00:17.920 --> 00:25.560 are standing in the back. And I want to ask, how controversial it's going to be and how 00:25.640 --> 00:32.680 maybe inspiring it's going to be, how many of you are designers? Oh, okay. How many of 00:32.680 --> 00:39.800 so there is none designers. So I am hoping that this is going to be encouraging for you. 00:39.800 --> 00:45.960 As for a designer to say that you don't need to be a designer to design to fix UX in open 00:45.960 --> 00:54.520 source could be a bit controversial. And yes, so I move from commercial tech to open source 00:54.600 --> 01:02.920 happy me. But this question has been around for quite some time in open source community. Many 01:02.920 --> 01:10.360 of you have already probably seen a lot of blog posts, articles, panel discussions around exactly 01:10.360 --> 01:18.040 this topic. And I want to start by acknowledging that this conversation exists and it matters. 01:18.920 --> 01:27.800 And a lot of important work has already been being done by many designers and also some of 01:27.800 --> 01:34.200 very familiar faces in the room today. These designers have been using their voices to advocate 01:35.160 --> 01:41.880 for why is it important for UX within open source especially? And they have been 01:41.880 --> 01:48.600 relatively working on improving the design contribution processes and making better ways for 01:48.600 --> 01:56.040 designers to contributing to open source projects and also being pushing design in forward 01:57.160 --> 02:02.440 direction. And this work is valuable and it is moving things in the right directions. 02:03.480 --> 02:10.200 And I would like to think that we have moved past a point where we are having to convince anyone 02:10.280 --> 02:20.440 still that UX matters. I say this because I work with a lot of developers and non-designed people 02:20.440 --> 02:27.320 who already do care about users. What I'm trying to say is that the awareness is changing. 02:27.320 --> 02:35.240 It is getting better and that's a good thing. But if you have spent any time in any open source 02:35.320 --> 02:41.800 forums or GitHub discussions, you start seeing a lot of questions and comments where 02:42.600 --> 02:49.960 project maintainers are having a list of UX issues that they would like to solve. But there is 02:49.960 --> 02:55.560 just no UX designer who is willing to come or maybe they're too busy. I don't know, but 02:55.560 --> 03:02.120 they seem to be less designers trying to fix things. I mean these are not rare cases. They are 03:03.000 --> 03:09.960 everyday reality of open source projects. And in a perfect open source world, every project is 03:09.960 --> 03:15.000 going to have a designer who is working side-by-side with a developer. They're going to be happy 03:15.000 --> 03:21.480 together. But the reality is that most don't. And you will see a long list of UX issues. 03:23.080 --> 03:29.000 Yeah, maybe one maintainer just trying to struggle everything together. It's not that people don't 03:29.080 --> 03:35.880 care about designer design. It's just that in open source, a lot of projects tend to be 03:35.880 --> 03:42.440 voluntary driven, developer-led and sometimes it's as simple as just not enough designers. 03:42.440 --> 03:50.520 And I believe good UX shouldn't depend on whether a designer is available to come and fix it. 03:50.680 --> 04:01.400 If we are being realistic, for us to get into a better place where every project is having 04:01.400 --> 04:06.440 UX support, it is going to take time. I have full conference, it is going to change, but it is 04:06.440 --> 04:11.400 not going to happen overnight. It's going to take a little bit of time. And while we wait for 04:11.400 --> 04:21.800 that future, the UX issues don't pause. These are still struggle. We see they do get confused 04:21.800 --> 04:29.960 in the docs. And because of that, the good features still don't get adopted as much as they 04:29.960 --> 04:36.120 should be. And ignoring this problems could cost us a lot more in the long run. 04:36.120 --> 04:46.840 And I want to take us a moment to have you ever thought. I see the problem, but I'm not a designer, 04:46.840 --> 04:52.840 I can't fix it, and there's not a designer, so the problem should just keep existing for eternity. 04:54.440 --> 04:59.880 As I mentioned, I do work every day with product managers, developers, engineering managers, 04:59.880 --> 05:07.800 and I do see that everyone genuinely cares about the users who are going to use the product 05:07.800 --> 05:14.680 they're building for. And so when someone says that thinking about users is a UX designer's job, 05:15.400 --> 05:26.120 I never quite believe it. Because I think every person, but most of every technical person, 05:26.200 --> 05:35.560 a non-designer, is capable of thinking like a designer. And yeah, you might think I might be 05:35.560 --> 05:42.360 delusional. And can ask, why should you believe me? I would like to say, well, I'm a designer, 05:42.360 --> 05:49.240 and I'm saying that people can think like a designer. But more importantly, I'm also an engineer. 05:49.240 --> 05:55.080 I have a bachelor's and a master's degree in engineering before I decided that I want to do the 05:56.040 --> 06:04.040 design. And I've trained for most of my life to be an engineer, which means that I focused 06:04.040 --> 06:09.400 on jumping to solutions, because there is supposed to be only one right answer, one right solution. 06:09.400 --> 06:16.760 But when I was introduced to the design world, it made me stop at the problem to understand 06:18.120 --> 06:24.280 who am I solving this problem for? And you know, why am I even solving this problem? Is it 06:24.680 --> 06:31.160 the right problem to solve in first place? And I think that is a really important thing for any 06:31.160 --> 06:36.600 office to stop and think not just as a designer, but as a human being in an everyday life. And I think 06:37.720 --> 06:46.440 that stands as a base why I believe. You can also think like a designer. And when I started learning 06:46.440 --> 06:51.160 UX design in the first place, I realized it's not a completely new skill set that I have to 06:51.240 --> 06:59.960 develop. But it was just a different way of looking at problems. And so today I want to offer 07:00.760 --> 07:08.520 parallel perspective that instead of leaving the UX problems, unaddressed, untouched, until 07:08.520 --> 07:16.600 a designer is going to come and fix. What if we fix them in small steps progressively, 07:16.600 --> 07:22.840 but intentionally, you know, what if contributors, maintainers, product managers, developers, 07:22.840 --> 07:28.440 everyone who is actually passionate about their own project. What if they can start surfacing the 07:28.440 --> 07:37.080 UX issues early and even better start fixing them by themselves? Because I think another controversial 07:37.080 --> 07:43.640 thing I'm saying here is that UX is not owned by designers. I believe it is a shared responsibility 07:44.040 --> 07:51.160 because when everyone in the project start to spot the friction and try to improve it, the whole 07:51.160 --> 08:01.000 community, I would like to emphasize that design is in just a credential or a degree that you need 08:02.600 --> 08:10.200 design is the way of thinking and it is also skill that anyone can practice. It would take a little 08:10.200 --> 08:15.480 bit of time, but you can practice. Another thing that I want to emphasize is that when I say shared 08:15.480 --> 08:21.160 responsibility, it doesn't mean that all of us designers and non designers are doing the same work, 08:22.360 --> 08:30.920 but it means that everyone can contribute. Designers still bring deep expertise, but what would be 08:30.920 --> 08:36.600 even better is like developers bringing context. Even before a designer is taking a look at the 08:36.920 --> 08:42.600 project, obviously you do bring the constraints, setting the limitations, which is great, 08:42.600 --> 08:48.040 but also bring real world signals, which is what we are going to talk a little bit ahead because 08:48.040 --> 08:55.640 when more people start contributing the fixes going to happen much faster. So that's why I want 08:55.640 --> 09:03.880 to break down UX today, not as a role, not as a title, but as a practice, something developers 09:03.960 --> 09:11.960 a non designers can use to move things around, to move things forward, but there is a lot of 09:11.960 --> 09:19.240 misconception about what UX design is. So the first thing, UX design is not a design tool. 09:20.840 --> 09:29.320 It is actually something that starts way before you even open a design tool, a file, and it starts 09:29.320 --> 09:36.520 when you start notice that someone wasn't able to do what they set out to do, and in true 09:36.520 --> 09:46.600 open source spirit, if your project might enter your UX, an identifying issue starts when someone 09:46.600 --> 09:55.240 got confused in your readme section. Another big misconception is this UX design is making things 09:55.320 --> 10:00.520 pretty, I've heard it a lot of times, but it is not about making things beautiful. I mean 10:00.520 --> 10:07.560 pretty is nice, I definitely agree, but useful is even better. The real goal of UX is 10:07.560 --> 10:13.480 into decorating your interface, but it is about making sure that people can actually use your 10:13.480 --> 10:20.200 interface without any frustration, with no confusion or even you are abandoning it halfway through. 10:20.440 --> 10:28.680 Finally, UX is not fancy frameworks. It is in some secret source or a complex process that 10:28.680 --> 10:35.480 only trained designers can follow. You probably see in this the very famous double diamond method, 10:36.120 --> 10:42.040 but if you just take a minute, look at the words, or maybe don't look at the diagram, and then see, 10:42.840 --> 10:49.640 the first thing is like you are trying to understand what the problem actually is, and then you try to 10:49.720 --> 10:56.200 pinpoint what is it that exactly need to be solved. And then maybe you ideate our how many different 10:56.200 --> 11:02.920 possible solutions can exist. And then you start building some of the possible and viable solutions. 11:02.920 --> 11:08.600 And if you really see, this is really just how problem solving works. It doesn't matter if you 11:08.600 --> 11:17.240 are coding or if you're designing, it's just pure problem solving. And now that we've seen what 11:17.320 --> 11:23.400 UX design is not, let's see what UX design is, and I'm simplifying it to the core for the 11:23.400 --> 11:30.040 sake of the talk, but UX design is understanding what people are trying to do and improving it. 11:31.560 --> 11:37.480 That's it. That's the core of UX design, and for the sake of, again, simplifying it, and if you 11:39.720 --> 11:45.720 want to take away two keywords from this talk today, it is two words, understand and improve, 11:45.720 --> 11:52.200 and let's see how we can break these two words further down. Starting with the problem, 11:52.920 --> 11:59.240 I would like to share a few quick tips, methods, and how you can go about understanding the 11:59.240 --> 12:04.840 problem and for the designers in the room, I assure you, I'm not trying to change completely how 12:04.840 --> 12:11.960 we're going to do the things. I'm just trying to enable the entire ecosystem to just start doing things. 12:12.040 --> 12:20.920 And the first one is observe. Observe where people get stuck. You don't really need fancy research tools. 12:20.920 --> 12:28.840 You just need someone new to try a project, a friend, a contributor, a neighbor, a partner who is not 12:28.840 --> 12:34.520 very technically oriented, like just give them their install instructions and watch them, 12:34.520 --> 12:39.480 don't tell anything. I mean, don't try to explain just watch. I know it can be painful, 12:40.360 --> 12:46.920 but it is educational. You'll see them pause. You'll see them rereads, scroll back, and get stuck. 12:46.920 --> 12:55.400 But that is the thing. That is where your UX friction is. Now, as a UX designer, I normally do spend 12:55.400 --> 13:00.760 a few days, a few weeks to do the whole process of like UX research, the interviews, the usability 13:00.760 --> 13:06.840 tests, but most times an open source thinks move fast and people contribute when they can 13:07.800 --> 13:14.520 especially in voluntary driven, volunteer driven projects, which means some, we don't have someone 13:14.520 --> 13:21.400 to always come into a very dedicated UX research, which is absolutely normal. It just means 13:21.400 --> 13:28.040 that the methods that work best for open source are like right. It's not perfect. I know, 13:28.040 --> 13:33.880 but it is practical and sometimes just watching some, the user behavior, even one user behavior 13:33.880 --> 13:39.560 for 10 minutes could be a lot more insightful than just trying to guess what could have been wrong 13:39.560 --> 13:48.200 for like 10 hours. Now, once you spot the problem, the next step is not to jump to solutions 13:48.200 --> 13:53.640 right away. And this is a very important lesson I have learned, moving from my engineer mind to a 13:53.640 --> 14:01.000 design mind, is that we should stop and ask why? And ask it a few times until it hurts, 14:01.880 --> 14:08.040 uses failets at up, why? This gets up too, why? It's buried in long test, why? 14:08.760 --> 14:14.840 Talks lacks structure. So, this is something like debugging, but for human behavior, 14:15.640 --> 14:23.640 and it is important to uncover the root cause, not just the symptom. And honestly, if you were 14:24.360 --> 14:28.440 a kid like me who used to just ask a lot of questions, this is your moment to shine, 14:28.440 --> 14:37.800 keep asking why. And the next one, talk to a few users. You don't need a full user research, 14:37.800 --> 14:43.800 a user study. You just made a few real conversations. Ask them what they're trying to do. What 14:43.800 --> 14:51.160 was easy, what was hard, and when did you get less frustrated? Now, in proper UX research, 14:51.160 --> 15:00.200 we do emphasize about things like statistical significance, with data supporting from dozens of 15:00.200 --> 15:08.200 users. And this quick method is not about replacing that, but it's really about noticing patterns. 15:08.200 --> 15:13.560 And you can be surprised to see that even after talking like five, just five to seven users, 15:13.560 --> 15:20.600 you will already see like 80% of usability issues as Jacob Nelson had once mentioned. So, 15:20.680 --> 15:24.440 these small conversations can really add a lot of insight. 15:25.720 --> 15:29.640 Once you've understood the problem, I think it's really, really important to define it clearly. 15:30.200 --> 15:34.520 I think this is also another place where a lot of people do fumble a bit that they start to put it 15:34.520 --> 15:39.160 down like, oh, this is what we're going to build. We need a newest installer, but that is not a solution. 15:39.960 --> 15:42.520 I mean, that's not a problem statement, that is a solution. 15:42.520 --> 15:52.040 Like the good problem statement, again, like the tip here is about defining who is struggling, 15:52.040 --> 15:57.880 with what, and why? Like if you can answer these questions, I think you do have a problem statement 15:57.880 --> 16:02.920 well defined. And if you can see it in one single breath, your focus enough to start solving it. 16:02.920 --> 16:09.960 And if not, you should go back, probably redefine it again. Now, the exciting and fun part, 16:10.600 --> 16:16.760 improving the solution, could be scary for someone like me who is not greatest sketching a drawing, 16:16.760 --> 16:22.760 but really, don't, don't be afraid. Like it doesn't mean it in an artistic way. 16:22.760 --> 16:28.360 It's just boxes, which are essentially your screens. The arrows which could become your 16:28.360 --> 16:34.760 flows and the labels which would guide you towards your information architecture. Take a picture of it, 16:34.840 --> 16:42.680 share it in your repo, the issue, comment section. And you see, like it's going to do one, 16:42.680 --> 16:48.120 you can share, I just just pen and paper work. If you want to go even for the, this is one of my 16:48.120 --> 16:58.520 favorite ones, take a paper, fold it into eight pieces, and give person these eight boxes, 16:58.520 --> 17:04.520 eight minutes, and they need to sketch eight ideas. And you will be surprised how creative your brain 17:04.520 --> 17:12.520 can get when it is under pressure. Another important thing is about testing. It isn't about 17:12.520 --> 17:19.400 polished screens, it's about validating thinking. So, a sketch, a flow, a sentence. All of these are 17:19.400 --> 17:27.240 testable. You don't always need a prototype to test. You just need something people can react to. 17:27.240 --> 17:34.360 So, there you go, a simple method, like to do test, but I would just bring like one quick 17:35.080 --> 17:41.720 usability test, like it's one minute test. You give one user, one task, and watch for one minute. 17:42.600 --> 17:48.360 No hints, no explanation, and wherever the pause or hesitate, like that is your UX mark. 17:48.360 --> 17:56.440 It's fast and lightweight, perfect for open source. Now, who is real user? Don't go for expert users, 17:56.520 --> 18:04.200 always start with the newbies. They are bold. They start noticing issues which expert users can't 18:04.200 --> 18:12.200 and try to pick users who match the skill level for your target audience or who want to use your 18:12.200 --> 18:21.400 project as well. It's a rate, always a rate. Start with small fixes, test it, repeat, and remember 18:21.480 --> 18:27.960 progress is far better than perfection. I think this is another really important lesson I've learned 18:27.960 --> 18:34.360 in recent times is documentation. Document your UX improvements because they shouldn't disappear 18:34.360 --> 18:42.280 in your commit messages. Adelable of UX improvements or contributors, see UX as a part of 18:42.280 --> 18:48.120 your project DNA, and you can just answer these points like the problem you saw, what you're 18:49.080 --> 18:57.000 tried and what changed. So, here's your UX tool kit and you might have noticed none of that 18:57.000 --> 19:04.200 needed, Figma or Photoshop or any other design tool. You can think of it like debugging, but for 19:04.200 --> 19:11.480 people, you find the bug, you trace it, fix it, and test again. That's UX design in the simplest form, 19:12.440 --> 19:18.200 and I hope you do agree like you don't really need a designer. You need to be a designer to 19:18.200 --> 19:25.160 do it. You just need to be curious enough to understand and brave enough to improve it. But here's 19:25.160 --> 19:33.880 the magic. I think the impact multiplies when developers and designers collaborate. So, I'm going to 19:33.880 --> 19:40.760 speak just a couple of minutes into this. What does it mean to collaborate? I mean, until now, 19:40.760 --> 19:46.840 we saw how all of you can go and start improving UX when there is no designer, but when there 19:46.840 --> 19:53.320 are few lucky times and you do have a designer or they're dropping in briefly, how can you help 19:53.320 --> 20:00.760 designers help you? This is how. Use all the tips you've seen today so that you can surface 20:00.760 --> 20:07.560 the friction early and you start adding context to it. Put an information that you've collected 20:07.560 --> 20:13.560 from all the user chats that you've been having. It is going to give that start starting boost for 20:13.560 --> 20:18.840 the designers to start thinking about like their proposals and you already do it really well, 20:18.840 --> 20:26.200 show constraints. It's going to make design proposals realistic and faster and what can 20:26.200 --> 20:33.800 designers do? What I've learnt to be learned is that by enabling system, which means you need to 20:33.800 --> 20:38.200 enable all the stakeholders you're going to work with. The technical authors, the developers, 20:38.200 --> 20:46.440 product managers, which means like you can start doing this by helping this contributors. 20:46.440 --> 20:51.880 Non-designed people, how can you recognize issues earlier? And you can do that by making like 20:51.960 --> 20:58.040 simple UX checklists, which will lower the bar for non-designed people to start contributing 20:58.040 --> 21:06.280 to design and believe in them. Turn the insights that the developers contributors are bringing 21:06.280 --> 21:13.160 and turn it down into your UX events. But what I love the most is make design thinking contagious. 21:14.200 --> 21:21.400 When designers explain how they think, not just what they propose, I think contributors 21:21.480 --> 21:28.600 start to ask better questions themselves. And I'm not just saying this because I've 21:28.600 --> 21:35.080 put it on the slide here. I'm very grateful to have learned this in the last two months, because 21:35.080 --> 21:41.400 I'm part of a team in canonical who is trying to enable the system for non-designed 21:42.040 --> 21:45.400 starting from technical authors. For the last two months, we've been trying to teach 21:46.120 --> 21:51.320 design thinking as a way of thinking for a cohort of eight technical authors and we've 21:51.320 --> 21:57.480 already saying really beautiful results on how much they are able to already start changing things, 21:57.480 --> 22:02.520 enabling things with in each product team. So when a designer is not able to be in all the teams, 22:02.520 --> 22:10.120 you have enabled someone to start bringing insights for you. So spot issues early and that's when 22:11.080 --> 22:17.640 you know, if you start taking shared responsibility for UX and improve it intentionally, 22:17.640 --> 22:25.480 that's when the impact scales. So I would like to conclude saying, you don't need a title to care 22:25.480 --> 22:35.720 about users. You don't need perfect conditions to improve UX. You can come together, start small, 22:35.800 --> 22:43.640 be intentional. And that's when the products, especially from open source, can be not just powerful, 22:43.640 --> 22:53.320 but genuinely useful. So I hope it starts to be less controversial now. Thank you so much. 22:53.320 --> 23:14.120 How are we doing on time questions? Okay, perfect. Yes. I can hear, yeah, you can tell. 23:23.320 --> 23:34.280 And even there's no design as you can see, but I think this is kind of like designers and the 23:34.280 --> 23:46.120 engineers are learning about some of how many most I call like design engineers. Or do you 23:46.120 --> 23:54.040 extension it? Oh, do you experience, like, what's the common, let's say mistakes or 23:55.480 --> 24:03.640 like these developers or there's no engineers team, they might need to be careful. 24:05.320 --> 24:11.080 Yeah, that's not. So your question is how can the developers with the no designers can be careful 24:11.080 --> 24:21.640 when the boundaries start to learn? I think the most important thing is to listen, listen to 24:21.640 --> 24:27.240 people who you're talking to. And I think it's also important to pick who you're talking to. Like, 24:28.520 --> 24:34.840 I mean, as I mentioned, like, who is a real user? Like, you need to pick the right set of people 24:35.800 --> 24:40.920 who I know. So I think it's very natural to be very protective of the work that we do. 24:41.800 --> 24:47.640 And what's important or something to look out for is to be humble, be open and like listen, 24:47.640 --> 24:53.160 start listening, what's being told. And it is not just about like taking notes, what's being told. 24:53.160 --> 24:57.320 It's how do you translate? Okay, they are saying like they don't like something. They're 24:57.320 --> 25:02.520 finding it something difficult. You need to start reading in between lines. Like, what does 25:02.520 --> 25:08.600 it actually mean? Like, why is this person struggling with this? Not just like, oh, they are 25:08.600 --> 25:13.880 not able to get past like stuff. Those are maybe we remove something. But you really need to understand 25:13.880 --> 25:21.880 like get to the core of the problem. Yeah. We have time for one short question. Yes, yeah, on the back. 25:32.520 --> 25:40.120 Yeah. Yeah. So your question is like, how can we have a lot of users come in? Yeah. They don't 25:40.120 --> 25:47.720 improve the design work we've done to guide them. Then you just do like a chat box. 25:47.720 --> 25:50.120 It was something and the wrong introduction. Yeah. 25:50.120 --> 26:02.360 Yeah. A lot of people on the right path. Yeah. So your question is like, how can 26:02.360 --> 26:10.600 you guide users in a better way rather than jumping off like to use a chat box for example? Yeah. 26:13.000 --> 26:19.880 Documentation. But designing documentation. I think like, now that I'm working with technical 26:19.880 --> 26:25.160 authors, like, we are also like trying to blur the lines between there. It is important, like, 26:25.160 --> 26:30.440 how you write, like, what you write things? But it is also important, like, designing the whole 26:30.520 --> 26:35.560 process, like, how are you documenting it? Like, are people able to find information in the first 26:35.560 --> 26:42.200 goal? What is there in your, the first page that users are seeing? Are they having to scroll through 26:42.200 --> 26:48.440 like different levels of information? So I would say that documentation can also be seen as a 26:48.440 --> 26:53.720 practice of design. You need to design documentation better. So people will rely on what you're 26:53.720 --> 26:59.320 trying to say rather than a chat box, which could be inaccurate at some points. Okay. So that's my 26:59.320 --> 27:01.320 time. Thank you so much.