GitHub GitHub Satellite India 2021 - Open Source: Day 2, 28 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub Satellite India 2021 - State of UI/UX in open source

Description

Presented by Pranav Raj, Co-Founder @ Chatwoot

Open source projects generally do not care about UI/UX patterns, and it is rare to find any discussion or contribution about design. One reason for why this might be the case is that the projects do not have a framework to accept design changes. In this talk, Pranav Raj will cover how to adopt a design language and create an environment for designers and UI developers to contribute. He'll also showcase successful companies who have made UI/UX a priority—and offer tips for how to promote design discussions and contributions for your own projects.

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

Hi everyone, my name is pranav, I'm the ceo of chatfoot.

A

Today I'm going to talk about the state of uiux in open source projects, how you can drive design discussions and how you can actually promote a design first culture.

A

But before going into that, let me introduce myself, as I mentioned like you know, I'm working on an open source project uh called chatwood. I've been contributing to open source for about seven years now I started in 2014 uh through github. Like you know, sales years was my first contribution uh from there. It's been an amazing journey from an open source contributor to now to a open source, uh maintainer, uh so yeah and a little bit about chatwood. uh We are building an open source customer engagement, suite built as an alternative to intercom and zendesk.

A

We started in 2016, we started out as a proprietary software, but it didn't work out. Well, so after seeing the data privacy regulations, uh people moving on to you know self-hosted alternatives, we thought why don't we give us this a try and we oppose the project and, to our surprise, it got trending in hacker news and from there like you know, we have been working for more than a year uh to build features and right now, like you, know, we're building business out of it.

A

uh So go check out, uh chat, food on github and uh let us know uh your feedbacks. We are open to contributions. We're open to discussions, yeah feel free to do it.

A

uh So before we jump into the uh actual topic, let me discuss about the two different aspects like developer experience and product experience, uh so as an open source projects. It's it's really important for you to uh you know, concentrate on the developer experience because, like you know uh it really matters.

A

uh How, like you know how it is easy to install the software or how hard uh is it to maintain, or maybe, like you know, when there is a new version of the software? How hard is it to upgrade these all things? Actually matters uh in your adoption. So if you want to have better uh adoption, uh you would have to make all these things simpler, uh but, like you know, there is other aspect as well.

A

Like you know the product experience uh so uh like you know how you use the product, how where it actually solves the problem. So today I'm I'm going to talk about products, experience not about the developer experience uh so yeah, I think, like you know, a design in open source projects is actually pretty debated topic because, like you know most of the uh projects don't follow as standards or most of them. Actually, uh you know don't have a guideline on how to contribute on design.

A

uh So, like you know, the the one of the reasons which we see uh for that is because, like you know, design and development are two independent processes um for designing a better user experience. There needs a group of people with different set of skills, working together uh towards a single goal. uh I mean, like you, know their needs. There needs to be. uh You need to have like you know, designers, you need to have developers who can implement the design and they need to have like communicate between these.

A

Like this should be a proper communication between these two and this is not happening in the open source projects, so one of the things which I've understood from my experience, working with designers in my previous jobs- is that, like you know, most of them are problem solvers, so they try to identify. What exactly is the problem? They try to understand how uh this problem is affecting the end customers and then from there, like you know, they work backwards, to identify what's the right solution and build a user experience around that.

A

This is not happening uh anywhere in, like you know any of the open source projects, because one of the problem with that is, like you know, most of the uh designers who's new to the open source project might not have context about what people are asking, so they need to set it up.

A

They need to, like you know, understand the product better it it takes a little bit of time uh to for them to actually do that, and uh second thing is actually like you know uh the I mean, like you know, most of the open source products, as we know like you know, starts with one single developer who uh who had a problem so they like uh they wanted to, like you, know, put them thought and then build a small hack or, like you know, a small product which solves their problem and then like uh they think like okay.

A

This is useful to me, so why can't I open source it so they open source the product and afterwards, like you, know, people uh like people see the product and then from there like you know, they start adding more and more features to cater large set of uh uses.

