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
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
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
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.