Designing in the open - The UX of UX
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.
Nayyar, Raghu
Open source software has always been engineering driven. Most of the peoplebuilding open source software are engineers with major turn on for featuresand more features which kind of explains how a lot of open source projectshave rich and extremely important features but are a pain to see or work with.This talk aims to deal with this problem of designing in the open which isoften neglected. Tools like GitHub, GitLab, etc. can actually become an arenafor usability testing and give extremely promising output only if it followsan effective design process. This talk is also a practical guide for buddingdesigners to get started with open source software.
 So we will start. We have the wrap-up talk about the UX of UX. So yes, this is the UX of UX. It's a pretty meta topic, but it also is, actually, the stock is very important to me because a couple of months back I realized that I actually completed five years with open source, primarily with design. This talk is mostly about what was my experience as a person who didn't know how to write code, as a person who just knew how to design a couple of few things. When I say I don't know how to write code, I say I didn't even know how to write proper semantic HTML. So I started from there, and it's been five years. This talk is about the behind the scenes of how I picked up. Who am I? I'm Raghu Nayir. I am currently a master's student in interaction design. I am a huge open source fan. I was working on open source software before GitHub happened. There were things which were on Gatorious, so I've seen the transition happen from Gatorious to GitHub. GitHub to GitHub to GitHub, all sorts of things. Yes, a couple of things. I mean, it's story time. Five years back when I was starting out in design, there was a couple of things which happened to me which were so awesome which if I think look back and I think about it, I won't have started with open source design if they didn't happen with me. So this talk is mostly about that part and my learnings from those things and what to avoid and what not to avoid. First thing, yes, if you're working on an open source community, be welcoming. Now by being welcoming, I don't say say hi, reply back to emails, you know. Small talk, chat, chat, no, by being welcoming, I mean, do contributors maintain the spirit of the project? It's important. I mean, you got to be welcoming for them. You got to document your contribution guidelines. Contribution guidelines may include or should actually include getting started, should actually include the code of conduct, style guide maybe, but you know, even if a project is small, having these small, small, small things, either one of them or all of them makes the project extremely welcoming for a person who's kind of shy, doesn't like to write emails to people and is just looking out for the right thing. It worked out for me because this is something which happened. Using Viki effectively, Viki, GitHub gives us an awesome option of adding Viki pages, which is kind of underused for a lot of open source projects, kind of overused for a lot of good open source projects and I kind of loved that. So using Viki effectively made it super simple for new people coming in. Using tags. Now tags, GitHub issue tracker has a feature called tagging. Everyone probably here knows that. Now, my tags, I see a lot of repositories use tags like UX, design, starter jobs. For me, my personal favorite was back in the day when I came across this. This primarily changed my outlook towards open source design and was the biggest factor how I got hooked into open source design. Junior jobs plus design. Junior jobs can be developers. Junior jobs can be for designers. Junior jobs can be for content people. Junior jobs can be for everyone. So you've got to subcategorize your junior jobs. Not just use junior jobs. Subcategorize them to smaller, smaller, even smaller categories so that the right person reaches the right place. This is the easiest way to get people on board when you're doing open source design. Onboarding. Onboarding was important. Now by onboarding, I mean software onboarding. So five years back, or maybe three years back, or maybe even yesterday, when I'm looking at a new open source project, and I really, really want to feel like, I want to contribute to this. I mean, this is awesome, and I would like to contribute to it. Something like this happens with me. I've got to run some commands. I'm not a badass programmer, so I'm just talking like a designer right now. You've got to start the node service. Yeah, you've got to compile your CSS, JavaScript. And yeah, by the time it happens, I'm like, oh no, man, this is some error comes up, and I just give up on it. This is the easiest way to get a person who's not a developer off-board from your project even before he has started. This happened with me with a lot of projects. This didn't happen with me a lot of projects as well, so which is a big thumbs up. So reducing installation steps. The biggest example, the first thing which came to my mind when I was talking about reduction in installation steps, and which everyone should need to learn from, is actually the WordPress 500 install. I don't need to touch the code base. I mean, it's simple. Even the language, the content, everything is simple. It's translated. It's like, you can do this in any language. I mean, you can think of. I know it's a big community, but it's a simple install. It's like, it's worth the effort. I think this is something which has not changed in WordPress since like, ever. No, like, yes, one thing. So two years back when I was working with open source software, something which happened to me, and I came across this term called design objectivity. This is something which I use almost on a daily basis. Now this is like a kind of a debated topic. Design objectivity in other terms is also called as pixel fucking. Now, yesterday, I mean, I was preparing a slide. I was looking out for, you know, good definitions of what pixel fucking means. It took me a while, but I kind of found this which was almost there. This is like a someone in pixel fuck space, more attention to things like grain than the world effectiveness was shot. It was not coded by Albert Einstein. It is from the urban dictionary. So, yes, basically what happens in open source community and design being subjective, everyone wants to be the designer. There are discussions, there are discussions which are very long. And what happens in these discussions, the best design solutions are kind of lost in the middle because everyone wants to put on their thoughts. And every thought is kind of different from the other. Good or bad, it can be good, it can be bad, but it gets different. So dealing with design objectivity is actually a very important, very, very important issue right now. I had this discussion with a colleague of mine as well a couple of days back. We discussed like the way we did it, I mean the way the community I currently contribute to next lab does it, is pretty awesome. So in case I'm absent and two people who have been contributing around say yes, this works, we lock it down. We do not take further ideas. We take ideas, we won't take ideas for V1, we take ideas for V2. So that's the easiest way to get a V1 out. And that's the point, I mean getting a result is more important having a discussion, having a super, super long discussion. The other way to fix it is defining a design language. Now design language can be a visual style guide, notice I'm playing out CSS here because CSS guidelines are like classes and all, no I'm talking about design here. Or it can be a wiki of design thoughts. It doesn't have to be, you know, your button should have this much border radius. No, if I have a certain sense of UX and what I'm looking out for, what my language sense is in the project, if you're enough to say that, it's kind of, you're almost there, you're getting there to find a design language. It's okay, it's fine. This is something which can also help out in reducing pixel fuckingness or design objectivity in your projects. The other thing which comes to me is like feature request. So I maintain, I maintain, I call maintain a repository which is a calendar application on top of Next Cloud. And we get a, we get a fuckload of feature request, like every day like probably five or something, you know, but there's a time and I'm busy, I'm like a student, like my other co-managers are also a student. So how do we deal with so many of them? It's a simple logic. We implement relevant requests and not all of them, unless all of them are relevant. It's very mad, I told you. So, good feature requests are to pull. Pulling is not, pulling is not a difficult thing to do. I mean, you don't need a forum for it. Now GitHub allows you to put a thumbs up or a thumbs down in the feature itself, in the issue itself. So if you have like people who actually request a feature, and it's like I really talked about, it actually becomes your V1. It's not my personal taste driving my design or my personal taste driving my features. It's the community which is driving my features. It's like if the community really wants it, there'll be a lot of people actually going out and going for it, you know. If there's a bug which is like annoying a lot of users, a lot of users will be, you know, putting their thumbs up on it. So this is like a great, great, great way to figure out how, or which features or which bug fixes to fix, to fix. Design thinking. Design thinking is actually one of the most neglected topics. Sorry, I'm sorry, but that's how it is. It's like we are engineers and it's very, very engineering driven. Now even I am turned out to be more of an engineer than a designer, sadly. Yes, it's engineering driven. It's still, still lacks. We are here already. We are here earlier, but we got to reach here. That's the difference we got to make. And to do that, we got to involve design since the start. Now involving design since a start can be done in a couple of ways. I know for a lot of people actually write articles on, I mean, not like articles, like essays on, you know, I say I need a feature. Let's like, I mean, I need this feature, I need this enhancement, it can be done in this way. I see a lot of people writing paragraphs about it. No, just draw a simple wireframe and put it out there. It's easily debatable. A lot of wireframes and it's scientifically proven that images are registered to your head more than text does. So that's another way of looking at it. So that's pretty much how we do it. We put out wireframes, we iterate over wireframes and we get the solution out. So involving design since the start, we'll have the perfect solution or perfect V1 at least all the time. So that's how it should be. If you over-engineer it, it's the easiest way to invest in usability. And which we see in a lot of softwares, not even just open source, even a lot of proprietary softwares, we see over-engineering when engineering is driving design, not the other way around. We see a lot of over-engineered product. We see a lot of features being implemented at the wrong place at the wrong time, which could have halted and more important features should have brought in, or design which could have been better, which could have been more usable if design was there since the start. If the design had not come in, then it was a visual stage or like halfway through the process. No, design has to be in the start. And I can like cry about it all the time, get the design in since the start. So this is basically what I realized. So as a small recap of what we talked about, yes, being welcoming, being welcoming doesn't mean writing emails. Being welcoming means contributor guidelines, style guides, keep everything there. There's a need of a lot of focus and onboarding because a lot of people leave because they could not get the software installed. I don't fuck the pixels too much, man. It's allowing to reduce so many features then. Pull-off feature requests, I mean, then you realize what's important, what's not important, and what can be done first, what can be done later on, what's not a priority. And involving design since the start, which is probably the most important thing. And I think this is one of the majority of the things we like to focus on in consortium design as well, because we are a bunch of cool designers. So yes, I am Raku, and I have time for Q&A. Any questions? I think it's super important today we will have a panel discussing how to design feedback. I think this is something that is overlooked in the community. I mean, for me, even having a panel is not like a priority. I have an eye, and luckily in all the communities I've been to, it has a very flexible panel. Like, say, for the month of October, I have three people who are contributing a lot to the project. They automatically a part of my panel. So in case I'm... Oh, okay, sure. So yeah, I mean, panel vision is super flexible, you know. Maybe I missed it, do you have an example how you develop the language, like do you have rules, like we talk about design like this? And this is the question you ask when you talk about the design. Is there something like that in the community? Can you repeat the question? So for example, you said you have to develop a language to speak about design. It's very important to ask the right question and not let people just discuss pixels and the color of the buttons. So do you usually maybe have a Viki page or you have a page where you explain how to talk about design? Do you have anything like that? We have a pretty strong getting started. At this moment, I maintain a smaller part of next-grad repositories. We follow the next-grad guidelines, and we do have a style-grader next-grad. Jan will talk about it. And yeah, I mean, it's not having a visual style guide. Even if you know the kind of content you would like to write on, even that's enough. Sign in versus login, you know. I don't want sign in to be everywhere. I would like login to be everywhere. That kind of thing, if you know the design language, that's important. Consistency is important. Content is also something we just kind of overlooked because this looks fine on this button, so let's put this on. It might just go inconsistent somewhere else. So those things are smaller, smaller things which can be taken care of. And yeah, that's it. I think what you mentioned before was touching this point where you said it's more about being pragmatic than over-discussing. So I think that's also how the design is maybe best done. Yeah. I mean, sometimes it's important to step back and say, dude, I'm doing this and it's going out for V1. Whatever discussions happen now on, it will go out for V2. I mean, otherwise design doesn't move ahead. Sometimes it's more important to rule the V1 out than to discuss way too much about V1. And the easiest way to do that is getting people to agree on one and then moving on from that rather than over-discussing it. I mean, moving on is the most difficult part about design process. You know, V1 won't be the most pixel-perfect one, but at least there's some improvement than what it was at V0. And that's more important. We talked about involving design to the start and design to the end, you know what I'm saying? But the problem I see usually in this community is projects are, as you said, basically being started by technology people. And then design may be even involved from the start. The choice of problems to work on is basically still based on technology. So, without thinking about the lab, how can we sort of turn that around and think about problems? Because that's essentially what people care about. Users don't care about the coolest library to do whatever. They care about sending a secure message to your friends. I know, sending a file, whatever. So, how could we basically not only involve you in actual development, but in starting with new projects? So, like, the choice of actual, yeah. The way I see it is every enhancement, every enhancement which changes the experience in an ideal-case scenario should come with at least a pen-drawn wireframe. I mean, you don't need to be an artist to draw boxes. And that's pretty much it for what you need for V1. It's more easier to pen-drawn your thoughts. You just draw it. I mean, you don't have to be an artist for it. Like, whatever changes your experience, think about the libraries. Think about the user experience here. You think that, okay, this button's got to go this side. It'll be a better experience than to go on the other side, you know? You got to document that part. Actually, I'm trying to say here, drawing is important. You don't have to do balsamic. Sure. I don't see how that's going to work. Yeah. I'm just talking about the choice of actual projects. Like, when you start a project in general, when you start developing something. Sure. How do you make that new experience? Like, how do we build projects with a hard-drawn experience by default? You know what I mean? So no project will be, I mean, this might be a very opinion-y thing, but no project will be default, extremely UX-friendly. By default. I mean, unless you've put a thought in the start itself. I mean, your V1, your all-visual, iterated design will be better, more UX-friendly than the previous one. Sure. Do you know what I'm saying? Sure. Maybe I'm doing a backup for you. My point is, I don't know. You have certain projects that are clearly driven by user needs, certain projects that are clearly driven by development needs. I see very few user-driven projects. There's maybe the elementary guys, but other than that, I have very few community projects that I can point to that are really driven by something that should work for average people. Okay. And something that essentially has design at its very core, in the actual inception of the project. That's true. That's the design thinking that I'm talking about. That's true. I can talk a lot about this with WordPress, with Ghost, especially Ghost, actually, which is a blogging platform, and it's a super design thinking thing since the start, because a couple of people who formed the project are actually designers. That's one really good example if you are looking for design thinking since the very, very start. Okay. In a way, I see what you mean. I mean, having one designer on board in the very start is like the way to be, at least one. That kind of thing. Thank you.
 So we will start.  We have the wrap-up talk about the UX of UX.  So yes, this is the UX of UX.  It's a pretty meta topic, but it also is, actually, the stock is very important to me  because a couple of months back I realized that I actually completed five years with open source,  primarily with design.  This talk is mostly about what was my experience as a person who didn't know how to write code,  as a person who just knew how to design a couple of few things.  When I say I don't know how to write code, I say I didn't even know how to write proper semantic HTML.  So I started from there, and it's been five years.  This talk is about the behind the scenes of how I picked up.  Who am I? I'm Raghu Nayir.  I am currently a master's student in interaction design.  I am a huge open source fan.  I was working on open source software before GitHub happened.  There were things which were on Gatorious, so I've seen the transition happen from Gatorious to GitHub.  GitHub to GitHub to GitHub, all sorts of things.  Yes, a couple of things.  I mean, it's story time.  Five years back when I was starting out in design, there was a couple of things which happened to me  which were so awesome which if I think look back and I think about it,  I won't have started with open source design if they didn't happen with me.  So this talk is mostly about that part and my learnings from those things and what to avoid and what not to avoid.  First thing, yes, if you're working on an open source community, be welcoming.  Now by being welcoming, I don't say say hi, reply back to emails, you know.  Small talk, chat, chat, no, by being welcoming, I mean, do contributors maintain the spirit of the project?  It's important. I mean, you got to be welcoming for them.  You got to document your contribution guidelines.  Contribution guidelines may include or should actually include getting started, should actually include the code of conduct,  style guide maybe, but you know, even if a project is small, having these small, small, small things,  either one of them or all of them makes the project extremely welcoming for a person who's kind of shy,  doesn't like to write emails to people and is just looking out for the right thing.  It worked out for me because this is something which happened.  Using Viki effectively, Viki, GitHub gives us an awesome option of adding Viki pages, which is kind of underused for a lot of open source projects,  kind of overused for a lot of good open source projects and I kind of loved that.  So using Viki effectively made it super simple for new people coming in.  Using tags.  Now tags, GitHub issue tracker has a feature called tagging.  Everyone probably here knows that.  Now, my tags, I see a lot of repositories use tags like UX, design, starter jobs.  For me, my personal favorite was back in the day when I came across this.  This primarily changed my outlook towards open source design and was the biggest factor how I got hooked into open source design.  Junior jobs plus design. Junior jobs can be developers.  Junior jobs can be for designers. Junior jobs can be for content people.  Junior jobs can be for everyone.  So you've got to subcategorize your junior jobs.  Not just use junior jobs.  Subcategorize them to smaller, smaller, even smaller categories so that the right person reaches the right place.  This is the easiest way to get people on board when you're doing open source design.  Onboarding.  Onboarding was important.  Now by onboarding, I mean software onboarding.  So five years back, or maybe three years back, or maybe even yesterday, when I'm looking at a new open source project,  and I really, really want to feel like, I want to contribute to this.  I mean, this is awesome, and I would like to contribute to it.  Something like this happens with me.  I've got to run some commands.  I'm not a badass programmer, so I'm just talking like a designer right now.  You've got to start the node service.  Yeah, you've got to compile your CSS, JavaScript.  And yeah, by the time it happens, I'm like, oh no, man, this is some error comes up, and I just give up on it.  This is the easiest way to get a person who's not a developer off-board from your project even before he has started.  This happened with me with a lot of projects.  This didn't happen with me a lot of projects as well, so which is a big thumbs up.  So reducing installation steps.  The biggest example, the first thing which came to my mind when I was talking about reduction in installation steps,  and which everyone should need to learn from, is actually the WordPress 500 install.  I don't need to touch the code base.  I mean, it's simple.  Even the language, the content, everything is simple.  It's translated.  It's like, you can do this in any language.  I mean, you can think of.  I know it's a big community, but it's a simple install.  It's like, it's worth the effort.  I think this is something which has not changed in WordPress since like, ever.  No, like, yes, one thing.  So two years back when I was working with open source software, something which happened to me,  and I came across this term called design objectivity.  This is something which I use almost on a daily basis.  Now this is like a kind of a debated topic.  Design objectivity in other terms is also called as pixel fucking.  Now, yesterday, I mean, I was preparing a slide.  I was looking out for, you know, good definitions of what pixel fucking means.  It took me a while, but I kind of found this which was almost there.  This is like a someone in pixel fuck space, more attention to things like grain  than the world effectiveness was shot.  It was not coded by Albert Einstein.  It is from the urban dictionary.  So, yes, basically what happens in open source community and design being subjective,  everyone wants to be the designer.  There are discussions, there are discussions which are very long.  And what happens in these discussions, the best design solutions are kind of lost in the middle  because everyone wants to put on their thoughts.  And every thought is kind of different from the other.  Good or bad, it can be good, it can be bad, but it gets different.  So dealing with design objectivity is actually a very important, very, very important issue right now.  I had this discussion with a colleague of mine as well a couple of days back.  We discussed like the way we did it, I mean the way the community I currently contribute to next lab does it,  is pretty awesome.  So in case I'm absent and two people who have been contributing around say yes, this works, we lock it down.  We do not take further ideas.  We take ideas, we won't take ideas for V1, we take ideas for V2.  So that's the easiest way to get a V1 out.  And that's the point, I mean getting a result is more important having a discussion, having a super, super long discussion.  The other way to fix it is defining a design language.  Now design language can be a visual style guide, notice I'm playing out CSS here because CSS guidelines are like classes and all,  no I'm talking about design here.  Or it can be a wiki of design thoughts.  It doesn't have to be, you know, your button should have this much border radius.  No, if I have a certain sense of UX and what I'm looking out for, what my language sense is in the project,  if you're enough to say that, it's kind of, you're almost there, you're getting there to find a design language.  It's okay, it's fine.  This is something which can also help out in reducing pixel fuckingness or design objectivity in your projects.  The other thing which comes to me is like feature request.  So I maintain, I maintain, I call maintain a repository which is a calendar application on top of Next Cloud.  And we get a, we get a fuckload of feature request, like every day like probably five or something, you know,  but there's a time and I'm busy, I'm like a student, like my other co-managers are also a student.  So how do we deal with so many of them?  It's a simple logic.  We implement relevant requests and not all of them, unless all of them are relevant.  It's very mad, I told you.  So, good feature requests are to pull.  Pulling is not, pulling is not a difficult thing to do.  I mean, you don't need a forum for it.  Now GitHub allows you to put a thumbs up or a thumbs down in the feature itself, in the issue itself.  So if you have like people who actually request a feature, and it's like I really talked about, it actually becomes your V1.  It's not my personal taste driving my design or my personal taste driving my features.  It's the community which is driving my features.  It's like if the community really wants it, there'll be a lot of people actually going out and going for it, you know.  If there's a bug which is like annoying a lot of users, a lot of users will be, you know, putting their thumbs up on it.  So this is like a great, great, great way to figure out how, or which features or which bug fixes to fix, to fix.  Design thinking.  Design thinking is actually one of the most neglected topics.  Sorry, I'm sorry, but that's how it is.  It's like we are engineers and it's very, very engineering driven.  Now even I am turned out to be more of an engineer than a designer, sadly.  Yes, it's engineering driven.  It's still, still lacks.  We are here already.  We are here earlier, but we got to reach here.  That's the difference we got to make.  And to do that, we got to involve design since the start.  Now involving design since a start can be done in a couple of ways.  I know for a lot of people actually write articles on, I mean, not like articles, like essays on, you know, I say I need a feature.  Let's like, I mean, I need this feature, I need this enhancement, it can be done in this way.  I see a lot of people writing paragraphs about it.  No, just draw a simple wireframe and put it out there.  It's easily debatable.  A lot of wireframes and it's scientifically proven that images are registered to your head more than text does.  So that's another way of looking at it.  So that's pretty much how we do it.  We put out wireframes, we iterate over wireframes and we get the solution out.  So involving design since the start, we'll have the perfect solution or perfect V1 at least all the time.  So that's how it should be.  If you over-engineer it, it's the easiest way to invest in usability.  And which we see in a lot of softwares, not even just open source, even a lot of proprietary softwares,  we see over-engineering when engineering is driving design, not the other way around.  We see a lot of over-engineered product.  We see a lot of features being implemented at the wrong place at the wrong time,  which could have halted and more important features should have brought in,  or design which could have been better, which could have been more usable if design was there since the start.  If the design had not come in, then it was a visual stage or like halfway through the process.  No, design has to be in the start.  And I can like cry about it all the time, get the design in since the start.  So this is basically what I realized.  So as a small recap of what we talked about, yes, being welcoming,  being welcoming doesn't mean writing emails.  Being welcoming means contributor guidelines, style guides, keep everything there.  There's a need of a lot of focus and onboarding because a lot of people leave because they could not get the software installed.  I don't fuck the pixels too much, man. It's allowing to reduce so many features then.  Pull-off feature requests, I mean, then you realize what's important, what's not important,  and what can be done first, what can be done later on, what's not a priority.  And involving design since the start, which is probably the most important thing.  And I think this is one of the majority of the things we like to focus on in consortium design as well,  because we are a bunch of cool designers.  So yes, I am Raku, and I have time for Q&A.  Any questions?  I think it's super important today we will have a panel discussing how to design feedback.  I think this is something that is overlooked in the community.  I mean, for me, even having a panel is not like a priority.  I have an eye, and luckily in all the communities I've been to, it has a very flexible panel.  Like, say, for the month of October, I have three people who are contributing a lot to the project.  They automatically a part of my panel.  So in case I'm...  Oh, okay, sure.  So yeah, I mean, panel vision is super flexible, you know.  Maybe I missed it, do you have an example how you develop the language, like do you have rules, like we talk about design like this?  And this is the question you ask when you talk about the design.  Is there something like that in the community?  Can you repeat the question?  So for example, you said you have to develop a language to speak about design.  It's very important to ask the right question and not let people just discuss pixels and the color of the buttons.  So do you usually maybe have a Viki page or you have a page where you explain how to talk about design?  Do you have anything like that?  We have a pretty strong getting started.  At this moment, I maintain a smaller part of next-grad repositories.  We follow the next-grad guidelines, and we do have a style-grader next-grad.  Jan will talk about it.  And yeah, I mean, it's not having a visual style guide.  Even if you know the kind of content you would like to write on, even that's enough.  Sign in versus login, you know.  I don't want sign in to be everywhere.  I would like login to be everywhere.  That kind of thing, if you know the design language, that's important.  Consistency is important.  Content is also something we just kind of overlooked because this looks fine on this button, so let's put this on.  It might just go inconsistent somewhere else.  So those things are smaller, smaller things which can be taken care of.  And yeah, that's it.  I think what you mentioned before was touching this point where you said it's more about being pragmatic than over-discussing.  So I think that's also how the design is maybe best done.  Yeah. I mean, sometimes it's important to step back and say, dude, I'm doing this and it's going out for V1.  Whatever discussions happen now on, it will go out for V2.  I mean, otherwise design doesn't move ahead.  Sometimes it's more important to rule the V1 out than to discuss way too much about V1.  And the easiest way to do that is getting people to agree on one and then moving on from that rather than over-discussing it.  I mean, moving on is the most difficult part about design process.  You know, V1 won't be the most pixel-perfect one, but at least there's some improvement than what it was at V0.  And that's more important.  We talked about involving design to the start and design to the end, you know what I'm saying?  But the problem I see usually in this community is projects are, as you said, basically being started by technology people.  And then design may be even involved from the start.  The choice of problems to work on is basically still based on technology.  So, without thinking about the lab, how can we sort of turn that around and think about problems?  Because that's essentially what people care about.  Users don't care about the coolest library to do whatever.  They care about sending a secure message to your friends.  I know, sending a file, whatever.  So, how could we basically not only involve you in actual development, but in starting with new projects?  So, like, the choice of actual, yeah.  The way I see it is every enhancement, every enhancement which changes the experience in an ideal-case scenario  should come with at least a pen-drawn wireframe.  I mean, you don't need to be an artist to draw boxes.  And that's pretty much it for what you need for V1.  It's more easier to pen-drawn your thoughts.  You just draw it. I mean, you don't have to be an artist for it.  Like, whatever changes your experience, think about the libraries.  Think about the user experience here.  You think that, okay, this button's got to go this side.  It'll be a better experience than to go on the other side, you know?  You got to document that part.  Actually, I'm trying to say here, drawing is important.  You don't have to do balsamic.  Sure. I don't see how that's going to work.  Yeah.  I'm just talking about the choice of actual projects.  Like, when you start a project in general, when you start developing something.  Sure.  How do you make that new experience?  Like, how do we build projects with a hard-drawn experience by default?  You know what I mean?  So no project will be, I mean, this might be a very opinion-y thing,  but no project will be default, extremely UX-friendly.  By default.  I mean, unless you've put a thought in the start itself.  I mean, your V1, your all-visual, iterated design  will be better, more UX-friendly than the previous one.  Sure.  Do you know what I'm saying?  Sure. Maybe I'm doing a backup for you.  My point is, I don't know.  You have certain projects that are clearly driven by user needs,  certain projects that are clearly driven by development needs.  I see very few user-driven projects.  There's maybe the elementary guys,  but other than that, I have very few community projects that I can point to  that are really driven by something that should work for average people.  Okay.  And something that essentially has design at its very core,  in the actual inception of the project.  That's true.  That's the design thinking that I'm talking about.  That's true.  I can talk a lot about this with WordPress, with Ghost,  especially Ghost, actually, which is a blogging platform,  and it's a super design thinking thing since the start,  because a couple of people who formed the project are actually designers.  That's one really good example if you are looking for design thinking since the very, very start.  Okay. In a way, I see what you mean.  I mean, having one designer on board in the very start is like the way to be,  at least one.  That kind of thing.  Thank you.
Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_0_131.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_132_2183.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_2184_2927.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_2928_6023.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_6024_6923.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_6924_10355.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_10356_11759.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_11760_13475.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_13476_13643.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_13644_14855.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_14856_16439.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_16440_17027.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_17028_17411.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_17412_19715.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_19716_23423.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_23424_23555.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_23556_23807.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_23808_26375.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_26376_27143.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_27144_27527.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_27528_28415.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_28416_28547.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_28548_28679.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_28680_29447.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_29448_30455.png Designing_in_the_open__The_UX_of_UX_How_does_this_thing_called_open_source_design_w_30456_30573.png