WEBVTT 00:00.000 --> 00:06.000 Our second is the last talk. 00:06.000 --> 00:07.000 Yeah. 00:07.000 --> 00:08.000 All right. 00:08.000 --> 00:09.000 Thank you. 00:09.000 --> 00:10.000 Cushicard. 00:10.000 --> 00:15.000 Thank you so much. 00:15.000 --> 00:18.000 Hello, everyone. 00:18.000 --> 00:24.000 So I asked someone who has transitioned from being a engineer, 00:24.000 --> 00:27.000 being a developer to a designer. 00:27.000 --> 00:34.000 I felt I realized that designers and engineers can collaborate in a better way. 00:34.000 --> 00:36.000 And that is what I'm going to talk about today. 00:36.000 --> 00:40.000 So currently I'm a product designer at Red Hat. 00:40.000 --> 00:48.000 And in the past I have interned with outreach, which was my first open source and design thing. 00:48.000 --> 00:52.000 So outreach usually does not have a lot of design projects. 00:52.000 --> 00:59.000 And I was able to find one of those applied to one and intern with them for a design project. 00:59.000 --> 01:06.000 And that is when I realized that open source in general does not see a lot of design contributions. 01:06.000 --> 01:10.000 And I delved into open source as a designer. 01:10.000 --> 01:21.000 So I started by addressing this misconception that engineers in general think that designers only focus on making things pretty. 01:21.000 --> 01:26.000 And designers feel that engineers are only just about functionality. 01:26.000 --> 01:33.000 And that they don't value or value UX as much or that they ignore UI and UX. 01:33.000 --> 01:37.000 So I have a lot of developer friends, right? 01:37.000 --> 01:42.000 Since I come from a BTEC degree, like a computer science degree. 01:42.000 --> 01:48.000 So it is kind of like a running joke between us that designers don't care about us. 01:48.000 --> 01:52.000 They give us such complicated designs, animations and whatnot. 01:52.000 --> 02:01.000 And we are not able to develop them or it is like it is a headache to develop the designs that we get. 02:01.000 --> 02:07.000 But at the end, the shared goal is usability and great UX for our users. 02:07.000 --> 02:14.000 And so again, we need to accept that better collaboration will lead to better solutions. 02:15.000 --> 02:21.000 So I would start with how designers can support engineers. 02:21.000 --> 02:24.000 First point, speak like an engineer. 02:24.000 --> 02:30.000 So learning basic technical concepts related to your product can be really helpful. 02:30.000 --> 02:36.000 So for example, you are working on a product that fetches data from a third party app. 02:36.000 --> 02:45.000 So if you as a designer understand how an API works or how this particular API fetches data or how often it does that, 02:45.000 --> 02:51.000 you would have better context and better constraints to design better. 02:51.000 --> 02:57.000 And you would be able to communicate much more effectively with your engineers. 02:57.000 --> 03:07.000 So you can start by asking questions in meetings, reading tutorials, reading documentation about the product or technologies that it is using. 03:07.000 --> 03:15.000 And eventually you will feel much more confident and equipped to talk with your engineers. 03:15.000 --> 03:20.000 Second would be to consider your engineers as your design partners. 03:21.000 --> 03:26.000 Do not design alone, designing is not a solo job. 03:26.000 --> 03:34.000 Try to involve engineers as early on as possible because it can save you a lot of time and effort. 03:34.000 --> 03:48.000 So your engineers can help you identify technical challenges, constraints and help you save time by identifying the technical challenges. 03:48.000 --> 03:56.000 So you can start by sharing wire frames, sketches and gathering their feedback quite early on. 03:56.000 --> 04:00.000 Designing for feasibility and scalability. 04:00.000 --> 04:10.000 Your design should not only look great, but you should make sure that it is easy to build and scale as a product grows. 04:10.000 --> 04:15.000 So let's say your product currently has two features. 04:15.000 --> 04:23.000 But what happens when the product team decides to add five new features next quarter is your design going to break. 04:23.000 --> 04:26.000 Is it going to be too overwhelming for the users? 04:26.000 --> 04:37.000 So try to discuss this early on with the product team as well and try to keep all of this in mind while you are designing and try to make your product. 04:37.000 --> 04:41.000 Make your design as scalable as possible. 04:41.000 --> 04:43.000 Good documentation. 04:43.000 --> 04:51.000 I think pretty self-explanatory, but good documentation can save you as and as of back and forth. 04:51.000 --> 04:56.000 Try to annotate your designs if possible. 04:56.000 --> 05:05.000 There's option in Figma to do that and understand that if something is missing in your design your developers will have to guess. 05:05.000 --> 05:08.000 And that is where mistakes happen. 05:08.000 --> 05:18.000 So you can try to document all the scenarios like loading states, error handling and success messages. 05:18.000 --> 05:21.000 Last point would be to advocate for your engineers. 05:21.000 --> 05:27.000 So it is our typical scene that the product team is all pumped up. 05:27.000 --> 05:30.000 We as designers have great designs. 05:30.000 --> 05:36.000 We are excited for them, but more often than not engineering resources are limited. 05:36.000 --> 05:41.000 The lines are always tight and not everything can be built right now. 05:41.000 --> 05:51.000 So don't just push for your wish or your vision and try to understand and sorry. 05:57.000 --> 06:06.000 So don't just push for your wish and your vision. 06:06.000 --> 06:13.000 Try to understand the technical limitations of your engineers as well and try to partner with them. 06:13.000 --> 06:19.000 Value the experience as well and be willing to just work together as our team. 06:19.000 --> 06:25.000 So that was part one of my talk that how can designers support engineers. 06:25.000 --> 06:29.000 Now we would talk about the other side of the coin. 06:29.000 --> 06:35.000 How can engineers support us as designers? 06:35.000 --> 06:44.000 So similar to what I said about designers, engineers can understand design principles. 06:44.000 --> 06:51.000 So knowing basic design principles will help you align better with your designers and appreciate their design. 06:51.000 --> 07:01.000 So you can start with learning about basic key concepts of design like hierarchy, contrast, typography, white space etc. 07:01.000 --> 07:14.000 And I feel when engineers also understand design language, it becomes a much more smooth process with unnecessary debates or miscommunication. 07:14.000 --> 07:18.000 So that could be a great starting point for engineers. 07:18.000 --> 07:21.000 Second would be to provide feedback on feasibility. 07:21.000 --> 07:26.000 So since I said that designers should try to involve engineers early on. 07:26.000 --> 07:33.000 If your designers are trying to do that, make sure you provide them with feedback early on. 07:33.000 --> 07:43.000 And you as a engineer can guide them by sharing technical insights, by sharing advice on what is achievable, 07:43.000 --> 07:49.000 given the given constraints on tools, time, budget, etc. 07:49.000 --> 07:57.000 But make sure you still preserve the design intent without our right rejecting ideas. 07:57.000 --> 08:06.000 Try not to say that this cannot be done, but propose a similar solution that aligns with your design team as well. 08:06.000 --> 08:10.000 And the overall projects or products ideas. 08:14.000 --> 08:17.000 Get familiar with design tools. 08:17.000 --> 08:25.000 So this is something I have personally felt a lot and still struggle with. 08:25.000 --> 08:35.000 So I feel that engineers often do not realize that how useful the tools that we use are. 08:35.000 --> 08:47.000 So I've worked with engineers who treat designs like a flat image and they are not able to utilize the tool completely. 08:47.000 --> 08:54.000 So if they are treating designs like a plain image, they tend to do guesswork. 08:54.000 --> 09:01.000 So they would have to guess on spacing, what is the spacing here, what is the font like, what is the font weight. 09:01.000 --> 09:13.000 But you again as engineers you will have to realize that tools like Figma have advanced a lot and you can utilize. 09:13.000 --> 09:19.000 You can utilize these tools to make your process much more smooth. 09:19.000 --> 09:24.000 So Figma can give you details about the design. 09:24.000 --> 09:32.000 You can directly check all the spacing, font weights, colors, everything on the tool itself. 09:32.000 --> 09:45.000 You can also add feedback, add questions on the design so that context is maintained and discussions are also traceable over time. 09:45.000 --> 09:53.000 And yes, a lot of design tools also allow engineers to export assets directly from the design file. 09:53.000 --> 10:03.000 So again you don't have to do a lot of back and forth with your designers to ask for assets or ask for clarifications. 10:03.000 --> 10:07.000 And I think this really speeds up the implementation process. 10:07.000 --> 10:19.000 So make sure you spend a little bit time to get familiar with the design tools and it will surely give you 10x of your time back. 10:19.000 --> 10:24.000 Next point would be to encourage design first culture. 10:24.000 --> 10:34.000 So if you are in a team where you feel that your stakeholders or the upper management does not really value design as such, 10:34.000 --> 10:47.000 make sure to highlight the importance of design to those stakeholders and advocate for involving your designers early on in the design process during the product meetings, 10:47.000 --> 10:56.000 which will also help you to align technical and creative goals from the very beginning. 10:57.000 --> 11:12.000 Advocate for accessibility as well, try to implement and write accessible code, try to write a clean code which is easily understandable for anyone accessing it after you or even if a design of it. 11:12.000 --> 11:17.000 Basic dev knowledge is accessing it, they can understand it. 11:17.000 --> 11:24.000 A test for accessibility so you can run automated tests using tools like Lighthouse. 11:24.000 --> 11:29.000 You can also manually check for keyboard navigation, contrast issues. 11:29.000 --> 11:39.000 You can check if you are developing design also supports screen readers and assistive technologies. 11:39.000 --> 11:47.000 So yes, that was all. Some key takeaways would be that design and engineering need to work hand in hand. 11:47.000 --> 11:54.000 And even small design efforts can significantly improve usability in open source in general. 11:54.000 --> 12:08.000 So this talk I feel was not directly targeted to open source design, but since there are obviously a lot of developers in the open source field and not enough designers. 12:08.000 --> 12:17.000 So if we can somehow improve the collaboration process, it would help the open source community in general. 12:17.000 --> 12:24.000 And today tools and processes exist to help engineers and designers collaborate better. 12:24.000 --> 12:30.000 So we should just make the best use out of them to help our users at the end. 12:30.000 --> 12:33.000 That was it. Thank you. 12:33.000 --> 12:42.000 Thank you. 12:42.000 --> 12:49.000 We have questions. 12:49.000 --> 12:54.000 I speak from the point of view of the engineer. 12:55.000 --> 13:01.000 For me, design has been a lot of value, but unfortunately I can collaborate with one. 13:01.000 --> 13:04.000 And so I have to do that. 13:04.000 --> 13:13.000 And I found myself using Storybook that is a weak collaborate and think in the way of the designer. 13:13.000 --> 13:18.000 And my question is, could you think about Storybook? 13:19.000 --> 13:43.000 So the question is, firstly about Storybook, and second about how developers in the open source field can collaborate with the designers. 13:43.000 --> 13:54.000 So for the first point, I have not really used Storybook a lot, but for the second point I would say that there are communities. 13:54.000 --> 13:59.000 So like starting with open source, open source design as we have it here. 13:59.000 --> 14:05.000 So I feel there are a lot of designers out there, but not enough design work also. 14:05.000 --> 14:09.000 So as you mentioned that you do most of the design work yourself. 14:09.000 --> 14:18.000 So when we as designers do not see any opportunity or any work, you know, post it out there that we need help with this. 14:18.000 --> 14:25.000 It also, it's also, it's not really for all that we are not able to contribute to it. 14:25.000 --> 14:38.000 So I would say if you could utilize platforms such as open source design, let's say, and put out a message or a issue on GitHub, let's say asking for design help. 14:38.000 --> 14:42.000 I think it could help solve that problem. 15:08.000 --> 15:31.000 So the question is that when perspective from both sides is discussed, do people tend to like switch sides basically. 15:31.000 --> 15:46.000 So I feel, I mean it's a little difficult question to answer, but from my perspective I would say that as a designer, I always try to defend like my role or my work. 15:46.000 --> 15:50.000 So as I mentioned, my experience with my friends who most of them are developers. 15:50.000 --> 16:00.000 So whenever they say something like we are not able to collaborate easily or designers are like they work in another world all together. 16:00.000 --> 16:08.000 So my perspective is that you need better processes in your work, in your company, let's say. 16:08.000 --> 16:29.000 And I think, no, no, not really, I don't think like people would switch sides, but there's always like both of the sides of the coin have valid reasons to believe what they do and we upset with the other side with what they do. 16:29.000 --> 16:42.000 They do so. 16:42.000 --> 16:50.000 Okay, so the question is that what would I like to change about designers using GitHub? 16:50.000 --> 17:06.000 So currently in my workflow, I tend to use GitHub very less, but in the past, when I've worked with open source organization during my internship, how we used to do it is based our. 17:06.000 --> 17:20.000 Now, I think it has been a discussion for quite a few like conferences that I've attended that we need a tool similar to GitHub for design. 17:20.000 --> 17:25.000 There is not enough version tracking or not enough all of that now. 17:25.000 --> 17:35.000 So a magic one if possible would be just to have a tool similar to GitHub for design and not use GitHub for design because it really does not work. 17:35.000 --> 17:38.000 Really does not work out from my experience. 17:38.000 --> 17:48.000 So how do you implement that? 17:48.000 --> 18:04.000 So you can say like engineers, we have a project for the use of designers and by Microsoft, do you like to go out to engineers and implement them and keep them with basis of design and how does that work. 18:04.000 --> 18:12.000 So the question is that how how this collaboration would work out like would we give out some training or something. 18:12.000 --> 18:17.000 So I think it is a very organized organization based answer. 18:17.000 --> 18:32.000 So in my current organization, I've been here for a short period of time and I've recently recently put this problem in front of my manager that I'm not able to collaborate with my developers when I once I'm done with the design. 18:32.000 --> 18:40.000 It just leaves my area of view. 18:40.000 --> 18:45.000 But in the past, I worked with this startup where again I was facing the same issue. 18:45.000 --> 18:50.000 So since it was a smaller startup, it was a quick process. 18:50.000 --> 18:57.000 I was able to tell them that the developers are like there's a lot of back and forth with the developers. 18:57.000 --> 19:04.000 So we did arrange a short session, get familiar with Figma for engineers. 19:04.000 --> 19:16.000 And I remember I gave like a 20 minute presentation on that, which I think I really feel that drastically improved my collaboration with them in the future. 19:16.000 --> 19:20.000 So I think it really depends like case by case basis. 19:20.000 --> 19:23.000 So you can try to do whatever you can. 19:24.000 --> 19:32.000 So here on that, this startup you will kind of, this, this movement to build DevOps, 19:32.000 --> 19:38.000 going to talk, you go writing software, you go operating software, you want to play together. 19:38.000 --> 19:49.000 You think there's a new of a space and you can do something similar content developers design, you can find else some sort of library. 19:50.000 --> 19:57.000 So a question is about similar to DevOps, if we can do something for front end engineers and designers. 19:57.000 --> 20:02.000 So I've not explored it a lot, but there is a term called design ops. 20:02.000 --> 20:05.000 I have not explored it a lot. 20:05.000 --> 20:13.000 But again, I think it depends a lot on case by case basis on how organizations would like to do that. 20:13.000 --> 20:20.000 But if there can exist a similar role or similar, you know, work stream or process, 20:20.000 --> 20:27.000 I think it could like really help with the collaboration between front end engineers and designers. 20:43.000 --> 20:52.000 Also, when you're about to do the lambda, but though I see there is a problem of explanation for design. 20:52.000 --> 20:58.000 So it's that some sides, it's like everyone was a hacker. 20:58.000 --> 21:09.000 So because the notion I say about the back end and the support, as far as even in the beginning of the Wikipedia, 21:09.000 --> 21:17.000 it's a kind of a lot of work to see, to find a thing. 21:17.000 --> 21:23.000 So I think it's kind to make a music guide, to use a pantheon as well. 21:23.000 --> 21:29.000 I think it's possible to have a better approach for everyone. 21:29.000 --> 21:35.000 And so it's also good for the relationship between design and engineering. 21:35.000 --> 21:36.000 Yes. 21:36.000 --> 21:38.000 I agree. 21:40.000 --> 21:42.000 That wasn't a question now. 22:06.000 --> 22:20.000 So the question is that in smaller teams, once the design is done, it gets developed and it is on production and sometimes 22:20.000 --> 22:23.000 we realize that it is not what we design. 22:23.000 --> 22:25.000 So how do we deal with that? 22:25.000 --> 22:33.000 So I, as I mentioned, like on during my startup, I did feel exactly that. 22:33.000 --> 22:42.000 And initially, in my journey, I think I did not have a lot of work to do. 22:42.000 --> 22:47.000 During my startup, I did feel exactly that. 22:47.000 --> 22:58.000 And initially, in my journey, I did not even think that okay, designs cannot be exactly translated into a product. 22:58.000 --> 23:05.000 And so that was a little bit of a shocker, a little bit of a frustration from my side that it is right there. 23:05.000 --> 23:10.000 You can see everything on the design, why is it such a big deal to not be able to do that? 23:10.000 --> 23:15.000 But I also understood it from the engineer's point of view. 23:15.000 --> 23:19.000 So again, I tried to discuss that with my developers. 23:19.000 --> 23:27.000 And I think I recently, I've made this change that as I mentioned in the presentation that getting involved early on. 23:27.000 --> 23:36.000 So every step discussing all the wire frames, sketches from the beginning and not just the final product. 23:36.000 --> 23:40.000 So going through the process together would be helpful in that case. 23:40.000 --> 23:41.000 Yes. 23:41.000 --> 23:43.000 Yes. 24:05.000 --> 24:06.000 Yes, yes, yes. 24:06.000 --> 24:15.000 The design queue or Q&A is something that we also recently incorporated in our design team since it's a newer team, I would say. 24:15.000 --> 24:19.000 And so yeah, that is in the talks right now and it's quite new. 24:19.000 --> 24:20.000 Yes. 24:20.000 --> 24:24.000 So this is the last question you came up with. 24:24.000 --> 24:29.000 I'm a graphic designer and this is my first time being in such a place. 24:29.000 --> 24:37.000 And when I hear your presentation, it's great because it's a very new thing for me to see design from engineer's perspective. 24:37.000 --> 24:44.000 Like when we talk about design, for example, if you would say documentation, you would call it design thinking. 24:44.000 --> 24:45.000 Yeah. 24:45.000 --> 24:48.000 And you say fonts, you would call it probably type things. 24:48.000 --> 25:01.000 Other efforts you may also to kind of like have you that you said you hang out with engineers a lot to know what they think about designers, but did you also get a touch with some designers to see. 25:01.000 --> 25:07.000 Because there's a whole kind of understanding education that is there. 25:07.000 --> 25:12.000 And maybe it's also nice to understand from graphic designers for you. 25:13.000 --> 25:25.000 Of how it is, because we always give a clear brief and ask a lot of questions, excuse me, I know what exactly and how you wanted to do. 25:25.000 --> 25:34.000 Like a logo or brandy or whatever, the engineer needs is actually all depending on what the brief is and what they want out of it. 25:34.000 --> 25:37.000 So I don't know if my question is clear then. 25:37.000 --> 25:38.000 Are you getting me? 25:38.000 --> 25:39.000 Yeah. 25:39.000 --> 25:41.000 Do you have a designer suit? 25:41.000 --> 25:42.000 Yes. 25:42.000 --> 25:44.000 And quickly engineers were actually. 25:44.000 --> 25:45.000 Okay. 25:45.000 --> 25:48.000 So I do acknowledge that there is a gap. 25:48.000 --> 25:59.000 And that's why I mentioned efforts from both the sides to try to understand the other persons perspective trying to understand some technical concepts from them. 25:59.000 --> 26:04.000 I have not really worked with graphic designers as of yet. 26:04.000 --> 26:08.000 Yeah, that is a fresh perspective that I would like to think about. 26:08.000 --> 26:13.000 But yeah, your reasoning is quite valid and I appreciate it.