How to be UX Researcher supporting an open source project with differing user objectives?

Question

I've seen other questions about user testing or contributing UI to open source projects- I'm curious if anyone has done UX Research for open source tools. I'd like to get better embedded in their github processes and help them engage with community beyond the biased group of devs building the thing.

A few pieces of context:

1. I am a FTE on a team that is partnering with an open source project- so the company employs FTE engineers and PM on the open source tool but there is also a big community of developers. As a researcher, I've been deterred from engaging in the ways I would on a normal team, mainly because the open source contribution process is so distributed and doesnt allow for roadmapping/UXR engagement.
2. I did an original set of heuristics evaluation and "missing essential features" workshops with the team, but was told to put a pin in the work until we hired a PM (which happened recently).
3. At its core, i feel the open source team believes we should be focusing more on the expert user (aka them) rather than the beginner, no code user (which is the company's objective), so i find my feedback and strategy to be at odds with them.

Any resources would be greatly appreciated!

Answer 1

I have not done UXR for open sources tools. I have however, fought against similar attitudes/situations to what you're currently facing so I have some suggestions. I hope they help.

1. Start with some UXR Theatre and engage the team on some UXR activities: The goal here would be to build some excitement for UXR, an understanding of where their assumptions could fall short. I did a lot of this at an Ad Agency where I brought in the UX practice then moved from UX Maturity level 1 to 3. I would print out mini-persona cards then have stakeholders, devs, and creative directors play the role and go through some basic UXR activities. I always found lots of joy in doing First Clicks tests in this format and watching devs react when the "test user" didn't click in the right spot.
2. Do some prioritization activities on the backlog tasks: If you can find some beginner/no-code users that use your tool, get them to evaluate and provide input on features/updates that haven't been made yet. Host a workshop and do an activity like Bullseye Diagramming or Buy a Feature. This will give you user-centred input on which features and tasks have the highest importance to your end users, which the project team will likely find valuable for their own prioritization w/o challenging their expert insight.
3. Pick you battles and find insight on diplomatic areas: Heuristic Evaluations and Missing Feature workshops are brilliant, I love them. But in your case, these kind of activities will produce findings showing where the team was wrong or missed something. That input could trip up some egos regardless of it's validity. Instead try to find some activities where findings could simplify or eliminate current dev efforts. If your findings start making their jobs easier they'll want to loop you in more and more.

I really, really, really wanna suggest some recorded field studies to capture user feedback on the parts that really don't work for users. I like being contentious sometimes, so I have definitely showed clips of users ripping into a tool to the team that built said tool to erode some of their trust in their own opinions and decisions. It rarely goes well :D I'm sure I'll do it again though

Answer 2

Here's some more background info to expand on Dylan's answer.

Understanding open source developers

There are main 3 avenues open source developers get made:

1. They are making a tool for themselves, which ends up being useful to quite a lot of people and thus popular.
2. They are making a tool for the benefit of a certain community.
3. They are making a product which happens to be open source. "Product" here would be something that can be monetized in one way or another, or otherwise has a pathway to becoming financially sustainable.

In case 3, Nash's answer broadly applies; you can send out some feelers on how to work together with the team and they'll likely understand the value UX research brings quite quickly.

In case 2, it's not so simple. If the community doubles as a target audience, you'll likely have an easier time to get going; if the community is the free software and open source software (FOSS) community itself, you'll have a harder time.

Part of the problem here is that, for better and worse, the FOSS community tends to be anti-consumerist, anti-capitalist, strongly pro-privacy and otherwise incompatible with common assumptions we as product and UX people make. After all, it hardly is normal to spend lots of time doing something for free, and continue doing it for free even as the world's most popular websites start using one's software as the foundation of their success.

For example, for us, majorly improving a software for 99% of the userbase while locking out 1% of it would probably be a no-brainer. In the FOSS community however, caring for the remaining 1% is generally seen as worthwhile, even if that results in a plethora of new options and extends development time 3x.

A major contribution to that is aforementioned pro-privacy stance which makes telemetry frowned upon. So when making a change and 20 users pop up in a forum or mailing list demanding a revert, that might be a representative slice of all users, or it might be literally the only 20 people who have ever used the feature you just have changed. The developers will have no idea, so better make the change optional.

In case 1, things are even more stacked against you. Here, in addition to everything which may happen in case 2, it additionally can happen that any bug, feature request, code contribution or anything other than direct praise is seen as an annoyance. Things get added and improved if the main developer(s) feel like it.

Going in this as a UX researcher is bad enough, going in it as a designer is worse still as you're seen not as a potential contributor, but as someone who is about to put more work on the table, which would be a hassle.

Answer 3

I think the question can be answered in a more generalized form as "How to get the UX role into an existing process?"

Changing a process can start from the management level if they change the meeting structure (meetings between devs and UX) or if UX becomes a quality gate for releasing features. Then they have to talk to you.

Otherwise, you have to think about how to integrate yourself into their process. I would start with helping them out. Ask if they need help with screen design, icons etc. Slowly, they will know what you are doing and ask you for help more often and also realize the value of having UX in the development process.