Recap of Events UX sessions for

The other week the Mozilla Reps website team met to improve the user experience for interacting with events on the website. Holly Habstritt Gaal from the Mozilla UX team guided us through the process in a series of four sessions, and this post shares a high-level view of what we created.

Discussing new UX concepts

Discussing new UX concepts

Our sessions took us through the user experience design process we adapted from Design Staff, and each session covered one stage — Understand, Diverge, Decide, and Prioritize. The group included people who work on back-end development, front-end development, quality assurance, visual design, product management, web product management and program management.

We started the first session by considering our goals, success metrics and user types. We then reviewed website analytics, research and user feedback to give us additional information. Based on that context we were able to create a problem statement:

We are not making events easy to organize, discover, or measure. We will design a better experience for the core needs of Reps and Mozillians, such as gaining new contributors and supporting Mozilla initiatives.

In our second session, we identified six types of tasks for improving events:

  • Organize. Make it easy for Mozilla Reps to create and manage events.
  • Discover. Make it easy for people to find relevant events.
  • Measure and validate. Demonstrate the impact of events and how those events further Mozilla initiatives.
  • Integrate. Improve information flow with internal/external services.
  • Promote. Add ways for users to share events.
  • Call to action. Add new calls to action (CTAs) for users.

With these tasks in mind, we individually sketched ideas using markers and paper to brainstorm solutions to these tasks. We held another round of sketching to refine the ideas, and then we shared our concepts with the group and discussed them to raise concerns, assumptions and alternative solutions.

Sharing a sketch

Sharing a sketch

Our last two sessions helped us solidify our ideas and decide how we would prioritize them. For our third session we reviewed our seven concepts in more detail and talked through user stories for them. In our last session we prioritized these tasks amongst each other and also talked about how we want to sequence them as part of our work during the rest of this year (Q3 and Q4).

As we wrapped up our sessions on day two, we had a clear understanding of what we want to accomplish and the priorities for implementing those concepts. We will now create specifications for those ideas, prioritize them amongst our other non-events projects and identify any other resources we need. In a short amount of time, we certainly accomplished a lot!

A framework for designing a better user experience

The Mozilla Reps website team recently met to plan how to make our event tools easier and more valuable. We are a bootstrapping team, so this is the first time that we have worked closely with user experience and visual design experts Holly and Lee. This opportunity was a special treat for our team, and I think it also gives us a strong framework for improving the user experience in other areas of the Reps Portal. I am going to use this post to share the process we used, and I believe other teams can benefit from using this approach as well.

Defining our process

To guide us through our sprint, we adapted the product design sprint five-day recipe from the good people at Design Staff. We changed the recipe a bit since we were meeting remotely and not creating a prototype just yet. Overall the team really liked this approach.


To help us prepare for the meetings, Holly shared guide documents detailing the sessions and included questions for us to think about in advance. We also created a quick survey for Mozilla Reps, our main users, to give us feedback and ideas about event functionality on the Reps Portal. The responses we received gave us some great insights that drove our discussion and concepts. Before the meetings each of us was asked to look at other event sites for inspiration as well.


We met for four two-hour sessions on Monday and Tuesday, and each session was focused on a different stage of the user experience design process. During these meetings we discussed, brainstormed, sketched, conceptualized and identified assumptions and concerns. We started by defining our opportunity and finished by prioritizing our new concepts and solutions. This is a thorough process that helps the team gain a common understanding of what we want to accomplish and then find solutions we can use. Here’s what we set out to do in each session:

  • Understand. Dig into the design problem through research, competitive review, and strategy exercises. End up with user story that we all agree on to move forward.
  • Diverge. Rapidly develop as many solutions as possible.
  • Decide. Choose the best ideas and hammer out our user stories.
  • Prioritize. Choose what order to work on ideas.

Working virtually

Our team is spread out around the world, so we used Vidyo video conferencing to meet in a virtual room and we created a shared folder of documents and images for each step in the process. Because our team spans eight timezones, not everyone could join every session, but at the start of each session we reviewed our previous work so everyone had the same context.

Sharing our ideas over video

Sharing our ideas over video

To share our designs and ideas, we made heavy use of screen sharing and showing paper sketches using webcams. While we took lots of notes, I found the paper sketches to be the most useful tool for our sessions. In a few minutes we could draw out ideas and share concepts with each other. We also took photos of all the sketches that we added to our shared documents folder.

Next steps

Now that we have a solid understanding of how we want to improve our event tools, we can start executing on our concepts. In the next week we will start creating specifications and filing bugs. We’ll prioritize our events work amongst our other Reps Portal projects as well.

State of the Reps Portal

There are lots of exciting things happening with the Mozilla Reps website, and I want to give an update on where things stand and share what’s coming next. continues to be a key way for Mozilla Reps to organize and report their activities continues to be a key way for Mozilla Reps to organize and report their activities

The Reps Portal gets about 250 visitors each day, which is pretty impressive considering there are just under 400 Reps. The average person visits the site for 4 minutes 18 seconds. Amazingly, Reps are organizing and participating in over 1,000 events each year. Reps are organizing more events than any other group in Mozilla.

The core functionality of the Reps Portal is composed of profiles, events, monthly reports and a dashboard. Most recently, we have released a voting feature so Reps can vote and comment on polls, which help different groups and the program as a whole make decisions. We’re also planning to use the voting feature to approve swag and budget requests for events.

Some of the most useful tools are highly specific. Here are two powerful features that you may not have noticed yet:

  • You can automatically add events that interest you to your calendar. On the events page, search for a location or any keyword, click the Advanced Options icon, and choose Export iCalendar. This will add a feed of those events to your personal calendar.
  • You can send an email to Mozillians attending an event. On an event page, simply click on Mail attendees.

Even with a great site, there is plenty more we can do. We are working to improve how you interact with events on the site, switch to a better reporting system, and show more insights and actionable items on your dashboard.

The team working on the Reps Portal continues to grow, and we have 14 people contributing to the site. Take a look at our team page to get to know everyone, and stop by #remo-dev on IRC or post on ourĀ discussion forum. We are a fun group!

Preparing for continuous delivery

The Mozilla Reps web development team is starting to move toward continuous delivery so that we can deliver features faster while maintaining or increasing the quality of code deployed to

Continuous deployment is the holy grail of application development. It reduces bottlenecks between stages of the development process, allowing the team to move faster and be pretty confident in the quality of the code. Once in place, it can also reduce the work to test and release new functionality. We think it’s a win for everyone.

It also means pushing every code change to a production environment (that’s the deployment part). Our team is interested in a variation of this called continuous delivery, which means that we have the ability to push to production at any time. This will give us more flexibility, since we’ll be able to separately make code changes and update the site when it is most convenient for the team.

What do we need to build to move to continuous delivery?

  • Continuous integration server
  • Source control commit check
  • Simple deployment script
  • Real-time alerting
  • Root cause analysis
  • Dark Launch and Feature Flipping
  • Redefine relationship between QA and WebDev
  • Re-evaluate branch management and staging environments
  • Higher standards for code reviews

Giorgos has provided more information about each of these, and I will publish another post that goes into detail about each one.

This is a big undertaking, and it will take us several months to fully implement continuous delivery. If you’d like to give feedback or ask questions about this project, please post in the discussion forum or stop by #remo-dev on IRC. You can also follow along with the project by watching our tracking bug.