Preparing the User Research

UX / User Research
#1

Bonjour,

I’ll follow the guide because I forgot most of it since the last time (2019). In the following software is used instead of Free Software to keep the research focused on activities related to software available to the general public (as opposed to being guarded by an access mechanism of some kind) and published under a Free Software license. The activities related to software that is not visible to the general public or that is published under a license that is not Free Software are significantly more complex and would require a lot more work.

Create a user-focused how-and-why question based on the initial idea for the project

  1. The initial idea is an online service that allows a user to interact with a software project hosted on one forge while using another forge.
  2. The meaningful activity is to develop software.
  3. How and why are multiple forges used in the development life cycle of a given software?

Find participants

There are three personas (Free Software developer, Forge developer, Forge maintainer) and there needs to be at least three interviews for each persona.

Legend: :question: Kindly asked, :red_circle: Not interested at this time, :white_check_mark: agreed, :clock1: scheduled, :microphone: : recorded, :spiral_notepad: transcribed, :ballot_box_with_check: transcription review in progress, :blue_book: published

Free Software developer

They are either serious hobbyists or professionals who participated in software development for several years. They have used more than one forge, simultaneously or because they had to migrate a project from one forge to another. The software they develop have dependencies to other software for which they either track issues related to features/bugs or provide patches.

Forge developer

They work (or worked) on a forge software. They are involved in defining new features, figuring out the user needs, either as independent contributors or as a company employee. They use the forge on which they are working on a daily basis, i.e. dogfooding. They have a good understanding of the User Interface and how it is defined as well as the backend supporting it. They are involved in release management, know how to analyze integration test failures and are conscious of the tradeoff involved in maintaining backward compatibility.

The developers working on forges that have developed a strategy to lock-in their users such as SourceForge, GitHub or GitLab enterprise are not considered. Their ultimate goal is either to prevent their users from using multiple forges or to only support one migration path: from other forges to their own. As a consequence their input would be strongly biased to favor their own needs: it would obscure the needs of the users instead of revealing them.

Forge maintainer

