Marie-Cécile Godwin Paccard is an independent designer and UX researcher. She supports individuals and organizations in defining their fundamental values and objectives by providing a systemic perspective. Her aim is to gather a deep understanding of people’s usages and to develop usable, ethical and inclusive tools.

Hello Marie-Cécile! You have helped the Mobilizon project team understanding the needs and uses of the people who will use it. Can you explain why it is particularly important for this project to consider the needs and expectations of future users?

Hello to the whole team! Studying needs and uses is essential if you want to design a software, a service or even an object to make it usable. Mobilizon’s purpose is to empower people to organize and gather together, and enable them to do it freely and with tools that respect their privacy. Therefore, it is instrumental to start talking about "uses" and "usage" at the very beginning of the thought process! The whole team wishes that existing communities take ownership of Mobilizon and that new communities are created. If we want this to succeed, we have to make the effort of reaching out to people in order to understand their needs, which problems they face every day and how they managed to overcome them so far, if they did.

When designing things which are meant to be used by people, you have to fight the urge to rely on your own assumptions, beliefs or fixed ideas. You have a duty to open your mind to the perception and experience of others. A quick "usage research" phase can give fast and valuable results and allow you to put a finger very early on problems and objectives you had not overseen yet. It helps questioning your first assumptions and take better decisions at a crucial stage of the project’s definition.

What was your approach to collect voices of these users and communities?

First, the team and I spent some precious time reflecting on the project’s purpose and ambitions, but also its political implications (because everything is political, especially in design and free softwares) as well as how Mobilizon would fit into Framasoft’s strategy. We reviewed the existing event organizing platforms and how they prevent people from organizing easily and freely. From there, I suggested a usage research plan to the team, to clearly define what we were going to focus on in the research phase. We launched a first online survey, which received nearly 300 responses. In this survey, we asked people about how they generally organize and gather using digital platforms, either as guests or as organizers. We collected valuable information on the problems they usually face, and which tools they would use or not, and why.

In a second step, we defined which kind of communities we wanted to interview. Once more, it was essential to start from "usage" and not socio-economic groups. Among others, we decided to seek out to some large, multi-layered communities who run public gatherings such as climate marches, specific communities who run events that are more niche or themed, and organizations for who privacy is very important, both for themselves and their event participants. I then started looking for people matching these usecases and asked them questions about how they organized themselves before, during and after an event. At this point, we are not talking about software, code or graphics yet: we are still focusing on the uses, the reality of organizing events and the real problems faced by the people who set them up.

How does this data contribute to the thought process to design Mobilizon’s functionalities?

Once the research phase is completed, we can draw conclusions from the collected data. We have a more precise vision of the reality of people’s uses and we can take informed decision about how to design a software that will fit them. The data will be a framework for decisions all along the design and coding process.

Some elements speak for themselves right away: if a specific problem pops up through practically all the interviews, it means that I have to keep it in mind throughout the design and development process and find the best way to solve it. Of course, there are human problems that Mobilizon will not be able to solve, for example the phenomenon of "no-show": people who say they will come to an event but do not show up in the end. Even if it is hard to tackle this behavioral issue with software, understanding why it bothers organizers will allow us us to take better decisions later on.'

Mobilizon is not meant to be a "one size fits all" software. Priority will be given to functionalities that seem essential to small communities for whom Mobilizon could be a game changer, both means and cost wise. But it will definitely not be able to replace Mattermost or WhatsApp and will never have the same firepower as Facebook. But Mobilizon will provide essential features so that the communities most vulnerable to surveillance capitalism can migrate out of the big platforms. Some organisations might still need hundreds of nested pads or Discord’s easy multi-user voice conversations!

Now that the research phase is mostly done,I am designing Mobilizon’s back office structure as well as the whole set of tools that will make it possible to create an event, a group or invite people in these groups to collaborate prior to an event. I am also working on how the concept of "identities" will be articulated. This functionality will make it possible for users to create different "facets" of their identity so they can compartmentalize some aspects of their social life. Last but not least, the moderation system is on my design list too!

The team and I still have a lot of questions to answer, for instance how Mobilizon will support people in the understanding of federation / instance concepts. We want to make sure that people get all the data they need to make the best informed decision for them and their community, be it if they choose to create an account on a specific instance or if they choose to have their own. This shall be applied on many facets of the software design, for instance during the on-boarding phase, or how the principles of instances and federation will translate in the interface.