Designing with and for developers

Open source is notorious for lack of design presence, enough so that my search to prove this fact has turned up nearly nothing. There’s many ways that such a gap in community might manifest, but one that I never anticipated was working with developers that had never interacted with a designer before.

A quick note for context: I’m writing this as a UX/UI designer working with open source projects for a little over a year. Because there are so many ways design processes can happen (enough to warrant its own blog post), this post is not intended to discuss design process deeply. My goal here is to pass on some of what I’ve learned that helps me design in this unusual space in hopes that it can help someone else. This post might seem most relevant for designers, but I think this experience could be helpful for developers as well.

After a few years at more conventional design jobs where the workflow never allowed me to communicate with our team’s developers, I started working with Project Jupyter on JupyterLab. This was my first experience working collaboratively with developers. I was feeling lost enough trying to comprehend the scope of the software I was helping design, and the enigma of the near-silent developer I began working with was not helping my nerves.

But it would be okay, because I had a plan! Surely if I set a good tone for this relationship and asked how design was most helpful for them, they’d be able to give me an answer, right? Here’s how that conversation went:

Me: Hey, I’ve never gotten to work directly with a developer like this before. How can I best support you? What are your expectations for working with designers?

Developer: I’ve never worked with a designer, so I have no idea. Let me know if I can help you, though.

Me: Oh, okay.

We didn’t speak for the rest of the day. Not the overwhelming success story I was looking for.

Once I learned I shouldn’t expect that everyone on my team to knows what they want from the design process, here’s what helped me move forward and collaborate with developers successfully.

Say hello.

Developers are the more established group in open source communities and may not feel the pressure to adjust their workflow to bring in designers even if they know it might benefit the project. Being on the outside, I’ve found it can be easier for designers to be the ones to reach out and intervene where they see a need for design. Just be friendly and be sure to give specific examples of the kind of work you’d like to do while listening to what they want. (Getting support from developers, however, is crucial, so if developers want to be the ones to invite designers, it can be a big help.)

Explore what’s already there.

Whether there is a product that’s already been developed or it’s brand new, I believe there’s always information that can be helpful in orienting a designer in a project. Make sure to explore the product not just in the ways I find designers are used to (testing the product based on use cases, heuristic evaluation, competitive analysis, etc.), but in the ways developers might experience or encounter it. This could be looking for what kinds of questions people are frequently asking on Stack Overflow, issues on GitHub, or any other kinds of documentation. One of the most helpful things is to have a grasp on what words developers use to describe specific parts or experiences in the project to make sure you are communicating with each other effectively.

Trust your process.

I hated being told this as a student, so hear me out before you immediately close this blog post like I would have a year ago. Sometimes it really is best to just start working with the intention of stepping back to evaluate the work early, often, and with others before getting too wrapped up in your own thoughts. I’ve found that once a developer has seen the direction I’m heading, they often start to get concrete ideas about what kind of design information they might need to turn those mockups and prototypes into real products. This opens up the possibility for more informed and stronger design work delivered in a way that makes everyone’s job easier.

Talk to each other.

This sounds obvious, but I find it easy to overlook by accident when both the developer(s) and I start getting wrapped up in our own work. Ask them their expectations about an interaction you are working on (developers are users, too) or what kinds of technical limitations you should be aware of. If you create a habit of bouncing ideas off one another, you’ll understand each other better when solving harder problems and will feel more comfortable sharing honest feedback. For me, this has been especially helpful since I work with projects that draw users with specific technical knowledge, so I’m unlikely to understand the user’s workflow deeply without relying on a little research.

Check in.

Would this kind of information be helpful when developing? Is this the work you were expecting from me? Do you see anything missing from the design? Am I representing this technical concept accurately? These are some of the typical check-in questions I ask developers I work with when reaching check points in a project. This regular feedback aided my development of a stronger workflow designed to help developers get the work they needed to move forward. Like any project, I find it critical to check in throughout working and at the end in order to learn from the experience and make sure I’m cultivating a positive relationship between design and development teams.

All these recommendations have grown and changed as the problems I face do the same, and I’m sure they will continue to develop as I work with different people and projects. In previous jobs, I had learned how to prove that my work had value and that design is critical to a company’s success. I always had to convince people to listen. Suddenly I’ve had people who are open to listening, but had absolutely no idea who I was, what I did, or how I could help them. The real problem began when I realized that I didn’t have confidence in my answers to those questions, either.

At just over a year into designing for open source, I remain surprised that this is more common than I thought. Across multiple projects and on different teams, I’ve worked with several experienced developers that aren’t certain what it means for me to be a UX/UI designer. It’s exciting in a unique way, and I’m grateful that I’ve met friendly and curious people who want to collaborate in spite of any uncertainty.

Most of all, I hope this helps someone looking for thoughts on navigating what it’s like to work in open source from the standpoint of a non-developer. Thank you for reading, and best of luck on your own collaborative adventures!