Methods to make an open source project's developer community more aware of its end users and their needs: personas? other ideas?

Design Lounge Communication and collaboration
1

Hi all! I work with the OpenRefine project. I’m not a designer - I am the project director; but am very interested in introducing more UX design work and general user-focused sensibilities into our project.

What kind of methods/tools/tips would you have to help OpenRefine’s developer community understand, and build for, its end users?

Personally, I am familiar with personas. I have used them in previous projects, and I really like the idea of introducting them in our project, especially with the attempt to make ‘our’ personas really visible and memorable for all code contributors. (‘I think Sandeep will be very confused by that new feature we are discussing here’ or ‘Yayyy, this is finally going to solve the struggle that Pam always had with…’)
That said, while I think personas are a good idea: I have never been involved in a project that really took them seriously and used them in the actual work. One designer I work with, dislikes / discourages personas (perhaps for this exact reason, I should really ask her for her more in depth opinion on this).

Hence my question. Do you have ideas for me? Do some of you know of projects where personas DID actually do a useful job, had a clear influence, and if so: how did that happen?

Or are there other, better methods?

Especially since I’m dealing with a quite nerdy, specialized, partly very academic developer community. This issue of ‘always making the end user very visible’ is really important to me!

Thanks all! I hope you find this a fun question :slight_smile: Sandra

3 Likes
2

My suggestion would be staying close to something that developers know. Most forms of design deliverables are unfamiliar to many programmers. However, many developers know usecases. The also have the advantage of being usable on issues in issue trackers. This is important, since things that live outside of familiar tools will often not actually exists, in a sense. And in most open source projects, familiar tools are tools that are close to code.

I imagine something like this (I am making all this up, it will not be factually correct!)

Usecase: Import XML data: An end user should be able to import XML data to Open Refine easily and without background knowledge of how XML exactly works. The import happens by doing the following steps:

  1. Call up the import process, Select the file to be imported
  2. Select the relevant data
  3. Check import for correctness
  4. Execute import

Now, this okay, but you might have some background knowledge that you should include:

Known problems: XML files are particularly hard to read for laypeople. Many users might feel overwhelmed. We also know that it is hard to create reliable heuristics to select the data.

usually, not all usecases are relevant for all users. Even without personas, you should specify:

User group: XML files are very often used by librarians; many will know that the format exists but they will not see it in its raw form, usually.

As this format can be put in an issue tracker, it is avaliable to developers and other roles as well. For the concrete implementation in code, one would create a separate ticket to track the progress of coding on relevant sub-features, e.g. Implement heuristics to highlight relevant parts of XML or so and link the the inital ticket as parent. This seperation is important and probably is the most difficult to convince many developers to follow, since it is very tempting to get absorbed in implementation discussions.

If the general structure is accepted, you can expand the focus on users. For the known problems, you could link to user research or feedback on forums to show the user needs there. For the user groups you might want to structure information on them. Usually this is gathered via community-survey and interviewing domain experts from the sub-communities you cater to. This, at some point could be expanded to personas but even a list of “things that are important to Journalists when using OpenRefine” is of great help.

1 Like
3

I feel like personas can be useful but mostly as a visual tool, and a way to try and ground discussions/disagreements with Product/Business types in a closed source commercial context.

Also personas created without any empirical basis are mostly kayfabe. I would say a better idea would be to get a designer and have them do some generative qualitative research or perhaps some exploratory surveys to a range of users (also easier to scale and present in concise metrics).

Personas could be a deliverable that comes out of that, but I wouldn’t pursue that as a deliverable without first doing the research.

I work at the VA and we do all our research in an open source way. If you’d like to see how we do that, here’s our guide: Research Checklist

And here’s the repo where you can peruse the outcomes and documentation from this work: va.gov-team/products at master · department-of-veterans-affairs/va.gov-team · GitHub

Each product has a folder, and in that folder you can find various research initiatives, with their proposals and conversation guides (basically a script for user interview sessions).

It can also be helpful to get devs to listen in on a few of these interview sessions to give them a general instinct for their users.

2 Likes
4

I would probably lean into user testing and user journey’s over user personas a majority of the time. As said above, personas are good for a general ‘finger in the air’ temp check and certainly a very good tool for some departments like marketing and advertising to remember how to ‘sell’ to a certain kind of person and documentation to remind writers what kinds of typical user personas respond to what kind of written language forms in what kind of cadence but for design, UX/UI etc. I find them more of a way for designers to onboard to that niches users. In that way I see them as a tool for designers to help to justify choices if no user testing/research can or will be done.

Here’s a couple of resource sites/repo’s I’ve made over my time:
This is the start of a series of guides, tools, scripts and other mediums to help developers get used to various kinds of design. We focused on user testing and synthesis processes first and are building out more resources as we go.

and if your want some methodology and other exercises to try out you could take a look as some of the work here: GitHub - Erioldoesdesign/opendesign: A methodology for distributed, asynchronous design contributions to software projects

Or you could take a look at the design docs I wrote for OSS design contributors when i was design lead at Ushahidi: Design: overview - Platform Developer Documentation
There’s some scripts and examples of how I did design out in the open there

I hope these examples help! Also drop me a DM if you want so have a video/audio chat sometime :slight_smile:

1 Like