A

uh So one of the typical problems uh which comes to the projects is that, like you know, since it's not built for a larger audience, uh I mean like they tend to have uh like you know, ux. That incurred due to various reasons. One is actually like.

A

You know most people who would ask you, like you know why don't you do x to do y or, like you know, why, don't you add an option to do something so as a as a maintainer, you want an option as a maintainer, you want more people to be using your product, so the immediate thought or, like you know the immediate uh uh uh understanding, for you would be uh to create uh an option for them like you know, so that, like you know they can use the product, and this keeps on adding like there will be like you know, a lot of features that will be like, like you know, there'll, be a lot of options which you provide.

A

So I, like you know it. It gathers every set of people and the end result for that would be something like this. Like you know you, you would have a smaller system with a lot of function, options with a lot of controls which might not be relevant to most of the uses. So one one one problem with this is actually like you know. Most people would have uh uh don't won't understand, like you know why these many options are provided or, like.

A

You know why this uh like this elaborate set of like in options this is given in the in the product, so it it's kind of a learning curve for them. Like you know, it's, it's not a good ux.

A

So if, if you're not doing something complex, if you're not doing something uh like you know like the one which we see in this image, uh so like try to minimize that and like you know, it's really important to understand that you don't have to provide every option which every customer or, like you know, every developer is asking you on github.

A

You can always say that like why? Don't you just swap the project and then make make option by yourself so that you can use it? So it doesn't make sense for you to add every set of features, every set of options which people are requesting. So every time you uh you get a request that, like you know, add a functionality.

A

Add uh an option to uh to do this. Just think about whether this is going to create a ux debt or whether it's going to create more and more problem on on on our end, then like then, after that, like you know, if you think this is going to be a problem, this is not going to be a useful feature for a lot of people who are using your product. Then um don't do it like the code like this, and you can do it yourself.

A

So this happens to me all the time in chat wood, because most people, like you know we have a broader product like with a lot of options, a lot of customizations available. uh So people would come to say that I come and say that you know I want this kind of thing for this use case and yeah like as a developer, uh the maintainer of the project. I my immediate reaction is like oh yeah.

A

I think I can provide that, but uh most of the time, like you know, I take a step back like talk to uh the people who are working on the project like understand whether this is something that's relevant for the larger uh set of people. uh Then, if it's not, then we would defer that or maybe ask the person to actually you know build it themselves, because it's open source right, like you know, you cannot build it themselves because it's open source right, like you know you can uh you can build it out yourself.

A

You can uh like you, can change the code, which is uh which is one of those things which you would want to do if it is not possible to uh remove that option. Let's say, like you know, you have, uh even though, like you know, even if you have like uh two options with two uh like two two type of different options with two: uh yes or no answers there, you have like four possibilities.

A

Think about, like you know, 20 different options with, like you know, uh 20 different, like uh yes or no questions like, and there will be like a lot of options. There will be a lot of combinations which you have to provide so most of the times, don't add the future right away.

A

Just like you know think about whether you can ask the person to say that, like you know whether they can build it themselves, if it is not possible, if you think that this is something which is going to be useful for a larger set of uses and still you would have to provide a standard default right.

A

So if you look at like zoom as an example, uh so the the way we are uh entering a meeting- it's just one click, but if you want to customize uh a specific thing like the way it's being recorded or, like you know the uh like the video quality or like the audio quality, it's all there, but it's it all have like it.

A

The all those options have a standard default so that, like you know, a new user comes in or the person who wants to try out the product has a very simple uh step to do that, like you know, install the software, just click on, uh like you know, login and then click on start a meeting. Then you have that particular uh you know meeting opened right, so you have to pro.

A

You have to think like that, where you, you have to provide a standard default for all the options which you provide so that, like you know, whenever a person comes in like it's, it's very easy to get started with the project and try to use the project. So we we do this at chat road a lot. uh We have a standard defaults for most of the uh cases which we recover, even though, like you know, there is a customizability option. We prefer to have a standard default for all options which we provide.

