The products we build get more design attention as our Firefox UX team has grown from about 15 to 45 people. Designers can now continue to focus on their product after the initial design is finished, instead of having to move to the next project. This is great as it helps us improve our products step by step. But this also leads to increasing efforts to keep this growing team in sync and able to timely answer all questions posed to us.
Especially for engineers and new designers it is often difficult to get timely answers to simple questions. Those answers are often in the original spec, which too often is hard to locate. Or worse, it may be in the mind of the designer, who may have left, or receives too many questions to respond timely.
In a survey we ran in early 2017, developers reported to feel they
spend too much time identifying the right specs to build from,
spend too much time waiting for feedback from designers, and
spend too much time mapping new designs to existing UI elements.
In the same survey designers reported to feel they
spend too much time identifying current UI to re-use in their designs, and
spend too much time re-building current UI to use in their designs.
All those repetitive tasks people feel they spend too much time on ultimately keep us from tackling newer and bigger challenges. ‒ So, actually, let‘s not spend our time on those.
Let’s help people spend time on what they love to do.
Let’s build tools that help developers know what a given UI should look like, without them needing to wait for feedback from designers. And let’s use that system for designers to identify UI we already built, and to learn how they can re-use it.
We are happy to receive feedback and contributions on the current content of the system, as well as on what content to add next.
Photon Design System
Based on what we learned from people, we are building our design system to help people:
find what they are looking for easily,
understand the context of that quickly, and
more deeply understand Firefox Design.
Currently the Photon Design System covers fundamental design elements like icons, colors, typography and copy-writing as well as our design principles and guidelines on how to design for scale. Defining those already helped designers better align across products and features, and developers have a definitive source to fall back to when a design does not specify a color, icon or other.
With all the design fundamentals in place we are starting to combine them into defined components that can easily be reused to create consistent Firefox UI across all platforms, from mobile to desktop, and from web-based to native. This will add value for people working on Firefox products, as well as help people working on extensions for Firefox.
If you are working on Firefox UI
We would love to learn from you what principles, patterns & components your team’s work touches, and what you feel is worth documenting for others to learn from, and use in their UI.
Like many organizations, Mozilla Firefox has been experimenting with the Google Ventures Design Sprint method as one way to quickly align teams and explore product ideas. Last fall I had the opportunity to facilitate a design sprint for our New Mobile Experiences team to explore new ways of connecting people to the mobile web. Our team had a productive week and you can read more about our experience in this post on the Sprint Stories website.
What is the most important thing to do in preparing for a Sprint?
“The most important thing is planning, planning, and then more planning. I want to emphasize the fact that there are unknowns during a Design Sprint, so you have to even plan for those. And what that looks like is the agenda, how you want to pace the activities, and who you want in the room.” — Ratna Desai, Google UX Lead
When I was planning my first Design Sprint as a facilitator, I was grateful for the detailed daily outlines in the GV Library, as well as the Monday morning kickoff presentation. But, given the popularity of Design Sprints, I was surprised that I was unable to find (at the time at least) examples of daily presentations that I could repurpose to keep us on track. There is a a lot to cover in a 5 day Design Sprint. It’s a challenge to even remember what is coming next, let alone keep everything timely and orderly. I relied heavily on these Keynote slides to pace our activities and I hope that they can serve as a resource for other first time Design Sprint facilitators by cutting down on some of your planning time.
These slides closely follow the basic approach described in the Sprint book, but could be easily modified to suit your specific needs. They also include some presenter notes to help you describe each activity. Shout out to Unsplash for the amazing photos.
10:00 — Introductions. Sprint overview. Monday overview. 10:15 — Set a long term goal. List sprint questions. 11:15 — Break 11:30 — Make a map 12:30 — Expert questions 1:00 — Lunch 2:00 — Ask the experts. Update the map. Make “How might we” notes. 4:00 — Break 4:15 — Organize the HMW notes. Vote on HMW notes. 4:35 — Pick a target
We launched Focus as a free content blocker for Safari on iOS back in December 2015. The idea was to bring control back into users’ hands. We wanted to let them dictate how they wanted to spend their browsing data, even if they weren’t using Firefox.
About a year later, we wanted to give the product an update. We wanted to experiment more on Mobile. But how?
What if we could give mobile users an app that only allowed private browsing?
Our team was very small. So we needed to set expectations early — who’s responsible for what?
We tried to stay focused (heh) on a small set of well-defined goals. Everyone had a part to play. A clearly defined timeline helped us avoid scope creep too. It set the tone for our discussions and made it a lot easier to prioritize issues.
We had weekly check-ins to make sure everyone was on the same page. All of our meetings were clearly directed and to the point. As things came up they would also be filed as GitHub issues so we always had a way to track our discussions.
It’s important to remember that getting 100% consensus is pretty much impossible. But “moving together” doesn’t necessarily mean everyone has to think the same. It’s natural to have doubts. Trust each other and try to move forward as a team. Define what success looks like together. Then go out, and gather some data.
Share early and often
Even if you aren’t finished, design comps/mock ups can really help provide a shared vision. Try to share them more! I’m guilty too sometimes. I know it can be hard. But I’ve always been glad that I did.
Where possible, we made all design changes “on device” using Buddybuild. This helped us arrive at decisions quicker, and with more confidence. It was great for design and engineering issues but it also kept the entire team in sync (especially useful when working across offices and timezones). Basically, it was our way of sharing early and often.
Then there was Slack . Lots of it. Our team was small, but distributed. Slack made it easy for anyone to give feedback, report/resolve GitHub issues, or even just give an encouraging 👍.
Sharing early might have pitfalls too. But it can get everyone involved and excited about the final product. Visual mock ups create a common language and helps avoid miscommunication later on. Share the vision, spread the workload. Insightful feedback can uncover interesting opportunities, but don’t let criticism stall you either.
Originally, Focus was a slightly different product. I didn’t work on the first version myself (that was mostly Darrin) but Brian (one of our engineers) did.
As designers, we should be opinionated but we also need to be flexible. Whatever decision we arrive at right now might not be ideal, but maybe that’s OK. Who knows, maybe sometimes we don’t have the right answer. Remember, it’s iterative!
Brian and I shared the same timezone but not the same office. So we spent a fair amount of time on Vidyo. Being on a video call over a long period of time can be really tiring. But it helped us hammer out the details quickly. When something didn’t make sense, we didn’t have to wait for the next weekly meeting to chat.
This is probably terrible of me, but I actually didn’t have a “full design spec” until towards the end of the project.
Unfortunately, there isn’t a one-size-fits-all type of solution here. For us, Vidyo and Slack made the most sense but there were still drawbacks. Everyone’s different. Every team is different. Find a solution that works for you and your team. The key is to be flexible, to adapt.
There are always more opportunities to learn, and to grow. Within our products and ourselves as practitioners too. In the end, I really think it’s a constant process.
If you’re interested in contributing, here are the GitHub repos for Firefox Focus on iOS, and Android. Currently, we’re working towards the initial release of Firefox Focus on Android. Send any feedback, questions and comments you might have!
My name is Philip Walmsley, and I am a Senior Visual Designer on the Firefox UX team. I am also one of the people tasked with making addons.mozilla.org (or, “AMO”) a great place to list and find Firefox extensions and themes.
There are a lot of changes happening in the Firefox and Add-ons ecosystem this year (Quantum, Photon, Web Extensions, etc.), and one of them is a visual and functional redesign of AMO. This has been a long time coming! The internet has progressed in leaps and bounds since our little site was launched many years ago, and it’s time to give it some love. We’ve currently got a top-to-bottom redesign in the works, with the goal of making add-ons more accessible to more users.
I’m here to talk with you about one part of the add-ons experience: ratings and reviews. We have found a few issues with our existing approach:
Some users just want to leave a rating and not write a review. Sometimes this is referred to as “blank page syndrome,” sometimes a user is just in a time-crunch, sometimes a user might have accessibility issues. Forcing users to do both leads to glib, unhelpful, and vague reviews.
On that note, what if there was a better way to get reviews from users that may not speak your native tongue? What if instead of writing a review, a user had the option to select tags or qualities describing their experience with an add-on? This would greatly benefit devs (‘80% of the global community think my extension is “Easy to use”!’) and other users (‘80% of the global community believe this extension is “Easy to use”!’).
We don’t do a very good job of triaging users actual issues: A user might love an extension but have an (unbeknownst to them) easily-solved technical problem. Instead of leaving a negative 1-star review for this extension that keeps acting weird, can we guide that user to the developer or Mozilla support?
We also don’t do a great job of facilitating developer/user communication within AMO. Wouldn’t it be great if you could rectify a user’s issue from within the reviews section on your extension page, changing a negative rating to a positive one?
So, as you can see, we’ve got quite a few issues here. So let’s simplify and tackle these one-by-one: Experience, Tags, Triage.
The star rating has its place. It is very useful in systems where the rating you leave is relevant to you and you alone. Your music library, for example: you know why you rate one song two stars and another at four. It is a very personal but very arbitrary way of rating something. Unfortunately, this rating system doesn’t scale well when more than one person is reviewing the same thing: If I love something but rate it two stars because it lacks a particular feature, what does that mean to other users or the overall aggregated rating? It drags down the review of a great add-on, and as other users scan reviews and see 2-stars, they might leave and try to find something else. Not great.
What if instead of stars, we used emotions?
Some of you might have seen these in airports or restrooms. It is a straightforward and fast way for a group of people to indicate “Yep, this restroom is sparkling and well-stocked, great experience.” Or “Someone needs to get in here with a mop, PRONTO.” It changes throughout the day, and an attendant can address issues as they arise. Or, through regular maintenance, they can achieve a happy face rating all day.
What if we applied this method to add-ons? What if the first thing we asked a user once they had used an extension for a day or so was: “How are you enjoying this extension?” and presented them with three faces: Grinning, Meh, and Sad. At a very high level, this gives users and developers a clear, overall impression of how people feel about using this add-on (“90% grinning face for this extension? People must like it, let’s give it a try.”).
So! A user has contributed some useful rating data, which is awesome. At this point, they can leave the flow and continue on their merry way, or we can prompt them to quickly leave a few more bits of even MORE useful review data…
Writing a review is hard. Let me rephrase that: Writing a good review is hard. It’s easy to fire off something saying “This add-on is just ok.” It’s hard to write a review explaining in detail why the add-on is “just ok.” Some (read: most) users don’t want to write a detailed review, for many reasons: time, interest, accessibility, etc. What if we provided a way for these users to give feedback in a quick and straightforward way? What if, instead of staring down a blank text field, we displayed a series of tags or descriptors based on the emotion rating the user just gave?
For example, I just clicked a smiling face to review an extension I’m enjoying. Right after that, a grid of tags with associated icons pops up. Words like “fast”, “stable”, “easy to use”, well-designed”, fun”, etc. I liked the speed of this extension, so I click “fast” and “stable” and submit my options. And success: I have submitted two more pieces of data that are useful to devs and users. Developers can find out what users like about their add-on, and users can see what other users are thinking before committing to downloading. We can pop up different tags based on the emotion selected: if a user taps Meh or Sad, we can pop up tags to find out why the user selected that initially. The result is actionable review data that can is translated across all languages spoken by our users! Pretty cool.
Finally, we reach triage. Once a user submits tag review data, we can present them with a few more options. If a user is happy with this extension and wants to contribute even more, we can present them with an opportunity to write a review, or share it with friends, or contact the developer personally to give them kudos. If a user selected Meh, we could suggest reading some developer-provided documentation, contacting support, or writing a review. If the user selected Sad, we’d show them developer or Mozilla support, extension documentation, file a bug/issue, or write a review. That way we can make sure a user gets the help they need, and we can avoid unnecessary poor reviews. All of these options will also be available on the add-on page as well, so a user always has access to these different actions. If a user leaves a review expressing frustration with an add-on, devs will be able to reply to the review in-line, so other users can see issues being addressed. Once a dev has responded, we will ask the user if this has solved their problem and if they’d like to update their review.
We’ve covered a lot here! Keep in mind that this is still in the early proposal stage and things will change. And that’s good; we want to change this for the better. Is there anything we’ve missed? Other ideas? What’s good about our current rating and review flow? What’s bad? We’d love constructive feedback from AMO users, extension developers, and theme artists.
Please visit this Discourse post to continue the discussion, and thanks for reading!
Philip (@pwalm) Senior Visual Designer, Firefox UX
Rollie started rapping many years ago, and since the beginning, Dollie was with him. In fact, when Rollie was born, Dollie was already a puppy. Dollie doesn’t talk, but with her expressions she can support Rollie before his concerts. Rollie already recorded many songs and videos, in which Dollie always appear. Dollie is also a theme in many of Rollie’s songs. She is the only dog Rollie ever had and besides of being close like siblings, Dollie is an inspiration for Rollie. Rollie wrote songs in which he talks of Dollie as his sister and he is going to sing it in his next concert. Now Rollie and Dollie doesn’t know if it’s a good idea to give milk to their dog.
Right now, Project Prox is taking shape as a mobile-first application on iOS. Starting with your location, we look for interesting places and events near you. That’s where our focus is at the moment — the here and now.
Yes, there are also other parts to this story too. But we’ve decided that focusing on this part of the “Traveller’s” journey right now makes the most sense. This was also something we touched on during our Design Sprint. If you’d like to know more (and haven’t already), you can read more about that process here.
But I don’t have an iPhone… why is it only on iOS?
Believe it or not, “only make this for iOS” wasn’t one of our goals. But with all our constraints, we felt that the iOS platform was the best place to start. We definitely want to expand to other platforms in the future. This came down to a matter of resourcing, time constraints, and the usual like.
It’s important to call out our goal here: to solve real user/people problems. We want to understand the problem space and provide user value through iterative research and design.
Is this something Mozilla should be doing?
When you think about Mozilla, it’s pretty much synonymous with Firefox. But surely that’s not the only way we can carry out our mission, is it?
Our mission is to ensure the Internet is a global public resource, open and accessible to all.
How do we define “the Internet”? It takes so many different forms nowadays. We might know what it looks like today, but what about the future? How will technology influence the way we interact with “the Internet” then?
Not too long ago, Mobile was the future. Now, the web platform itself is growing. Chrome’s Accelerated Mobile Pages, and Progressive Web Apps give us the ability to create new, better experiences for the mobile Web.
If we want to ensure that the mobile Web is also “open and accessible to all”, we need to grow the influence of the mobile Web too. We need to be open to new technology and consider all the different ways people are (and will be) accessing this information.
Ok, so what does Project Prox look like?
As soon as you open the app, we want to provide immediate value. Our goal is to enable easier decisions about what to do or where to go next. So, without even knowing what to start searching for, we want to leave you with a satisfying day.
This should work regardless of whom you’re connected to, because your social network shouldn’t be a prerequisite for getting the most from the web.
For those looking for a less immediate perspective, we also included a “Map View”. This was actually not something we tested in our Sprint. But the intention here was to offer an alternative view for users to give them more context about their surroundings. The goal here was to give users a better sense of spatial awareness.
Although we never finished it in time for Kona, we still got a lot of helpful feedback that is going to help us iterate and test this more for the next version.
Last but not least, notifications! If you’re nearby an event, we’ll notify you so that you can decide if you’re interested or not. The nuances of notifications makes this helluva lot trickier. But more than anything, we want to be useful without being annoying.
Keep in mind, all of this is still a work-in-progress. We’re going to continue iterating with the help of our User Research team until we have something we’re happy with.
All in all, it’s just too early to tell. Kona was our first announcement but we’ve yet to actually launch the product. But we do have a clearer picture of what success might look like for us.
We’re calling this a “V1” — so there’s lots of work to be done still. We’re going to address some of the feedback and bring the product to a level we’re comfortable with calling an MVP before releasing to a larger population. And obviously, it works better in some cities versus others.
We need to get more data and gather more feedback. Improving the experience and releasing the updated product in a larger, denser city will be our next challenge. What we learn there will help us determine the appropriate next steps.
If you’re interested in giving feedback, please reach out!
A recently landed feature in the experimental Firefox Nightly build integrates proactive tracking protection for Firefox Nightly users coupled with Do Not Track (DNT). With tracking protection active, ads and tracking technology are blocked before they reach the user’s browser. Subsequently, tracking ads and tracking pixels are not loaded by the browser and are not visible to the user. Further, by not loading the ads, tracking protection speeds up page load times.
In January 2015, the Firefox user research team conducted a three-day diary study with twelve demographically-diverse Firefox users in the US to understand their experience with Firefox Nightly’s implementation of Polaris tracking protection. For the diary study, participants were asked to download and install Firefox Nightly. Participants were instructed to turn on Tracking Protection in Firefox Nightly use it as their primary browser for the duration of the study. Participants responded to cues and direct questions while keeping notes of their daily online activities. After the diary study was completed, we conducted hour-long follow-up interviews with four of the participants via Vidyo.
We wanted to answer the following questions:
What does “tracking protection” mean to participants? How do they define it? How do they believe it works?
How does the implementation of tracking protection in Firefox Nightly match participants’ mental models of what tracker blocking means?
Does tracking protection disrupt participants’ current experience of browsing the web?
Findings and Observations
Definitions of Tracking and Tracking Protection Most participants understood that tracking involved a third party using a tool or technology to identify unique browser users and to collect data about those unique users’ activity online. Participants provided different descriptions of how they believe tracking works and what information being tracked. Most participants used more general vocabulary to describe the more tangible aspects of tracking, such as tracking technologies track “my likes based on my website visits” (P15) or “what I might be interested in.” (P10) A small number of participants described the technical details of how online tracking works with a high level of accuracy.
Who Do Participants Believe is Tracking Them? Overall, the majority of participants were able to describe at least one or many employers of tracking technology. While most participants did not describe the ecosystems of tracking and the relationships among companies involved in tracking, they did mention the piece of tracking technology that is most visible to them: targeted ads.
We also asked all the participants: “who do you believe is tracking you online?” Most participants mentioned Google, Facebook, or “marketing companies.” Two participants said the US government was engaged in tracking online activities
Benefits about Tracking Protection Feeling more secure and private. The most commonly cited benefit among participants was the feeling of greater security and greater privacy. Although some participants who said this did not articulate specifically how tracking protection worked or made them feel more private and secure. Some participants clearly believe the tracking protection feature’s labeling and/or its visible effects (e.g., blocking the display of some ads).
Fewer ads, less clutter. Among the participants who noted the absence of targeted ads with tracking protection on generally viewed the absence of targeted ads as positive benefit. Most of these participants viewed ads as “clutter” (P2) on a site or as a “distraction” (P4) from their intended browsing activities. A few of these participants said that they have sometimes found targeted ads helpful, but also said they did not miss the ads when they were absent.
Faster page loading. Some participants believed tracking protection speeded up their browsing experience by blocking tracking technologies that took extra time to load on a page. This extra speed was seen as a benefit. In our follow-up interviews, two participants believed that tracking protection slowed down their browsing because “the browser has to do extra work.” (P2). The other two participants described how tracking protection improved the speed of page loading.
Brings attention to the issue of tracking ads. A few participants noted how their relationship to and understanding of tracking changed over the course of the study. As P2 wrote, “It was very thought provoking because even though I did not use the internet much on my phone or computer I started to think about what a difference tracking can make…”
Relevant for mobile. Further, when asked about tracking protection on mobile, many participants said they hadn’t considered online tracking on mobile before. As P10 wrote, “None of my other devices give me the option of turning tracking on and off. And Firefox Nightly has definitely changed my perception of tracking because being that it gives me the option to turn it on and off it also makes me curious what the other browsers are using…It’s led me to various questions.”
Frustrations with Tracking Protection Confusion when targeted ads disappeared. Some participants found the blank areas of missing content where targeted ads were blocked as visually jarring and confusing. As P8 said, “I did notice unusual behavior with page loading or missing content. My reaction to the missing content were usually were Ads would appear…I eventually closed the page because it was odd.” Eventually, participants who mentioned the blank content grew to like having targeted ads blocked.
Options/Preferences Labels unclear. Some participants did not understand the functionality of the opt-in selections in the Options/Preferences menu. The two options sound very similar: “Do Not Track” is a technical framework to send a signal to ad servers requesting to opt out of tracking and “Prevent sites from tracking me” refers to the Firefox Nightly tracking protection feature. For these users, these two selections are a distinction without a difference.
Limited discoverability of interface and alerts. Participants were only alerted to the presence of the shield icon in day two of the study. Only one participant (P15) said he noticed the icon before it was pointed out in the instructions. Once they discovered it, participants did express an accurate understanding of the shield’s functionality to turn tracking protection on and off for the site.
Perceived video playback issues. Video playback, page loading issues, and crashing were issues participants attributed to tracking protection. In our subsequent tests, we demonstrated it is unlikely that tracking protection was the actual cause of instability or video playback issues. Regardless, likely because their attention was focused on the tracking protection feature as the subject of the study, tracking protection was perceived by some participants as the cause of these problems.
A feature for more than a privacy-centric niche. We sometimes think that privacy protection tools are valuable to only a small portion of privacy-centric users (3–8% depending on the study) or general users at specific moments (for example, using the private browsing window). It is noteworthy how many of the participants found value in tracking protection.
Most participants in this study were not already focused on tracking and privacy-related issues. Tracking protection in Firefox Nightly exposed them to a tool that offered them a good deal more privacy than they were accustomed. Some participants responded positively and wanted to continue to have tracking protection as an option. A few other participants said they would like to use tracking protection after they perceived it becoming more stable. As P2 said, “I do plan to use tracking protection beyond this study because I liked the way things loaded better and I feel safer for some reason. I will not seek out additional tools because I don’t think I use the internet enough that I would need something like that.”
Invisible and visible. Participants focused almost exclusively on the visible manifestations of privacy such as targeted ads. During the follow-up interviews, we asked participants about the aspects of trackers that they could not see. P4 and P12 described ad networks and Google but did not fully convey the complex web of relationships among advertisers and tracking technology. Instead, participants only described the targeted ads they saw or did not see with tracking protection active. This more limited understanding makes a good deal of sense given the abstract nature of privacy concerns and the behind-the-scenes nature of tracking tools.
In order to improve the user experience of the tracking protection feature, we recommended at the time a few changes to the design:
Better labeling in the interface, using more common language to distinguish between “Do Not Track,” “Tracking,” and “Privacy.”
Show the invisible aspects of tracking to users to demonstrate visually (via a counter and a list of blocked trackers) to users what is being block on the sites they visit. Making the invisible elements more visible would allow us to show more fully the impact of tracking protection. As some participants indicated in their diary study, these details are valuable to them and enlightening about tracking in general.
Many participants did not mind targeted ads disappearing, but some did find the missing ads affected the design of sites they visited. Whether users support ads or not, many sites are designed with space for ads. In order to retain the intended design of a site, we recommended filing in these empty spaces with wireframes of the ads being removed. Wireframes would also benefit new tracking protection users who were uncomfortable with sites appearing empty. [This proposal may be technically challenging to implement with accuracy.]
Tracking and privacy are complex and sometimes abstract issues. Introducing the tool with on-boarding and a visual tutorial is essential for adoption and education.