Our second is the last talk.
Yeah.
All right.
Thank you.
Cushicard.
Thank you so much.
Hello, everyone.
So I asked someone who has transitioned from being a engineer,
being a developer to a designer.
I felt I realized that designers and engineers can collaborate in a better way.
And that is what I'm going to talk about today.
So currently I'm a product designer at Red Hat.
And in the past I have interned with outreach, which was my first open source and design thing.
So outreach usually does not have a lot of design projects.
And I was able to find one of those applied to one and intern with them for a design project.
And that is when I realized that open source in general does not see a lot of design contributions.
And I delved into open source as a designer.
So I started by addressing this misconception that engineers in general think that designers only focus on making things pretty.
And designers feel that engineers are only just about functionality.
And that they don't value or value UX as much or that they ignore UI and UX.
So I have a lot of developer friends, right?
Since I come from a BTEC degree, like a computer science degree.
So it is kind of like a running joke between us that designers don't care about us.
They give us such complicated designs, animations and whatnot.
And we are not able to develop them or it is like it is a headache to develop the designs that we get.
But at the end, the shared goal is usability and great UX for our users.
And so again, we need to accept that better collaboration will lead to better solutions.
So I would start with how designers can support engineers.
First point, speak like an engineer.
So learning basic technical concepts related to your product can be really helpful.
So for example, you are working on a product that fetches data from a third party app.
So if you as a designer understand how an API works or how this particular API fetches data or how often it does that,
you would have better context and better constraints to design better.
And you would be able to communicate much more effectively with your engineers.
So you can start by asking questions in meetings, reading tutorials, reading documentation about the product or technologies that it is using.
And eventually you will feel much more confident and equipped to talk with your engineers.
Second would be to consider your engineers as your design partners.
Do not design alone, designing is not a solo job.
Try to involve engineers as early on as possible because it can save you a lot of time and effort.
So your engineers can help you identify technical challenges, constraints and help you save time by identifying the technical challenges.
So you can start by sharing wire frames, sketches and gathering their feedback quite early on.
Designing for feasibility and scalability.
Your design should not only look great, but you should make sure that it is easy to build and scale as a product grows.
So let's say your product currently has two features.
But what happens when the product team decides to add five new features next quarter is your design going to break.
Is it going to be too overwhelming for the users?
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.
Make your design as scalable as possible.
Good documentation.
I think pretty self-explanatory, but good documentation can save you as and as of back and forth.
Try to annotate your designs if possible.
There's option in Figma to do that and understand that if something is missing in your design your developers will have to guess.
And that is where mistakes happen.
So you can try to document all the scenarios like loading states, error handling and success messages.
Last point would be to advocate for your engineers.
So it is our typical scene that the product team is all pumped up.
We as designers have great designs.
We are excited for them, but more often than not engineering resources are limited.
The lines are always tight and not everything can be built right now.
So don't just push for your wish or your vision and try to understand and sorry.
So don't just push for your wish and your vision.
Try to understand the technical limitations of your engineers as well and try to partner with them.
Value the experience as well and be willing to just work together as our team.
So that was part one of my talk that how can designers support engineers.
Now we would talk about the other side of the coin.
How can engineers support us as designers?
So similar to what I said about designers, engineers can understand design principles.
So knowing basic design principles will help you align better with your designers and appreciate their design.
So you can start with learning about basic key concepts of design like hierarchy, contrast, typography, white space etc.
And I feel when engineers also understand design language, it becomes a much more smooth process with unnecessary debates or miscommunication.
So that could be a great starting point for engineers.
Second would be to provide feedback on feasibility.
So since I said that designers should try to involve engineers early on.
If your designers are trying to do that, make sure you provide them with feedback early on.
And you as a engineer can guide them by sharing technical insights, by sharing advice on what is achievable,
given the given constraints on tools, time, budget, etc.
But make sure you still preserve the design intent without our right rejecting ideas.
Try not to say that this cannot be done, but propose a similar solution that aligns with your design team as well.
And the overall projects or products ideas.
Get familiar with design tools.
So this is something I have personally felt a lot and still struggle with.
So I feel that engineers often do not realize that how useful the tools that we use are.
So I've worked with engineers who treat designs like a flat image and they are not able to utilize the tool completely.
So if they are treating designs like a plain image, they tend to do guesswork.
So they would have to guess on spacing, what is the spacing here, what is the font like, what is the font weight.
But you again as engineers you will have to realize that tools like Figma have advanced a lot and you can utilize.
You can utilize these tools to make your process much more smooth.
So Figma can give you details about the design.
You can directly check all the spacing, font weights, colors, everything on the tool itself.
You can also add feedback, add questions on the design so that context is maintained and discussions are also traceable over time.
And yes, a lot of design tools also allow engineers to export assets directly from the design file.
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.
And I think this really speeds up the implementation process.
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.
Next point would be to encourage design first culture.
So if you are in a team where you feel that your stakeholders or the upper management does not really value design as such,
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,
which will also help you to align technical and creative goals from the very beginning.
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.
Basic dev knowledge is accessing it, they can understand it.
A test for accessibility so you can run automated tests using tools like Lighthouse.
You can also manually check for keyboard navigation, contrast issues.
You can check if you are developing design also supports screen readers and assistive technologies.
So yes, that was all. Some key takeaways would be that design and engineering need to work hand in hand.
And even small design efforts can significantly improve usability in open source in general.
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.
So if we can somehow improve the collaboration process, it would help the open source community in general.
And today tools and processes exist to help engineers and designers collaborate better.
So we should just make the best use out of them to help our users at the end.
That was it. Thank you.
Thank you.
We have questions.
I speak from the point of view of the engineer.
For me, design has been a lot of value, but unfortunately I can collaborate with one.
And so I have to do that.
And I found myself using Storybook that is a weak collaborate and think in the way of the designer.
And my question is, could you think about Storybook?
So the question is, firstly about Storybook, and second about how developers in the open source field can collaborate with the designers.
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.
So like starting with open source, open source design as we have it here.
So I feel there are a lot of designers out there, but not enough design work also.
So as you mentioned that you do most of the design work yourself.
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.
It also, it's also, it's not really for all that we are not able to contribute to it.
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.
I think it could help solve that problem.
So the question is that when perspective from both sides is discussed, do people tend to like switch sides basically.
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.
So as I mentioned, my experience with my friends who most of them are developers.
So whenever they say something like we are not able to collaborate easily or designers are like they work in another world all together.
So my perspective is that you need better processes in your work, in your company, let's say.
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.
They do so.
Okay, so the question is that what would I like to change about designers using GitHub?
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.
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.
There is not enough version tracking or not enough all of that now.
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.
Really does not work out from my experience.
So how do you implement that?
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.
So the question is that how how this collaboration would work out like would we give out some training or something.
So I think it is a very organized organization based answer.
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.
It just leaves my area of view.
But in the past, I worked with this startup where again I was facing the same issue.
So since it was a smaller startup, it was a quick process.
I was able to tell them that the developers are like there's a lot of back and forth with the developers.
So we did arrange a short session, get familiar with Figma for engineers.
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.
So I think it really depends like case by case basis.
So you can try to do whatever you can.
So here on that, this startup you will kind of, this, this movement to build DevOps,
going to talk, you go writing software, you go operating software, you want to play together.
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.
So a question is about similar to DevOps, if we can do something for front end engineers and designers.
So I've not explored it a lot, but there is a term called design ops.
I have not explored it a lot.
But again, I think it depends a lot on case by case basis on how organizations would like to do that.
But if there can exist a similar role or similar, you know, work stream or process,
I think it could like really help with the collaboration between front end engineers and designers.
Also, when you're about to do the lambda, but though I see there is a problem of explanation for design.
So it's that some sides, it's like everyone was a hacker.
So because the notion I say about the back end and the support, as far as even in the beginning of the Wikipedia,
it's a kind of a lot of work to see, to find a thing.
So I think it's kind to make a music guide, to use a pantheon as well.
I think it's possible to have a better approach for everyone.
And so it's also good for the relationship between design and engineering.
Yes.
I agree.
That wasn't a question now.
So the question is that in smaller teams, once the design is done, it gets developed and it is on production and sometimes
we realize that it is not what we design.
So how do we deal with that?
So I, as I mentioned, like on during my startup, I did feel exactly that.
And initially, in my journey, I think I did not have a lot of work to do.
During my startup, I did feel exactly that.
And initially, in my journey, I did not even think that okay, designs cannot be exactly translated into a product.
And so that was a little bit of a shocker, a little bit of a frustration from my side that it is right there.
You can see everything on the design, why is it such a big deal to not be able to do that?
But I also understood it from the engineer's point of view.
So again, I tried to discuss that with my developers.
And I think I recently, I've made this change that as I mentioned in the presentation that getting involved early on.
So every step discussing all the wire frames, sketches from the beginning and not just the final product.
So going through the process together would be helpful in that case.
Yes.
Yes, yes, yes.
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.
And so yeah, that is in the talks right now and it's quite new.
Yes.
So this is the last question you came up with.
I'm a graphic designer and this is my first time being in such a place.
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.
Like when we talk about design, for example, if you would say documentation, you would call it design thinking.
Yeah.
And you say fonts, you would call it probably type things.
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.
Because there's a whole kind of understanding education that is there.
And maybe it's also nice to understand from graphic designers for you.
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.
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.
So I don't know if my question is clear then.
Are you getting me?
Yeah.
Do you have a designer suit?
Yes.
And quickly engineers were actually.
Okay.
So I do acknowledge that there is a gap.
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.
I have not really worked with graphic designers as of yet.
Yeah, that is a fresh perspective that I would like to think about.
But yeah, your reasoning is quite valid and I appreciate it.