A

Second problem here is actually this lack of standardization of design, uh so all right, so the all the design, all the open source projects, like you know, if you look at them, it's it's mostly like, as I mentioned like you, know, a developer working on it and from there like building features out of it. So uh there is a lack of like you know, design uh design. First thinking uh what I mean by that is uh like.

A

If you look at uh any of the uh like web projects out there, it's like you know there will be 10 different types of buttons. You can see or 10 different spacing you can see, or maybe, like you know, you can even see people writing uh styles in line. So one of the problems with that is, like you know, as a designer. If somebody comes to your project and even like there are different barriers for them to actually like, you know, try and use the product. Even then, like you know, if they did all those.

A

The first thing which they are going to see is like you know, the the design itself is like not standardized or maybe, like you know, don't have a guideline which is written anywhere, so their first uh thought process would be like you know. Why don't I contribute to this?

A

Why don't I contribute to uh the base design like make it better, but often it ends up like you know, changing a lot of variables, which uh might not be the right thing for uh the developer because like and it's a lot of for work for them to uh change all this and like make it standardize and they would end up, like you know, rejecting uh the proposal which, which might be like frustrating for the designer. So uh before you start like you know, think about how you can uh standardize the the uh like.

A

You know the options which you take like you know. One of the easiest examples is to take uh uh one of the frameworks, like you know, tailwind or a bootstrap or foundation like you know, take that as an example.

A

Take that as a base uh style guide for you and then from there build on top of that, make the uh colors, uh with with respect to your brand, make make uh spacing with based on based on what you require and use the standard colors or spacing or like you know, whatever is whatever you are using inside.

A

Your project, like you, know, make it a standard, put it somewhere in a common place, so that everyone who like who is interacting with the product knows that, like you know, this is the place, I can go and look at uh what is the standard being set? So uh this is what is called like.

A

You know: design force culture, like you know, whenever a new person comes in or, like you know, whenever a new, uh a new kind of like designer who wants to install or like you know, use the software, it is easier for them to see. What's already there, like, you know it's, it makes it less complex for them to understand what are the standards that that are being set.

A

So we, when we started chat root uh we were thinking about, like you know how we can, uh how we can like adopt this system, like you know how we can adopt a design system, or maybe, like you know, adopted a sign language so that it's easier for us to communicate with uh other people. So we started searching for the options it was in. 2016 design system was a smaller thing, but, like there was a good guide written by marvel at that point, so we started from there.

A

Like you know, we took their uh design system as an example and from there we built our own standards. Like you know, we have our own typography.

A

We have our own phones, we have our own spacing or, like you know, even colors like can we customize all those things but like the base idea or like the base layout was taken from other examples, so you right now they all of the uh companies are like all of the products which is out there who have, who have certain set of guidelines would follow some kind of design system and, to be honest, like you know, I wouldn't I wouldn't recommend anyone to just like follow bootstrap because, like you know, it gets worse when, like you, have a lot of components and there is no way to actually like you know, um make a standard or like there is no way to for you to uh build a standard just by bootstrap.

A

So it's more about, like you know, the the culture which you building, like you know, think about standards. Think about, like you know, our design system, how you can adopt it like go check out like different options um like primer or primer, is actually like.

A

You know the design system for github um and you can actually go to refactoring ui, which is a great book which you should follow uh uh which, like you know, even if you are a developer or if you, even if you are someone who don't have who have not worked much in design. That would actually help you uh to understand, like you know like it, would help you to get started and understand how things work uh so and second, and and like, and one of the options which you can do is actually like.

A

You know document the design choices. What colors you choose? What's? uh What are the components which is available in your projects, like you know how? What are the different type of options available so that whenever you, whenever a new person comes in, you can define a process on how they can contribute to the project?

A

