Calling all UX Designers!
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 39 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/67208 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 202236 / 39
2
9
11
15
26
30
36
37
00:00
AnalysisDatenverwaltungFormale SpracheOrdnung <Mathematik>SoftwareExpertensystemEDV-BeratungProdukt <Mathematik>MAPSoftwaretestEntscheidungstheorieAnalogieschlussAuswahlaxiomBitDeterministischer ProzessDivergente ReiheEinfacher RingMultiplikationProjektive EbeneRechenschieberZahlenbereichZeitzoneE-MailVerschlingungSoftwarewartungGüte der AnpassungPrototypingExogene VariableSpannweite <Stochastik>FehlermeldungHelmholtz-ZerlegungPunktQuaderHilfesystemInteraktives FernsehenOpen SourceDifferenteMultiplikationsoperatorMapping <Computergraphik>SoftwareentwicklerDatensatzProjektive EbeneQuellcode
07:40
CodeDämpfungDatenstrukturFormale SpracheVersuchsplanungGebäude <Mathematik>Produkt <Mathematik>MAPBenutzeroberflächeGanze FunktionEntscheidungstheorieAuswahlaxiomBitDivergente ReiheGruppenoperationPhysikalisches SystemProjektive EbeneSpeicherabzugVisualisierungZahlenbereichGüte der AnpassungSpannweite <Stochastik>FontProzess <Informatik>Orbit <Mathematik>ProgrammfehlerStrategisches SpielZusammenhängender GraphTemplateNummernsystemPunktBridge <Kommunikationstechnik>KontrollstrukturQuaderGleitendes MittelBildschirmsymbolPixelWeb-SeiteUmsetzung <Informatik>VerkehrsinformationGraphfärbungSichtenkonzeptWeb SiteEndliche ModelltheorieNP-hartes ProblemTouchscreenFahne <Mathematik>Einfache GenauigkeitMultiplikationsoperatorMapping <Computergraphik>Minkowski-MetrikComputeranimationDiagramm
15:15
CodeComputerspielDigitaltechnikFormale SpracheMathematikMehrrechnersystemRückkopplungWärmeleitfähigkeitGebäude <Mathematik>MAPKonfiguration <Informatik>EntscheidungstheorieAnalogieschlussBitDivergente ReiheFunktionalProjektive EbenePunktrechnungRechenschieberSpeicherabzugStichprobenumfangZahlenbereichE-MailDatenflussSoftwarewartungExogene VariableParametersystemOrbit <Mathematik>ProgrammfehlerAdditionPunktWeb-SeiteUmsetzung <Informatik>FokalpunktRahmenproblemVerkehrsinformationAdressraumSichtenkonzeptHook <Programmierung>MultiplikationsoperatorCachingOrtsoperatorDoS-AttackeMechanismus-Design-TheorieTwitter <Softwareplattform>EinsCodeEntscheidungstheorieComputeranimation
22:51
ProgrammierstilSoftwarewartungStrategisches SpielPunktFokalpunktBesprechung/Interview
23:46
DatensatzQuellcodeComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:04
So thank you very much for having me. I'm talking about how to attract UX designers to FOSS projects. This talk came from the fact that I spoke last year at FOSS back on the reciprocal problem. You know, why is UX so damn hard for open source?
00:20
And if you want to go see that talk, that tiny link down here, tiny cc UX FOSS one, gives you a link to that original talk. It got a lot of good response and a lot of good questions. It was because of the community and the interaction that I decided to come back this year. So this year, what am I doing? I'm flipping it around. Instead of talking about my experience
00:40
as to why it was so hard for me, I'm flipping around to talk about specific things that you can do as a maintainer to attract and keep UX designers. I really want to stress though, this is a prototype. I have, I'm just basically summarizing all of the tricks that I use when I work on various teams and I'm applying it to open source.
01:01
I expect there could be a lot of questions and there may be better ways of doing what I suggest. So please write questions in the question tab. I'm going to be the breakout room afterwards. I really want this to be a learning experience for all of us here. So this is my talk. I got these five key points
01:20
and I'm going to, you'll see this slide multiple times as I go through. The first point here is what's at stake? You know, why should we be doing this? So the idea is pretty simple. By the way, I was working as a consultant at Frog Design for a number of years and it's really important that you answer this question, what's at stake? Because if you don't know what the problem is,
01:42
if you don't know why you're doing it, you can't be motivated to do it. So it's pretty clear. You just don't have the talent you need. I think everyone is agreeing, certainly in the paid world that UX design is critical. The question is how do we get that talent into open source projects? There's lots of discussions I've noticed online
02:01
about attracting help for devs. That's a well-known topic that I think has discussed a lot of conferences like this but why don't we talk about it for UX? So this talk is trying to change that because I can guarantee you there are UX designers that are looking at your project and just like a badly designed webpage, they're bouncing.
02:20
So what can you do to make that work a little bit better? So I understand the question is how and I understand that an awful lot of maintainers are a little outside their comfort zone. So this talk is effectively trying to address that to help get you out of your comfort zone, make you a little more likely to do this and be frankly more comfortable with this.
02:41
So why you? Why is the maintainer so important to do this? The analogy that I use is that of a CFO and a CEO. A CEO really understands finance as well. In fact, this many CEOs could be a CFO but they have a separate CFO and the whole idea of the CFO is to collect some data,
03:03
do a lot of analysis and present a series of choices to the CEO who then makes the final decision. That's just how things work but the difference here is there's a shared language between the CFO and the CEO. They speak the same language, they understand what they're doing, the CEO supports what the CFO is doing
03:23
and when the CFO makes recommendations, the CEO understands where they're coming from. It's that trust that makes for a very powerful relationship. Maybe you can see where I'm going with this but the example here is between UX and a maintainer. UX is not the maintainer
03:41
but they need to provide a whole series of, they need to collect data and provide an awful lot of analysis so the maintainer can make that decision and it's not going to work if you have no idea what UX is, you don't know what the shared language is, the shared vocabulary is, it's just not gonna be worth their time and they're gonna bounce.
04:00
So this is the analogy is like, why can't we have these two professionals that understand each other a little bit better and can cooperate? So another way of phrasing it is that could a maintainer not know how to code? I think the answer is of course not. They have to. You can't manage other contributions
04:21
if you don't know how to code. So UX is absolutely no different to that. It's not like you have to be a professional UX designer but you have to know a little bit about it and I would claim this is the number one reason why designers leave. It's that the UX designer is doing their thing. They're producing journey maps,
04:41
they're doing some analysis, they're doing some wireframes and the maintainer just doesn't get it. So that's the problem that we need to address here because why will someone do work if no one appreciates their work? So don't be worried. I'm not trying to say that you're doomed. I'm trying to say that a little bit of learning
05:01
can go an awful long way. So let's talk about these small things that you can do that'll really help. So start with camel and camel is just me trying to get a little cutesy to kind of decompose what UX is composed of and I'm just saying it's composed of caves, maps and Legos and camel is just a way for you
05:21
to kind of have a deeper level understanding. Don't treat UX like a box but treat it as a sub box filled with things. So let me go through each one of these things. Caves are about exploring the dark unknowns. That's what's really important. You need to basically understand that most devs think
05:41
that the answer is obvious. At least to them, just add another button or make a weird error message. If the user has read the manual, they'll know what to do and effectively, the most powerful trick I have in my arsenal to gain trust with a developer or a product manager is to have them watch a user test
06:03
because when they see real intelligent people struggling with the software, it usually makes a convert of them because they understand that they're not the user and really smart, reasonable people can be completely confused. So that's what I think is about exploring these caves.
06:22
What is actually confusing real people, not experts like you, honestly? And it's not just simply about the software. If you really are exploring these caves properly, you're exploring a broader range of things. It's like, how are people using the software? How do they approach it?
06:41
What do they do afterwards? Where are they using sticky notes? Just what are the band-aids that they're using in order to use your software? When I consult with startup companies, I often say that really transformational products solve one ring out. In other words, every company, every product
07:00
has one magic technology that they know, that they know they have to build. That's not the problem. The real issue is the ring out. What's the extra thing that you need to solve to get them into your project? So I was working with a company that was doing a kind of mail merge product, and they realized that people were having a hard time
07:20
importing their contacts. So in order to do a really kick-ass mail merge, they actually had to solve the importing problem as well, as an example. So now moving from caves, which is exploring the unknowns, just getting a sense of everything, is maps. What is the user's journey? How do they get from where they are to success?
07:42
And what does that look like? And this involves asking a lot of questions. Who is the user? What are their pain points? And what can't your tech do for them? It's really important to know what you're good at and what you're bad at. And this actually, there's a whole range of things that you can do to kind of articulate
08:01
just what's it look like to be a user. So that you can talk about them and appreciate what their journey is. So it's really hard though, to get this common understanding and good UX is based on having a good map. But what happens is discussions can wander all over the place, especially if you've got a dev team
08:22
that really thinks they understand everything and they're building just for themselves. So core tech decisions can be questioned. There are unclear impacts. The UX person could be asking for things that have huge technical costs to them. And so just danger flags just start flying up all over the place.
08:40
And too often, I mean, UX designers are seen as kind of this harbinger of death. It's like all they do is just make things harder. But the reason they're doing this, of course, is they're seeing it from the user's point of view and they're asking, can these problems be solved? You don't have to say yes to everything, but it is important, I think, to at least draw a map of these things
09:03
and to figure out what's going on and have that discussion. So the last thing I wanna talk about is Legos. How are we going to actually build this? So most people, most devs in particular, think of UX as just pretty pixels
09:21
and just making sure that everything's working okay. Yeah, good, okay. Most people just think that, most devs think that you're just pretty pixels and you just simply just throw something up on the screen. Good visual design is about structure. It's about a language for your icons. It's about having a good color scheme. It's about having white space.
09:41
It's about having good font choices. Really good visual design calms things down and allows people to kind of absorb your product in a much more reasonable way. It helps improve cognitive absorption of your product. But doing it consistently is very, very hard.
10:00
So the one advice I would have is to learn more about design systems. Design systems are a powerful bridge that breaks your product up into UX components and then those components can then be implemented by the tech team. And once they're implemented properly, those components become Legos that then just get snapped together. You don't have to redo every single dialog box from scratch.
10:24
You just use the dialog box Lego and the button Lego and the label Lego and so forth. So it's a collection of radio buttons and templates and icons and systems that allows you to have a very high level discussion of how you want to put your product together. So here's the summary of my camel models
10:42
that in a sense, I haven't done a very good job of hiding that caves are about user research, maps are about user experience design and Legos are about visual design and how each one of these things is accomplishing a very physical thing. User research is exploring these dark places and helping you see them. They're shedding light, maps is articulating the journey
11:03
so that you can talk about who the users and the pain points are and Legos is about how you construct your user interface in a consistent way. So if there's books that you want to read, these are three that I recommend. They're all really good at talking about effectively each aspect of this, how to manage the project, how to think about
11:22
how to do research and how to build design systems. So these are three good things to get started. If you want to learn a little bit more. So now we're moving on to number four, UX as an asteroid because I've seen this play out in projects all the time. What do I mean by UX as an asteroid?
11:41
Well, effectively when an asteroid is coming towards earth, it's like a little bit like fixing UX problems. It's like you have this problem with coming to earth and you want to divert it. If you do a little nudge really early on, you can divert it and it's no problem at all. If you wait until the very, very last minute, you have to nuke the thing from orbit.
12:00
And I would argue that the number one reason why devs hate working on UX is because they ignore it for too long. They're always having to pull out the nuclear weapons. And this is why UX designers so much want to have these conversations before you write code. Having these conversations, articulating the maps,
12:21
making the hard choices upfront allows for much smaller investments in code. Too often in FOSS projects that I've been working on, their entire UX strategy is just basically a bug report. Well, let's just build it first. Let's just get something up. Let's just get an MVP and then we will fix everything through a series of bugs.
12:43
That's possible, but you're constantly nuking things from orbit. All the hard technical decisions have been made. They're baked. The APIs are done. If the UX designer wants to try something even slightly different, it's like, roll your eyes. These guys don't understand code
13:01
and that's a huge problem. So enough of this touchy feely bullshit. Tell me something specific to do. This is where I want to move into stage five, specific actions you can take. There's five things we can talk about starting from super easy to getting harder and harder. So let's take the easy ones first. Better onboarding.
13:20
Just have a welcome page for contributors. A lot of your sites have it already. That's great, but just simply have one for UX designers. So Elementary OS is a good example of a company that does this exceptionally well. Their onboarding welcome page is fantastic. So go check them out. The next one is this works for devs and UX.
13:42
So there's no reason why you can't have a welcome page just for UX designers as well. And once you have a simple onboarding webpage, you can then grow it and make it a little bit better so you can add motivations, your core values, you can link to critical documents so that people can kind of get a shaper what you're doing more quickly.
14:00
Home Assistant, by the way, does an amazing job of this and it has an excellent kind of jumping off page. So just start small though. This is the easiest one. You literally just need a welcome page that says, we are looking for UX designers that just lets them know that they're wanted and that's a very, very powerful thing.
14:23
Of course, once you get that in place, you can then grow it over time, but let's take baby steps. Okay, better hashtags. A simple trick to improve your issues in bug reporting is to just simply have a hashtag so that you can tag things in your issues and bugs so people can find them. It also gives visitors something to find.
14:41
What can I get started on right away? So hash design is a start. I think many groups have done that, but I'd recommend that you actually break something up a little bit more. So you have user tests, wireframe, visual design. They're even better. This actually is talking about this camel model I talked about better. You have hashtags for each aspect of UX, but here's the critical thing.
15:01
You actually have to use them and set an example for the team. If you don't use them, no one else will. Find better history. You have to move beyond the code speaks for itself. The idea here is that when you make a key decision, write it up, put it in it, have a core decisions document that you log all these changes
15:21
and then blink this document into your onboarding, your welcome page. But I'll tell you, this is a pain, but it does a couple of really critical things. The first is just by writing it down, you distill what you've learned and it clarifies it. Often by writing it down, you realized you missed something.
15:41
Second, the rest of the team can learn and verify what you've decided. It's not uncommon for you guys to make a decision, write it up and share it out. And then some of the team goes, no way that can't possibly work. Now, yes, that's a little bit chaotic to have that conversation, but it's better to have it now than three months down the road when a bunch of code has been written up.
16:01
So this is a forcing function to make sure that everybody agrees with this critical position that you made. And linking to it can short circuit endless discussion. You're gonna have an issue where some noob comes in and says, hey, I want us to do this. And you gotta go, no, we already discussed this back in April. Here's the discussion point.
16:21
So it allows you to short circuit a lot of discussion by saying, this is canon, this is what we've agreed to. So better discussions. This is really a deep topic. And I think I could spend, I have actually spent an entire conversation about how to do this, because teams are terrible at discussing UX.
16:42
And there's ways to do it. So effectively, what I would recommend is in addition to an onboarding guide, have a design discussions guide. It's similar to a code of conduct, and the same people are going to complain about code of conduct as their discussion guide, but it's a way to get started. And you link to it on your welcome page. So I've actually written up a sample one
17:00
at tiny.cc UX discussion. And it's a place for you to get started. I can't go through it right now. I'm running, I only have a few more minutes left in my talk, but it's a, I wanna roughly go through the high level points so that you know what we're talking about. The first one is that whenever you talk about a feature or a UX issue, focus on the target audience first.
17:21
And after you identify who it is for, focus on the pain points second, because too many people jump to a solution and they don't talk about why they're doing it, because I can guarantee you there's a second and a third and a fourth option. And so by talking about target users and pain points, you're opening up the discussion broader. Be clear about what feedback you like.
17:41
This is especially true for UX designers. Say, this is an early sketch. I'm just talking about the flows here. Don't focus on the pixels, that kind of thing. It's really important that when you do have a conversation, you're clear what kind of feedback you want. Improve your idea by combining alternatives. Too often, it becomes my idea versus your idea, and it's a huge fight.
18:01
Step back, ask open-ended questions. Why do you want that? How does that benefit the user? And usually, by combining an A and a B, you get a C that's far better than either A or B. Avoid long paragraphs. Too many conversations are long, long, long rambling things. Write a long email if you want to,
18:22
but then trim it down. Make it a couple of bullet points. Concise arguments are better arguments. Lock down decisions. We talked about that before. Once you write something down, once you figure it out, write it down. And then be a good responder. In other words, always acknowledge the person's point. Make sure they feel heard,
18:41
and then you can go ahead and ask a few questions, and then finally answer. It makes the team feel so much better if they feel heard. And of course, this goes back to the design guide, the code of conduct. Never use personal attacks. So the idea here is that these first two points are about framing. Make sure that whenever you discuss it, you have a frame of reference.
19:01
These next ones are just how to communicate better, just techniques. And this, by the way, works not just for UX, but for anything in your project. And finally, this last one is just not being a dick. I mean, it's just don't be that kind of person, and hopefully we don't need to spend a lot of time on number eight. Now, like I said, a lot more can be discussed here. We need to have a lot more conversation about it.
19:21
So please go to tiny.czuxdiscussions and check it out. And I think it is a very rich way for you to improve how you guys work together as a team. So my last point is kind of the obvious one, but it's the best one, which is just get a UX designer on the core team. This is clearly the hardest one to do, but it's the most effective one
19:40
because it allows you as a maintainer to offload a bit of your burden. Having a UX designer on the core team, for example, like elementary OS does, gives a certain cache to UX. It makes UX designers feel welcome. There's someone that speaks their language. It's very, very powerful. So if at all possible, give it a shot. Of course, you're not off the hook. You're still the CEO, and they're the CFO.
20:01
You still need to talk and learn UX and support them. Otherwise, they'll leave, but it's a good start. So I've now kind of reached the end of my talk, and here's basically the summary. And I wanna make sure that anybody has any questions, start writing it up. But the key point here is what's at stake? The stake is that you need to attract talent,
20:23
specifically UX talent. And if you don't take it seriously, you won't get it. Why you? I'm gonna go back to my CFO and my CEO analogy. CEOs don't work if the CEOs don't understand finance. The same thing is true for UX. You have to understand enough about UX.
20:40
Otherwise, no one's going to want to work on it because you're going to ignore their advice, and they're going to leave. Start with camel. Once you understand a little bit more about UX and that it's really composed of exploring caves, creating maps, and building Legos, you have a more nuanced view of what UX is, and you've got more vocabulary to talk to your UX designers about.
21:02
This will make you an easier person to work with. UX is an asteroid. If there's one thing I really want you guys to understand is that UX starts early. Do not treat UX like a series of bug reports. You're gonna be constantly nuking asteroids from orbit. It's gonna make your life miserable, and everything is going to be a lot of work.
21:22
It doesn't need to be that way. The earlier you start, the more gentler and the easier it is to discuss these things. And then the five things I wanted you to try, which is to basically have a better onboarding flow. Use, you create and use better hashtags. Have a better history mechanism
21:40
so that you document what you do. Check out my discussions documents so that you guys can actually have a culture that talks better about UX. And finally, just if at all possible, get a UX designer on the core team. I know that's a big ask, but that'll really help quite a bit. So, as I happened with last year,
22:00
I really want this to be a conversation. And so I really want to have this not be a one shot deal. So the slides that I just showed you here are available at tinyccuxfos2. UXfos1 was my talk last year. UXfos2 is my talk this year. I am gonna go to the breakout rooms afterwards, depending on how many questions we have,
22:21
but here's my email address. So please send me an email, let's talk. You can also reach out to me on Twitter and we can engage there. I feel like we're not gonna solve this by just me talking to you, but having this be more of a community conversation. I also hope that this talk isn't just filled with UX designers. I actually hope there's some UX maintainers in here,
22:41
but we'll go from there. So I think at that point, I am done. I'm going to stop presenting and I'm ready to take questions. Yeah, thank you for the talk. The questions, there's a couple of questions. The first is, are the following also UX?
23:04
A CLI, an API, a coding style guide, emerging strategy or a contributor guide? I think the last point you already mentioned. Yes, they could be related. I think they're worth talking about. I don't think they're really
23:21
the primary focus of my talk. I really, and we can talk about having them there, but that could be added. I just wouldn't claim those are the first steps that a maintainer should be doing. That's why, the whole purpose of my talk was to give a prioritized list, to say let's at least just start with these things
23:41
and get you along the way. And then we can expand it to the kinds of things that we've just mentioned.