Mozilla Community Portal


Making it easier for people around the world to contribute to Mozilla’s mission of making the web more open and accessible to all.

Campaigns and Activities pages

As a key part of their Mission-Driven Mozillians strategy program, the Community Development team at Mozilla were looking to build a centralized place where their enthusiastic volunteers could collaborate, organize events, and contribute to campaigns or activities.

Playground worked closely with Mozilla community managers to build a portal that was truly useful to their contributors, and leveraged entirely open source Wordpress plugins.

The problem

The existing contributor experience was disjointed, redundant, and dated. Volunteers were using several different platforms under separate accounts and it was difficult to create communities or locate relevant events to attend. There were 3 different websites that community members used at the time that would end up being replaced by the portal– Mozilla Activate, Mozilla Events, and Mozilla Reps.

Mozilla Activate, Events, and Reps sites

Success meant combining and improving on the functions of the separate platforms into one portal, leveraging modern open-source technology, to make it easier for volunteers to contribute to Mozilla’s mission.

Mozilla community members needed:

  • to discover and create communities
  • to find impactful activities
  • exceptional contributors or groups to be formally recognized by Mozilla

Mozilla community managers needed:

  •  to be able to direct community actions
  • to regulate brand and community affiliation
  • to access insightful user data through the CMS

What we built

Our Playground team consisted of a PM, myself and another designer, and 2 developers.

To keep within the project’s scope, we built the entire platform in Wordpress, leveraging BuddyPress and Events Manager plugins. Though there were constraints around the product's capabilities as a lot of the user flows were dictated by those plugins, the design and dev team worked closely to agree on smart trade-offs around what was nice to have and what was realistic.



Groups are a way for people to meet and connect over specific interests or causes related to Mozilla. People enthusiastic about Mozilla in a certain city or province or country can join a group together, and create events to connect with one another, or chat in Discourse (Mozilla’s preferred message board). Community managers can verify particularly active groups to highlight their quality contributions.



Community members can create events to facilitate collaboration together on Mozilla-related initiatives. Events can be in-person gatherings or online meetings, and linked to groups, campaigns or activities. Filters for location, tags, and language can better help someone find an event relevant to their interests. An event details page also links out to related events to encourage the discovery process.


Campaigns and Activities

Though we collectively refer to both as initiatives, there are key differences between campaigns and activities.

Campaigns are promotions for specific ways that people can help out with Mozilla’s various initiatives, promoted within a certain timeframe. Campaigns are considered active for a short period of time, which helps community managers measure engagement and outcomes.


Similarly, activities also provide ways that people can participate in donating their time or skills to Mozilla initiatives, but they’re considered “evergreen”, and don’t involve a time limit or a particularly concentrated promotion.
Anyone looking for a way to contribute can find an activity to jump into at any time, while campaigns become archived after their active period.



The people page is the repository of all community members, where people can find and connect with one another, filtering by tag, language, and location. Members have a lot of flexibility around the details of their information of their profile page, and can link their groups, participation in initiatives, events they’ve attended, and tags they’re interested in.


Key obstacle

Account creation

Initially when designing the create account flow, a new member would be able to fill out their entire profile upon signup. However, profile details are so extensive that we figured the process could feel daunting rather than motivating and could be a barrier to signing up.

We decided to split the account details into two processes. On signup, only the most pertinent fields would be visible, and most of them would be auto-populated if the person had signed up with Auth0, to make the process even easier. After they'd created their account, they would be able to edit their profile details and fill in all of the rest of the info that's relevant and valuable to the community– bio, interests, social media, tags, and the like.

the Complete Profile screen alongside the Edit Profile screen

We also needed to make the customizable privacy options super clear. Usernames would always have to be public, and First Names would always need to be visible to other registered users, but otherwise the content in all other fields could be hidden. They could also be customized at quite a granular level.

We needed to make all of these options, and the reasons behind the exceptions, very clear to the community member without overloading them with information.

The privacy options for member profiles laid out in a grid

There was a parallel project,, that we had to align our UI with. Based on an element on that site, we created a version with toggles as a future option, (but in the interim we went with dropdowns as the clearest and easiest way to convey and execute this customization.)

Edit profile screen, with toggles to customize visibility settings

It would have been interesting to have been able to A/B test the profile signup flow, or to see the impact of the profile signup decision we’d made– because it seems that most users ended up with the default with all visibility settings automatically set to private. Referring to our comp of a completely filled out profile page as the expected default ended up being unrealistic.

One regret I have is that I wish we aligned closer to’s profiles and the way the categories appear visible but empty rather than removed completely from the page. Empty zero states might have been much more incentivizing to fill out rather than simply an empty-looking profile.


Campaign page builder

Campaigns are promotions for specific ways that people can help out with Mozilla’s various initiatives. They’re meant to encourage volunteers to contribute towards a specific cause, promoted within a certain timeframe.

For instance, the Common Voice Single Word Campaign was a 2-week push to get as many contributors as possible to create a recording of them saying the digits zero through nine, and the words yes and no in different languages, in an effort to help train Mozilla’s open source voice recognition engine.


The existing landing pages per campaign varied widely in length and content type, unlike activity pages which followed a predictable and standard structure.

As there wouldn't be a single page structure that would cover every need, I designed a thorough template builder. Built to be future proof, with utmost flexibility and responsive considerations, campaign pages are robust and seamlessly visually integrated with the rest of the site.

However, in practice (and as might be expected with templates), the campaign builder could have benefitted from a more thorough user guide or do/don’t suggestions.

An example of the elements used in the campaign page builder

What I learned

I went on maternity leave shortly before the design phase of the project ended, so I wasn’t present to help with design QA. Looking back I wish I’d have planned better and prepared some guidelines of design details to account for. I would have loved to contribute to some of these solutions– for instance, more thinking on options for group profile images that didn’t span the width of the card.

A comparison of our pixel perfect comp vs the less-perfect reality of the live Groups page

I also learned there was an opportunity to have created clearer usage guidelines for design best practices. We didn’t account for instances like in the below example, where custom HTML had been added to make the content in a field span 2 columns, and had added buttons. The polish of our mockups didn’t always translate to real life.

a single Activity page mockup alongside a live single Activity page

Defining success

The community portal was an integral piece of the Mission Driven Mozillians initiative, supporting contributors who help further the cause of making a more open and accessible internet experience.

We’ve seen a lot of positive feedback so far that cements the importance of what we came together to build.

"I started my activities with Mozilla five years ago, and I remember how hard it was to find people, events, and stuff happening around my area...If we had the portal back there, probably our life would have been easier. I’m thrilled and excited to see what we will achieve with this new hub for volunteers!"


©2021 Lindsay Sto Tomas. Happy to love what I do.