Gain a Superpower in OSS as a Designer Through Code

Gain a Superpower in OSS as a Designer Through Code Intro (Brief intro about myself, my past work for open source, why should you care what I have to say) Why do I need to learn to code? That's developer stuff... (5 mins) Being able to own your thoughts from design to implementation is definitely a strong skill on your designer toolbelt. So, why do I need to learn to code? Knowing how your mock can be implemented helps improve your approach to design. You’ll find yourself approaching problems differently and also get better at your work as you see things more practically. Knowledge of how difficult it would be for developers to materialize your design visually or in terms of performance is powerful and helps provide perspective. Understand developer jingoism and participate in conversations that revolve around your design. Also, being familiar with the terminologies can go a long way in improving communication. In case your team decides to build live code prototypes, you'll be able to adapt easily. Stand out amongst your peers because of your versatility and in depth knowledge around your domain. Apart from the topic of the talk, in my opinion, coding is something you should definitely dabble with before you decide it's for you or not. Helping OSS as a Developer-Designer (5 mins) You'd have a difficult time finding someone who believes that design in Open Source couldn't use help from a professional. FOSS in general is made with little to no contributions from skilled designers which leads to ugly looking UI and end up with poor User Experience. So many powerful Open Source tools lack the perspective from a designer and thus block out a large portion of users due to inaccessibility. Let's consider a scenario: Most open projects don't have teams of coordinated people working on different aspects of the software. We're all everyday people taking out some time to work towards a passion project. So if you add a designer in the story who can also help write the code for their work, it can improve the project quality significantly. And if you happen to be that person, it would not only help the project, but increase your standing in the FOSS community too. If you're already an Open designer, another common pain point that you may have come across is the loss in translation of design from a mock to code. However, gaining control over that will help you build much more accurate flows and improve the final product. The approach to coding for OSS complexity (5 mins) Open Source software can be really big and complex. So, starting off can definitely be daunting but it doesn't have to be demotivating. I won't focus on how to set up the local dev environment for a project because of the time constraint here but I'm aware this is a key hurdle. I'll discuss the next best thing, i.e stuff to keep in mind before you start contributing. Coming from a design perspective, your first approach should be to find the code responsible for generating the views, i.e the frontend. Play around with the code, make some changes that you can see on screen. This will also help generate confidence while writing code. Understand the structure of the code. Figuring out how a particular view is generated will help you know the exact files to modify and boost your understanding of the codebase. Ask for help. I've experienced running into many weeks of rabbit holes that could've easily been solved in a day had I just asked for help. This ranged from having trouble running the project, or just simply confused what a particular piece of code does. So even if you're struggling with simple problems like Git, remember we're all in it together, don't be afraid to reach out for help! So, "I know my way around the code, how do I tackle a particular issue?" Always break down the issue to it's smallest constituents. In terms of design work, break it down to the relevant components and the files that affect it. This will create an isolated environment for your work that won't (or should not) affect anything outside of what you're contributing to. Backtracking. Whenever you're pointed to a particular file that needs to be updated, go a step above and see where and how it is being used in the broader architecture of the codebase. This is a good practice which you should definitely include in your workflow as you start your coding journey. Where do I go ahead with all this new found knowledge? (3 mins) If my talk inspired you to pick up code for the first time, go ahead and use all the amazing learning resources out there to get familiar with styling, animations etc. Try coding your design on non-critical parts of a project. Advice, go for this approach on projects that you're already a contributor. This way you know the developers are open to mentoring you and can provide helpful reviews. You can apply the learnings from this talk to even your work, maybe try implementing some small design improvements if they let you. Pitch in Open Source Design jobs page to find opportunities paid and open source. Mention orgs like NextCloud that build design heavy OSS Also, if you would like to know more on this topic, I intend to release a blog soon that would cover some other points too, like, - How to take your PR through the OSS process. - How to properly receive a code review. - Engaging with other devs and deal with difficult conversations. Outro (Appreciation, extend help, links to my socials and all that jazz)