They are either independent system administrators or manager of an organization maintaining a forge that is either publicly available (such as https://forge.chapril.org/) or targeting a selected audience (such as https://lab.enough.community). They were involved in choosing the forge software and defining the production environment, backups, RGPD compliance, import and export policies.

Informal discussions

Organize the affinity mapping session

User Research Affinity Mapping
Diversity: continuous improvement
Logilab collaboration
DRAFT: monthly report, May 2021
DRAFT: User Research report
Personas and Intercept Interviews
Preparing the user interface
DRAFT: monthly report, April 2021
#2

On SocialHub in United Software Development: A new paradigm? I mentioned the following (highlight mine):

But what you have to do anyway is to analyse and elaborate the application / ‘business’ domain where you want to reach your project objectives. Right now, FedeProxy is conducting User Research. Very good and utterly important to gather as much feedback as possible.

But there’s a possible pitfall too. What users are you researching? For what domain? Currently on the forum this occurs in the “UX / User research” category. But UX is a step too far, if you do not know the domain. There’s a risk to start thinking about concrete features and functionality, UI widgets even, way too fast.

My question is if something of that pitfall is apparent here already? This is oriented towards UX, where persona’s are abstractions of persons using the software. May be better to refer to stakeholders first. They may or may not have representation in UI features, but they have needs and desires for the project. Your funders, your core team, and contributors might be among them.

Also “free software developer”… why not “forge user” or even agent/actor? The person or organization that maintains a website, or a piece of documentation, a resource list, a specification (e.g. W3C). Is there a another stakeholder besides “forge maintainer”, namely “fedeproxy maintainer”, or are they one and the same? Should there be a distinction between Persons and Organizations? What does ‘organization’ even mean in context of a forge? Can they be groups, communities too? Are bots or 3rd-party services stakeholders? Note further that not all stakeholders need to be addressed from the start, but that should be a conscious decision.

1 Like
#3

Now is indeed a good time to question the fundamentals of the User Research. It is currently focusing on the following how-and-why question: How and why are multiple forges used in the development life cycle of a given software?. My reasoning is that the very nature of forges is to enable software developers, to provide them with a space and the tools to create software. Note that developer should not be limited to someone who writes code. People who report a single bug are developers: they contribute a change to the software that is as valuable as a bug fix. The forge user who is not a software developer, i.e. who only consumes what the forge publishes is not in scope, IMHO.

I thought about including a persona who is contributing to a software but not writing code instead of blending them into the software developer persona. But I don’t see how they have a behavior that is fundamentally different. I don’t see what perspective they would provide that would be so different that it would deserve a different interview script. In this user research, a “forge user” or “agent/actor” is a “software developer” for this reason.

Since user research is about observation and testimonies, it cannot include a “fedeproxy maintainer” for the simple reason that they do not exist yet :slight_smile:

The distinction between Persons and Organizations is something I did not think about. In my mind, User Research is about observing what human beings do. I did not think about what it would entail to observe an organization and I would have to educate myself on this interesting idea :thinking:

Regarding the UX focus, I don’t see how it is one step too far and would love if you could expand on that problem.

#4

@arthurlogilab would someone from logilab be interested in participating in the analysis of the interviews? Since you kindly agreed to be interviewed, I can’t ask you :slight_smile: This is an in-person (six people) activity that takes half a day and will happen in Paris, between 15 May and 15 June. I won’t lie: it’s not a lot of fun even though there are lots of post-its involved :sweat_smile: It will be my third experience and I’m looking forward to it because it’s very intersting. There is no preparation required, all it takes is an open mind and focus during a few hours. And also to be fluent in French because a number of interview transcripts are in French :fr:

#5

Ah yes, you are using that guide to find user needs. Nice!

I formulated my feedback as questions, because I don’t know the extend to which you had considered them already, and also there are a ton of different approaches to product development, and each have their own pros and cons. Not saying you take the wrong approach either… it depends on elaboration and objectives, if they are already somewhat defined.

Reason I mention the pitfall and say that UX may be a step too far, is that the (real-world) domain exists regardless as - how should I formulate - ‘universal knowledge’ your stakeholders have, regardless of any software forge implementations (which are abstractions of the domain). In a sense there is no user experience yet. There are just domain experts (the people with the expertise / craftsmen). In the case of FedeProxy this is everyone in involved in the software development lifecycle.

I understand you want to know all about current use of forging. But with the interview focusing very much on that, the danger is you get tunnel vision, unwittingly put on blinders that make you miss out on opportunities for improvement. With the line of questioning people tell their experience from a particular software perspective, not from the holistic process they follow. During the interview the goal should be ‘discovering the domain’. And then gradually the domain becomes your guide to delve deeper into specifics.

This takes a lot of text to explain, maybe we can do a vidcall one of these days, but I’ll include a video I posted yesterday to SocialHub:

Some random thoughts:

  • Is the question “How and why are multiple forges used in the development life cycle of a given software?” properly phrased? Why not ask “How do you develop software?”

    • How large is your team, and what roles are involved? Describe the development lifecycle. What problems do you encounter, where can this be improved, what is most time-consuming? Who’s the customer? Toolstack? Partners? Etc.

  • Are different scripts needed for different stakeholders? Might well be. Product owner, QA/Tester, Technical writer, UX/Interaction designer. They’ll be touching repo’s.

  • While you can’t interview a “fedeproxy maintainer” now, it most likely will be a stakeholder in the future. You can interview e.g. masto / pleroma hosters or similar hosted FOSS bundle providers. What drives them, what do they desire from their software.

  • Don’t know if you planned it yet, but I’d also include a large professional organization that develops FOSS and has a complex dev process, many people involved + complex products. Maybe a Linux distro, dunno.

#6

Thanks for explaining and this is precisely the pitfall I’d like to avoid. I’m tempted to answer that given the time / resources we can afford on User Research and putting them to use, exploring the “software development” domain is too costly. Exploring the “software development involving multiple forges” is something that sounds like it can be done within a few months (one month already passed). Now… to keep an open mind one has to consider the possibility that the basis of the current project are rotten. For instance, if there is a high probability that my assumptions on the “software development” domain are wrong, it follows that my exploration of the “software development involving multiple forges” domain is biased to the point of being useless.

There are three ways to clear this: either explore the “software development” domain and verify my assumptions are good enough. But this is something none of us can afford right now. Or take a leap of faith and hope for the best, which is something that makes me very uncomfortable. Or, as you propose, discuss it verbally and exprience a “Conflit sociocognitif”, i.e. understanding each other point of view and reformulate our own.

Would you have time in the near future for such a discussion?

#7

Note that you don’t need to explore the domain in-depth. It is vast. Just by a different phrasing of your research, and a subsequent way to phrase the questions (while still quickly drilling down on how forges come into the picture) you may ensure to keep a holistic focus, while being better able to set direction. All I’m saying is people don’t use apps for the apps, they use apps in support of their domain.

And the domain modeling - just of those parts interesting to FedeProxy - go hand in hand with user/product research, reinforcing the effectiveness of each other as you go along. Note that it is an ongoing process of continual improvement and should by no means lead to ‘analysis paralysis’ and waterfall design.

1 Like
#8

I’m not sure I understand what you suggest. I sense there is something but I don’t see it. Sorry for being slow today :blush:

#9

Mail template to invite people to the affinity mapping session. In French because most of the interviews are in French. And also because it has to be IRL and in Paris. Sent to:

Bonjour,

Depuis le début de cette année je suis impliqué dans un projet de fédération des forges[0] qui, pour faire court, vise a permettre de sortir de la domination de GitHub sur le développement logiciel libre. Dans une optique “user centric”, le projet débute par une étape de User Research durant laquelle une dizaine d’interview ont été réalisées et transcrites[1]. La prochaine étape consiste à analyser ces transcriptions en suivant un process dit “affinity mapping”[2] et c’est à ce sujet que je t’écris.

L’idée générale consiste à découper les interview et les classer par thème. Les participants à la session d’affinity mapping regroupent et classent les thèmes, en discutant et confrontant leurs idées. Lorsque la liste des thèmes est établie, une dernière étape consiste à les classer par importance. Les trois plus importants sont dit les thème “émergents” et déterminent l’orientation du projet fedeproxy pour l’avenir. Pour illustrer ça plus concrètement tu peux jeter un oeil à une session réalisée il y a deux ans dans le cadre de la publication d’un dépôt Open Data venant de l’assemblée[3] et la façon dont cela ressort dans le rapport[4].

Malgré de vaillantes tentatives pour faire cela en ligne, c’est très peu fructueux et il est préférable de le faire en présence. Si cela te tente et si tu as une demi journée pour y participer, ce serait vraiment formidable. La date n’est pas encore fixée mais ce sera entre mi-mai et mi-juin sur Paris, en fonction des contraintes des un·es et des autres.

Qu’en dis-tu ?

A++

[0] https://fedeproxy.eu
[1] Preparing the User Research
[2] https://www.nngroup.com/articles/affinity-diagram/
[3] https://forum.en-root.org/t/affinity-mapping-for-data-tricoteuses-fr/140
[4] https://forum.en-root.org/t/user-research-report-developers-and-dataset-repositories/164

Diversity: continuous improvement
#10

@misc suggested to contact https://www.duchess-france.org/.

1 Like
#11

Great idea! I’ll do that tomorrow… unless someone else is willing?

#12

I will reword and translate an email targeting a Chinese developer.

1 Like
#13

Message sent this morning on their event chat:

Le projet de fédération des forges logicielles (GitHub, GitLab, Gitea etc.) fedeproxy cherche des participant·e·s pour l’analyse des interview sur le thème: “comment développez-vous avec plusieurs forges ?”. Si vous êtes disponibles le 28 mai, c’est une demi journée en présentiel (oui, ça se fait rare ) à coté de la gare Montparnasse à Paris. Si vous êtes interessé·es il suffit d’envoyer un message à https://mastodon.online/@fedeproxy (oui, c’est un projet de décentralisation donc pas de twitter ni de facebook, c’est aussi assez rare ) ou venir discuter sur le chat qui (attention il y a un thème ) … n’est pas slack.

duchess

Diversity: continuous improvement