Hi! I’m a senior product designer with a focus on devtools and observability. I’m currently working at an openTelemetry native observability tool, mostly focused on Kubernetes, services and web monitoring ( And CNCF related technologies). But It’s been awhile since I would like to contribute to the OpenSource community as a product designer, and I just don’t know where to start 
. Any tips?
4 Likes
Hi Andrea,
That is a question that is surprisingly hard to answer! Many projects have at least some sort of onboarding for developers, but it is very rare for designers.
Here are some recommendations:
- Check issue trackers and community discussions of projects you already like to use yourself. A lot of problems are very context dependend and this way you have a good chance to understand some of the context already.
- Related: Large projects tend to be well known (and thus more likely to draw contributors, among them maybe you) but they have a lot of hidden dependencies both technological and social. But it might be rather easy to make a design suggestion to a somewhat mid-sized Firefox extension.
- Since the ecosystem of open source projects focusses so much on, well, the sourcecode, it can help greatly if you can program and implement your own designs.
- Some thing that is relatively easy to do: Create simple wireframes of your ideas to make them more clear and/or wireframe the ideas of others and ask “Would it look like this?”
1 Like
Welcome. We tried to provide some pointer so this common situation in the Open Design Guide. There’s a page about finding the right project and getting started. Maybe it’s helpful?
3 Likes
Hi Andrea,
I’d be curious to hear how you’d envision finding UX challenges in the open source world to contribute to from your perspective.
we just started to outline a first process for design contributions in our contributing.MD, but we haven’t yet got to creating resources for onboarding UX folks to our project, such as publishing our current design practices and systems, key workflows, etc. I see that as the main blocker for facilitating contributions. In addition we want to publish specific UX challenges as clearly labeled issues on our issue tracker going forward.
Cheers, Tilo.
1 Like
Welcome 
As the others have said this is a common problem - plenty of OSS projects don’t yet know that they could benefit from OSS design contributions and half the battle is finding a project to contribute to - what I would recommend, since you have a OSS space re. CNCF technologies that you’ve got experience in is you can either look for projects there and find gaps that design can fill or if you’d like to contribute to a project that’s not in that space at all then the same process works for any projects - kind of like the developer ‘find a bug and fix it yourself’ as a designer you find a design bug and propose a fix.
You might want to see if Grafana and/or Mautic or any other metrics OSS tools are opne to contributions?
2 Likes
Hey there, thank you for your message .
That its an interesting topic…
I’d probably start by browsing issues explicitly tagged as ‘ux challenges’ and seeing if they connect to the bigger workflows you’re designing for.
I would say that the biggest help is context, knowing the design principles you follow and how users move and behave through the system. Without that, it’s hard to know if a suggestion fits. So I’d expect contributions to work best once you’ve published some of those resources and paired them with clearly scoped issues. That way, contributors like me can jump in without worrying we’re moving in the wrong direction.
From my side, I’d look for issues that go beyond ‘design polish’ and highlight deeper UX challenges, things like workflow clarity, reduce cognitive load, navigation patterns, or reducing friction (which may also imply broader UX changes). Framing these as open questions rather than prescriptive tasks invites contributors to bring their expertise and make meaningful contributions, and even more if a full picture/ context its provided.
I am happy to provide more insights if needed
3 Likes
that all makes sense and I actually also see for us a need of higher level workflow/interaction design. I’ll keep you updated on our progress of materialising these context artifacts and might come back to your offer to chat further along the way. cheers, Tilo.
2 Likes
As a maintainer for a project, I’d like to throw my thoughts into the ring. I find it to be complex, with multiple things at play.
One being a chicken and egg scenario.
Having a product designer as member of the team is a dream. But it’s so very, very rare. So while I could write up a bunch of issues specifically for designers, the sad reality is there’s a high chance that nobody will ever read those and nobody will ever work on those issues.
I used to write up “needs design” issues. But they would sit there for extended amounts of time until I realized nobody but me was ever going to work on them. So I do them. And if I do them, that means there are no design tasks left for actual designers to do. So when a designer does go looking, it looks like there’s nothing to do.
I can file big, meaty, product design tasks that are more “big picture” topics, and less “make blue button a new color”, but that leads me to the next issue I’ve run into.
Product design contributions are (obviously) very, very different than code contributions. Somebody can come in and fix a typo, or fix a quick bug in an hour and disappear forever and still have performed a worthwhile contribution. But with product design, you inherently have to be intimately knowledgeable about what the project is, what its goals are, who the users are, what the future is, how it got there, etc, etc. And that’s much more of an investment than a quick typo fix. An investment that when I’ve spoken to people, they are not interested in making. They want to know what they can do today, and that’s a hard question when they don’t know the product enough to do product design. They’re interested in making the blue buttons green because they think it would look cool, but they don’t know why they’re blue in the first place, or the weeks of conversations about button colors.
I hope I’m not over simplifying this or dismissing designers or projects, but I wanted to share some things I’ve run into.
I hope all are well.
3 Likes
I 100% agree! which is why making your goals, roadmap and hopes for an OSS project as a maintainer of it, clear and viewable and/or i recommend finding a designer that is interested in becoming a maintainer of the design of the OSS and not just ‘tasks’ 
I totally hear you though, it’s a chicken egg situation, but as a long term design maintainer of OSS projects as well as knowing a good number of other design maintainers, it is possible. Not easy, but possible!