Flock 2026 The Engineer’s Guide To Design: Merging Technical And Creative Skills In Open Source

Um, hi everyone. So, every time you as an engineer choose a variable name, decide where or how a error message appears, or pick a default value, you are making a design decision. And engineers make design decisions all day, every time, but they just don't call it that. So, I'm here today because I think designers are far more capable of good design than they give themselves credit for, and they just need a slightly different toolkit. So, hi everyone. I am Khushi. I am an engineer turned designer. I worked at Red Hat for 2 years as a product designer, and I'm now just wrapping up my master's in London. Yeah. So, a pattern that I've seen in the few open source projects that I worked are that the code is solid, architecture is great, but users still sometimes complain that the product feels a little rough. Not completely broken, it works for sure, but a little rough. The navigation could be a little confusing, some unclear error states, or forms that do not behave like a user would expect. And eventually, the engineer who built it gets the bug report. But, the real failure happened like three sprints ago when a spec was ambiguous and no one really caught it. So, yeah, today I'm basically going to talk about how you as an engineer can close that gap yourself, not by becoming a designer, but by using what you already know and have. Yeah. So, tip number one is to read a design file like a spec and not just a screenshot. So, from my experience working with engineers, most engineers open a Figma file and look at it like a screenshot, like an image, and sometimes fail to notice that a Figma file or a design file usually has a lot more information than just what you can see visually. So, a design file is a spec, and as a good engineer, uh you can you should read it the way that you would read a API spec, for example. So, you can check for edge cases, missing states, um undefined behavior. So, make sure there are all the states such as the default state, hover state, focus state, et cetera. And uh you can also check for edge cases, like what happens when the text overflows or if the design is responsive enough. Yeah. Tip number two is to share your constraints uh before design starts. So, uh uh a designer, let's say a designer spends 2 weeks designing a designing an animated flow or a screen, and then you as an engineer come, look at it, and say, "Oh, we cannot do this. The data that is supposed to be here doesn't load fast enough for that animation to make sense." So, that's just 2 weeks gone. So, um the fix could be simple. Before a designer starts working on any feature, give them a technical brief. So, some bullet points, like what kind of data is available in what shape and form, what components already exist that they can use, what is expensive to build and what is cheap, and any other hard um accessibility requirements or internationalization. And I understand that as engineers, this might look extra work in the beginning, but it is kind of just front-loading the conversation that would happen eventually anyways. Uh just that you're doing it earlier to save more time and effort in the future. Tip number three is to review design the way you review code. Um as as engineers you are well aware, you already know how to do a thorough code review. So, check for edge cases, maintainability, performance. Uh design review is the same as a code reviews, but just a just a skill applied to a different artifact. And so in your project when a designer puts up a PR or shares a new file or a frame, uh your job isn't just to say looks good or, you know, I don't like the color or this doesn't look okay or doesn't feel okay, but ask the engineering questions. Uh does this work with the real data? Not just the clean 12-character username that they might have put in the design in the mockups. Um questions like what happens on a slower 3G connection? Is there a loading state that they've uh designed? Is the touch target for buttons big enough for mobile? And um yeah, so as engineers I feel engineers who could do this become a very valuable asset and design collaborators in any project. Um yeah, and these are skills that you already have. You just have to apply them on on the design side of it. Yeah. So, tip number four could be a little controversial, but uh [sighs and gasps] I feel that a lot of open source projects don't have the luxury of having a designer at all, uh which is very real. So, if if that's you, that's your project, these are some of the things that you can do with AI that don't require much design background, but can at least help you kickstart the the process. So, first is the accessibility audit. You can use any LLM to to get at least the basic understanding if your if the designs are accessible enough, if they are if the color contrast is okay, if there are any missing labels, hierarchy. Obviously, it would not catch everything, but it catches the obvious things that sometimes you as engineers might miss. Uh second would be token extraction. So, uh if there's a design system of your project, you can paste a screenshot of your existing UI and ask the model to extract a structured token file. So, it could give you the spacing, colors, type scale, um and you can use that as a starting point at least. Um Next I feel could be a helpful is the feedback clustering. So, uh if your project has a GitHub or like a open forum where users can give feedback, you can consolidate that feedback and ask AI, you know, what are the top issues that our users are having, and you can turn that community noise into design priorities without really needing a researcher on your project. So, I was trying to do these things with AI. So, this is just an example. Uh I pasted a screenshot of my design and asked for an accessibility audit. And as you can see, it gave me like quite a bit quite detailed, um suggestions for that. So, this is one example. Another example. Yeah. Another example was about error states. So, I feel as engineers, sometimes we don't care enough about how the error messaging sounds like, and it can be very confusing, and you know, frustrating for the user sometimes. So, if you can spend a little bit of time on just improving the error messaging, you can use AI for that, and it is quite helpful. It It adds to good UX overall. Yep. Uh and these are some of the examples of design-related uh feedback that I just got from the VS Code GitHub uh issues. So, these are some examples. I have not yet put them into AI and asked for actionables, but but like, this is proof that, you know, there are uh issues with There could be issues with your uh project as well, and you can collect them, ask AI to help you with that. Yep. So, if you are lucky enough to have a designer on your project, uh you can help them work much better for you, for the engineering team in general. Um I would start with saying that invite them to conversations early, uh not to make technical decisions, of course, but knowing what what kind data they are working with, what kind of constraints they are working with. Um and I know from my experience that a designer who understands your architecture doesn't would not design impossible things. So, usually that is a complaint that I get from my engineer friends that, you know, designers sometimes end up designing something impossible which is either very expensive to build or completely impossible to build. So, yeah, share constraints early. Uh and during, let's say, a feedback loop, if you do push back on a design, explain the constraint. You know, just saying this won't work um is not that helpful. So, saying something like, you know, this won't work because we would have to we would have to make a separate API call for each list item and that would tank the performance, you know, something like that. So, that is a constraint that uh technically sound designer, at least, can design around. And maybe they would find a solution that you hadn't hadn't thought of keeping the constraint in mind. And overall, if you are a maintainer and if you do want more designers contributing to your project, you can label some issues as good first design task. And honestly, like from my experience, from my peers around me, designers do want to contribute to open source, but it's just that they can't find the door sometimes. >> [snorts] >> Okay. So, as I mentioned in the beginning, that um you are already making some design decisions. Um just make try to make them more intentionally. Uh if an error says an unexpected error occurred, it is it is when a user can get frustrated, confused, you know, kind of lose confidence. And so, the Sorry. Yeah, so the shift has to be really small. Just ask yourself, you know, what does the user need to know here? And instead of, you know, what is the quickest or the default string that we can return. So, yes, that's that. Okay. So, a quick note on mentoring designers in open source. Um, I began my design journey, like when I shifted from engineering in open source, and that was that was very helpful for me. And uh, I would say to like if you're a maintainer, >> [cough] [clears throat] >> Sorry. Yeah. So, uh, mentoring designers in open source, uh, would be very helpful and beneficial for you as well as a maintainer. Sometimes, as a product owner, project owner, you do not realize what maybe having a design designer or some design contributions on your project, what that can do. So, the best thing you as a designer can do is explain your code base structure to a designer who's joining. Once clearly, like not the code itself, just just the mental model, just the structure. Um, so things like we use this component library, these are the constraints that we care about, and these are some of the issues that are labeled as, you know, good first design issues. And so, a conversation like that can unblock a designer for months and eventually >> [clears throat] >> when you review their work, tell them what's not buildable and why. Sometimes I feel we don't give designers enough credit as to how technically sound they could be. So again, explain why a certain thing, a certain design could not work and um yeah, so that's how technically uh literate designers are made and can help you. So now I'm moving slightly to the design side of it like for designers. So at Red Hat I worked with engineering teams of course and because I had a little bit of background in engineering, I could do certain things which I which I thought that other designers could not. So I could look at a component in the code base and understand what state it supported or what states were needed for a certain design. I yeah. Uh so in yeah, so in yeah, that's the >> [laughter] >> that's the thing. So in in design systems usually um you would need information like what sizing, spacing, hierarchy, maybe colors. So if as an engineer you just try to look at a um a design as a image and try to, you know, build it, it would be very difficult and very messy. So that's why we have like design systems which is like a which are tokenized items for again, as I said, colors, spacing, etc. So that you can like directly build upon design systems, basically. Um >> [clears throat] >> Yes. So, what a technically literate designer can do differently >> [snorts] >> Um yeah, so working with engineers, I I can I can understand what kind of things are buildable and what are not, and I can Um yeah, I can say things like, you know, I noticed the error state in that PR doesn't match the spec, and so the color is off. You have probably built something wrong, and things like that. Yeah, again, something for the designers to help their engineers is to annotate uh constraints. So, when we are designing, again, it should not be just the visuals. Um you as designers can uh work on annotating and giving more information about how it works instead of just how it looks. So, uh work on things like minimum touch target size, what happens if the text or the label is three times longer than in the mock-up. Um yeah, what breaks first if uh if there's a responsive um element to it. Uh yeah, so in general, engineers have to think in constraints. So, we as uh designers have to meet them there. Uh design tokens, as I mentioned earlier, um don't don't just uh work with hex codes. Tokenizing your uh colors, spacing, grids is very helpful for everyone, and documentation a little bit. Uh just mentioning that, oh, this is a blue button is much less helpful than saying something like this is a primary action button this or this is a call to action or let's say this button opens up a model. Or things like that. So the engineers making the implementation decisions need to know the reasoning they need to be able to connect the dots connect the screens that you're designing. So it's helpful when it's not just visuals and it's um it's more annotated. Yeah and that uh brings me to the next uh point which is prototypes. So uh the biggest source of friction often is disagreement about behavior and not just appearance. So clicking a button opens a model or is it a navigation button? What is the loading state? What happens on an error? So a high-fidelity clickable prototype answers almost all of those questions before anybody writes a line of code. And um yeah for engineers uh especially it can also help you do uh QA before um before you actually build it and so you are not questioning does it look all right but also does it behave all right. And so that is kind of where we can meet engineers and designers in between. In the middle. Yes and that's it. So I think the major three things to take away uh would be to share constraints early involve designers in in the early talks in the meetings uh demand interactive specs not just static marks and uh technically literate designer can be the biggest asset to your team. And yeah, that's all. You can connect with me here. Yeah. THANK YOU. >> THANK YOU VERY MUCH. DO WE HAVE QUESTIONS? >> HI. YOU mentioned that that you can like mark some issues as good for a design issues or something like that. I'm wondering how that actually works because like to me design is a whole like thing that you can't easily divide or like it's a like this you know overarching thing over the entire like program or suite or whatever app. How does a designer or can a designer actually work in the for like a small issue that involves some part of design but like it doesn't affect the others or something like that. >> Yeah, I think that's where it becomes challenging specially for bigger complex products. So um one of the one of the projects I worked with during Outreachy internship was a smaller project and so I felt it was much easier for me to get into it. But if your project is a larger more complex code base, you should start by you can start by like putting out there the issues and if designers show interest, be proactive in explaining to them the overall code base. I think it really helps. I hope it that helps. >> Thanks for the talk. I think this is a it's it's cool to see the, you know, ways that engineers can also think more about these things and in the same way that it helps to have a technically literate designer, it's also helpful to have a design literate engineer. >> sure. >> My question is, have you had a chance to explore many automated tools for testing or linting accessibility? The context for my question is this, I've I've been looking at um I guess it's pronounced pa11y, p a i 1 1 y. Um it's a tool for this as as I've been trying to think of how can I, you know, on smaller projects where maybe I don't have a designer [clears throat] on hand, but I want to think about accessibility. You know, it's it's it I use it as like a CI pipeline uh linter, so like oh if certain tests fail, you know, it can inform me like oh, maybe I need to go and look back at something and it can be with accessibility design, lots of different contexts I suppose, but I'm just wondering if you've have much experience with these kind of tools or if you found them as a designer to be useful or for creating conversations. I'm just wondering what other people are doing with these kind of tools. [clears throat] >> Yeah. So, I have not explored a lot, but uh at Red Hat, I do not remember the name, sorry, but I did work with a uh with within uh I think it was uh like a Chrome extension or something like that to to again do a accessibility audit. And so, I'm I'm not sure. Yeah, it's been it's been long. Yeah, that's fine. Um so, >> [clears throat] >> so yeah, I think I think there are a lot of tools like that uh that can be used. Um nothing on top of my head right now as of now, but uh yeah. >> Uh back to like this sort of um being able to manage small chunks of a project. Because I I was thinking like you know, not a very good-looking app. Mainly, in my opinion, due to the lack of a central designer that like actually, you know, gives a design document like this is how you should, you know, make it look and, you know, feel. [snorts] So, that that was my question. Like, is >> [snorts] >> does it make sense to start with these small local improvements, or is it better to just like, you know, find an actual designer, pay them, and you know, like >> I think a good starting point could be design systems, like maybe the Google's material design system or anything else that you think can work with you work with your project. So, starting with something like that and then, you know, working around it. And then, as your project, you know, progresses, then you can maybe think about like a designer. But, a design system can really help >> [clears throat] >> starting out and structuring and making it cleaner at least to start with, I feel. Mhm. Any more questions? Great. Well, in that case, let's thank our speaker again. Thank you very much.