Right, like you know, you already have all these things documented and we started this with styleguide.chatfoot.com, so we started our experiments with that and right now, like you know, we are writing a guide so that our new person, who's interested in design, can, like you know, look at how we are dealing with the design and then from there like you know they can contribute, or maybe uh just take, inspiration from so and the third problem which most of the people face who are designer.

A

Is they don't know how like how they can contribute where they can, where they can contribute and what they can contribute. So the first thing is actually like: you know where they can contribute. There is definitely a lack of understanding or awareness about tooling. So github, as you say, like you know, or even open source projects is mostly about code. uh The the the amount of people like you know.

A

The amount of people involving in open source projects who are designers is very less so, and there is a separate movement called open, source, design and stuff like that, but uh the the core or, like you know, the most of the people who are working in open source would uh who are not designers and for designers. Like you know, it's it's a big barrier for them to uh understand how github works or, like you know, or any other, a git or svn or any other tools which you use.

A

uh That's first thing, and there is no there's no like a way around it like no. They have to learn. It second is actually like you know, even even if they come to, they understand github and they come to your project.

A

They don't know what to contribute. Right like there will be a set of issues which might be highly technical, which is not really uh really good to understand. So you have to define an issue which describes what is the expectation here? What are the kind of things which you would want to build and, like you know, what can we contribute or like? What can external people contribute to that particular issue?

A

Most of the times like, if you go to any of the open source projects it'll be like you know, there'll be a log and then okay. This is not working for me, and this is why this is happening so easy. There is no easy way to filter out these kind of issues just to make sure that, like you know, I have a design problem which, like you know you can solve. There is no there's no easy way to do that.

A

So, like one of the things which you want to do is like you know, define a process on how you can contribute to design. So first thing is to write down the expectations, have a proper uh product spec. So let's say you're building a teams feature write down a product, spec understand what uh what this feature means to. You then create different types of options which is available like or different use cases which you can solve and from there label the issues right, like you know, if you have the product spec complete.

A

Next, you want is a high level design. Maybe people can contribute like you know it can be, uh it can be about civic mockup or it can be a figma design. It can be anything like you know, just to contribute to the design label the issues correctly so that people can find it. So first thing you you want to do is, like you know, label them properly, with design wanted or something of that sort- and third, is actually like you know, have a clear honor of the issue and define how you how you resolve conflicts.

A

So, most most often like you know, if there are two people who are working, who saw the issue who wanted to contribute something, then they comes with two different approaches.

A

There is a conflict and you have to define very clearly upfront that, like you know, this is the person who is owning this issue or like this is how this issue would be resolved. If there are a conflicting opinion and from there uh you have to define that process as well. Like you know, the understand like tell like write down in that particular issue that, like you know this is how we accept contributions to this particular issue.

A

uh Say you want to have these these many things and it should not uh follow these many things and it should follow your actual design contributions.

A

So, like you know, having that clear ownership and having that conflict or solution, written inside uh issues is clearly important and I think like I can give an example of metabase, uh so they, uh if you, if you look at their like contribution guidelines, there is an option called. There is a section where they define design the feature uh and in this like, even though it's it's clearly it might, it might be, like you know, their internal team working on it.

A

Like you know, it's very clear that these set of issues which are tagged with design needed is specifically for designs.

A

It's the ux is complete or like the uh the feature is actually uh understood, like a feature is already written very clearly, you have to understand how, uh like there is a clear description of how the functionality would work, and the next thing you want to do is, like you know, create a design for that, so people can just go there, filter out the label uh design needed then from there like you know they can contribute, or maybe, like you know, they can provide suggestions which is not there in most of the problem most of the projects and the other way you can approach.

A

This is actually by you know, having a process for design. Let's say, like you know, you have a set of components which is desired, which is designed and you have a style guide written for it, so you can either say uh if, if the contribution, if like you know, if, if you want to do something new in design, just go to the content, like you know, the style guide library see if the component is all already there.

A

If it is there, then you can actually see whether uh you need to make any changes or if, if, if it is already like, you know it already covers everything, then you can just right away use that if it's not present, if the component is not present, then you can propose a new component design and if the component, like you know you can have, you can define all the steps like that.

A

So that, like you know there is a written rule or like you know, there is a process which is defined on how you accept design related contributions, which makes it easier for people to contribute as well. Right, like you know, you go to a project, you understand, this is how you can contribute, and then you can jump right in and then contribute so uh primer like, as I mentioned, github's uh uh style guide is actually like.

A

You know they have well written document on contributing and maybe like you know, you can actually explore other of those projects or other uh companies, guidelines which gives you much better decisions and the last part of it is actually like. You know we covered why this is happening, how this is happening and what are the different things which you can do to improve design contributions?

A

Now, I'd like to talk about uh how to drive design discussions uh driving design discussions is uh double-edged sword uh to be honest, like you know you, you either get a lot of good responses or you either get a lot of very bad responses, and there is no uh way to like you know get around on that. So you have to understand. Like you know, whenever you start design discussions, it can get very.

A

Over some kind of very minor, colors or, like you know, some spacing, but it like there is actually a way to uh way to provide design discussion. First of all, the thing is actually like. You know whenever you write a feature with the mock-ups right inside the issue.

A

Just take a screenshot put that in the issue, so that, like you know, when people come to your your github, go to issues, click on one of the feature description like you know, they see how this is going to be uh in, like you know, whenever, when the com feature is completed, right like at that point, they might have some options.

A

So this is one of the things which we did from very early on, so that, like you know, whenever we have a design whenever we have a new feature which is going to be build, we build the designs or build the modes in in figma from there, like you, take a screenshot and put that on the github issue, and this drove a lot of uh comments and like in a lot of discussions based on very particular things for, for example, very particular on this.

A

One was like you know, one of the things we which people suggested was to provide an option for them uh instead of, like you know, instead of like having a text area to add this consent, uh they want to have a standardized concept like you know, maybe just they can just change the variables or like their company name. They can just use the user right away.

A

Second thing: people wanted was to add options for terms and conditions or, like you know, privacy policy, which makes sense because at all like you know, we are, we are saying, like you know, you are accepting this and then you want to have all the links together and then that kind of things like you know, drove discussions in us.

A

So maybe you can experiment with like you, don't have to have a design like this, you can just use uh balsamiq or maybe anything like or even like paper written mocks, which which can actually drive discussion so driving design discussions might not really involve uh designers, it involves people who are actually using the product. So if you are building something out there, you want to have a better understanding. How people think about the feature you don't have to do user research in github because, like you know, your project is open source.

A

You can leverage that, as your starting point create a feature uh if you request and then from there like, you know, put the design ask for contributions and there just explain very clearly what you're looking for and what kind of feedback you're looking for instead of like. If you put something like this without that that direction, what happens is like you know, people say that okay, this uh text or font size is very small or maybe like you know, I want to have the heading bet larger.

A

Instead of that, give them clear direction on, like you know what you're looking for as a feedback, and if there is someone who was willing would provide that feedback. So yeah, I think, like you know, that's all that's all I had for today. So basically, like you know, I define a process understand that you need to standardize at some point. So why don't you start at the beginning itself, like you know, standardize your components, standardize your uh your uh design system, so that, like you know, people can just look at uh the designs and understand?

A

Okay, this is what this guy is actually doing from there. If you have like standardized design, if you have like a process which is involved in uh design contributions, you can actually have a third thing where, like you, uh you just like ask for general public for feedback on specific options which would drive more and more design discussions.

A

So yeah. I think that's all we had uh for today. So I I was doing this experimenting this for a long time in chat. Would some of it works? Some of it doesn't work uh but yeah, I'm really happy to talk to you. If you want to, like you know, understand how uh I see about this. Maybe, like you know you can reach out to me on twitter or or my email as I shared before then yeah. I think, like you know, that's that's pretty much it thanks for taking time to watch this talk, bye.