Indonesia Follow-up: Ecommerce

Bill Selman


Following up on our research that we conducted last year on Internet usage in Indonesia, The Financial Times published an article (Note: Paywall) on Indonesia’s challenges to developing ecommerce. Their observations and interviews confirm our observations about infrastructure hindering the development of ecommerce.

It will be interesting to see how ecommerce develops over the coming years in Indonesia. Based on the field work we conducted, infrastructural change is unlikely to follow the path of western countries in terms of their development.  Instead, Indonesians are already employing alternative approaches to western business and logistics models in order to work with their current infrastructure. In the near future, some of these logistical alternatives will likely be replaced by a better technology. However, just as likely in some cases, these alternatives may become entrenched as institutions that are the local, accepted way of completing tasks and conducting business.

An example of the former are the app kiosks provided by some mobile OEMs in their branded stores or by operators that allow smartphone owners to plug in their phones and download apps and video. These kiosks allow users to bypass the annoyance of unstable and slow 3G networks in order to download apps and video more easily and efficiently. Further, the kiosks conserve customers’ expensive bandwidth. Nevertheless, as bandwidth improves and becomes more stable with the adoption of LTE networks over the coming years, the utility of the kiosks is likely to fade.

Galaxy Station at a Samsung store.

Galaxy Station at a Samsung store.

An example of an institution that will not change soon is the lack of consistent and stable addresses for deliveries. However, as the FT story points out, courier services have emerged as the means to deliver ecommerce items. Barring wholesale government or private investment, these services will likely evolve beyond logistical alternatives to become the accepted means of delivery of goods bought via ecommerce. Apart from a few specialized services, couriers are no longer the western approach to delivery. Technology companies that wish to succeed will need to adjust their logistical models and technological assumptions (or make large-scale investments) in order to meet the requirements and customs of some locales.

A typical middle class street in Jakarta

A typical upper middle class street on the outskirts of Jakarta



Introducing the update experience for Australis

Zhenshuo Fang


This post focuses on design principles and solutions that accompanies our other post about design process for the Australis update experience. - Zhenshuo Fang and Holly Habstritt Gaal, Mozilla UX

Introducing change is always hard, especially for software like Firefox that has been around for 10 years, and has technical legacy as well as UI legacy. The Firefox design and engineering teams recently introduced a redesign of Firefox we call Australis, that includes several visual improvements as well as new features that we believe benefit our users. Even though we blogged, tweeted and talked about it in various places, the majority of our users will find out about the new design the moment they update Firefox. While the interface is intuitive for new users, it still represents change for users who have learned and gotten used to the existing UI.

To introduce Australis to our existing Firefox users, a group from different teams started a project called “onboarding” to create an update experience along side Australis. The goal of this update experience is to help existing users get familiar with the new interface faster, gain interest in using more features, and answer their questions about the “why” behind the design. Here I will share with you some design principles and lessons we learned through the process of designing the update experience for Australis.

1. If you don’t want people to skip it, don’t design it like a webpage

The Banner Blindness study shows that people ignore what looks like an advertisement on a web page. We found through usability testing that the same holds true when users update their browser: they will ignore and not interact with what looks like a typical landing page. Since existing users have seen the update page so many times and the information on that page is not always relevant to their current task, ignoring the page has become a habit no matter whether the information on the page is interesting or not. Therefore in this new version of the update experience, we designed the web page so that it is minimal and only contains one welcome message to reassure that the user has updated to a new version of Firefox. This allows users to focus on the other key information we want to deliver in a “door hanger” information bubble.

The web page users see when they update Firefox

The web page users see when they update Firefox

2. Minimal Interruption for users

In contrast to new users who just downloaded Firefox, the challenge of designing an update experience for existing users is that they already have a task in mind when opening the browser and do not want to be interrupted. Instead of making every user go through a tour upon update, we decided to use a door hanger information bubble as a minimal barrier to tell existing users only one key thing about the new design: the location of the newly redesigned menu button. For users who are interested in learning more, the ”Let’s go” button will take them through an interactive tour of the new interface. For users who do not have time at the moment, they can choose “Not Now”, but by then, they should already know about the new menu and where to find it.

The door hanger

The door hanger bubble hanging off the menu button

3. Show, don’t tell

Show, don’t tell is a writing technique as well as an important design principle. The traditional way of introducing features in a product is using a web page with screenshots or pointing arrows that point out where a feature is. But if the browser is already open, why show yet another screenshot of the browser to talk about it? The most interesting and challenging thing about the update experience from both a design and technical perspective is that the website and browser can now talk to each other to provide a connected and immersive experience. This means that when talking about a specific feature or task in the web page, we can now highlight directly the controls in the browser interface to show users where that feature is. Users can also interact with the feature while learning about it. Through usability testing, we found that showing a feature in the browser also help users recall it afterwards, which resulted in more feature use after taking the tour.

First step of tour

The step showcasing Add-ons in the tour

4. Serendipity

“Exuberant” and “Finely Crafted” are two key Firefox Design Values we always refer to when designing for Firefox. Other than making the update experience interactive, We also tried to add a little bit fun into it. After all, the tour should not feel like a dry lecture but a fun journey. For example, the highlight of a feature can change randomly every time you open the tour. Or if you close the panel in the middle of the tour, the “next” arrow will rotate into an “up” arrow and dock the tour at the bottom of the window. We are also experimenting different visual design and tone of the copy to make the experience as human and joyful as possible.

Dock the tour at the bottom of the page

Docking the tour at the bottom of the page

5. ABT (always be testing)

Just like any other design, no one can get it right at the first time. That’s why we need to always be testing and keep improving. For this particular project, we used various methods to validate our assumptions and evaluate the design throughout the process. We gathered qualitative data early on through in-person interview and remote usability testing, as well as quantitative data in different release channels to measure our success.

The update experience landed in Firefox Aurora with Australis and an improved version of Sync. While we keep iterating on the design as well as other features in Aurora, try it out and let us know if you have any suggestions. The onboarding team is also working on an “unboxing” experience for new users who just downloaded Firefox. Stay tuned for more awesomeness!



5 questions to ask during your design process

Holly Habstritt Gaal


This post focuses on process and accompanies Introducing the update experience for Australis. – Zhenshuo Fang and Holly Habstritt Gaal, Mozilla UX.

We’re really excited to release a new onboarding flow for users updating to the new Firefox (Australis). Throughout this project we’ve learned a lot about design process that helped us to make decisions and allow our assumptions to become something tangible and valuable for our users. We started with high level thinking about how to educate users and are now focused on updating current users to the new Firefox. Our process started with a few assumptions, but evolved to fit a project that didn’t exist when we started. This post explains a few questions that we asked along the way.

Onboarding project timeline

Onboarding project timeline

1. Are my assumptions right?

Assumptions need to be explored and tested before offering solutions. In the early stages of our work, “onboarding” was not yet a project on the roadmap and was not tied to the launch of Australis in Firefox 29. We felt strongly that improving the onboarding experience would help the adoption of the new browser. Sentiment reports also tell us that better onboarding is desired by our users. In order to demonstrate the value of onboarding, we first needed to learn more about the assumptions we had about browser usage and onboarding in general. Initially, there were only a few of us exploring our ideas, so early testing and learning allowed us to rule out assumptions early and work efficiently.

One assumption we had was that users in a First Run or Update experience are likely to ignore what appears to be a typical web page since they are focused on a task like checking email when opening their browser. This presents a challenge of not creating a barrier from completing the user’s task, but also creating an experience that is both valuable and memorable. We also had assumptions about language and tone, how feature education could lead to more usage hours, and many others.

Tools we have to help

  •, surveys, and one-on-one observation: By gathering qualitative data (feedback directly from our users) we are able to quickly validate or rule out our early assumptions before diving into them too far.

  • Google Analytics: We ran very early web experiments to test copy, UI styles, and general engagement with our content, but will continue to use GA after release.

  • Telemetry and Firefox Health Report tell us about user behavior in the browser itself. See Blake Winton’s post about Measuring Australis to learn more.


2. What should I prototype?

We know that prototyping is useful, but knowing what to prototype and being efficient is important. Testing first with existing products, Keynote mockups, and static pages allowed us to decide what we should prototype further with engineers. The key to learning more about our assumptions and proposing possible solutions was working with engineers early in the process. For example, this allowed us to know the technical possibilities and limits when debating early UI and interaction ideas.

An early premise was that watching a video or looking at a screenshot is not as memorable or clear as showing the user what is happening directly in the browser. We knew that the best experience shouldn’t just tell the user about something new, but result in a behavioral change and a new way of thinking. Exploring this idea with a rough prototype is what lead to creating the foundation of the experience, technology that allows the web and chrome to interact with one another. This avoids having to rely on passive viewing of a web page to create a memorable experience. Check out this video from Michael Verdi to see what I mean.

* video demonstrates our progress and thinking as of November 2013

Working with engineers early with prototypes allowed us to do the following:

  • Confirm that the new interaction for showing, not just telling a user about the browser was technically possible.

  • Have access to try builds to test with users outside of the release channel. This was essential to knowing what UI and interaction and would be accepted and adopted by users.

  • Find bugs early and be able to plan for what challenges we may face in implementation. This was essential for moving forward in proposing solutions.


3. Am I confident enough to propose a solution?

As a direct result of everything we learned in preliminary exploration, prototyping, and testing we were able to propose solutions based on key findings that we felt confident would lead to valuable onboarding experience. For example:

  • an experience that doesn’t feel like a webpage, appears to be connected to the browser itself, and not isolated to the web

  • an experience that balances low interruption with clear visibility that a UI tour is present

  • a new interaction pattern where the web and chrome collaborate (as a result users are noticing and remembering the experience more than serving the same information in a typical web page)

Being able to share what we learned by referencing data and user test results made our design choices easier to understand by those not directly involved. It was also much easier to have a discussion and make sure everyone felt confident in design choices before moving forward.

For more about how we designed the experience see Introducing the update experience for Australis.

Onboarding Tour UI

Onboarding Tour UI


4. Is everyone on board?

Collaboration leads to a better solution and experience for our users, but also leads to smoother internal adoption of an idea. This project started as a few of us exploring assumptions, then became a weekly meeting that included those interested in improving onboarding and user education, and is now a cross-functional team working together towards the Australis launch in Firefox 29.

The collaboration spans across teams such as release engineering, web development, marketing, visual design, UX, user advocacy & support team, metrics, and others. This is an example of how UX isn’t an isolated step in the process. It affects the life cycle of a project and requires balancing input and collaboration from all teams and roles.

5. Are we improving?

 With all of the hard work we have put into this, we want to be sure to continue to improve the experience for our users. To do so, it is important to know both what our definition of success is and how to monitor it. As we release the experience to more users in Firefox 29, we’ll learn more about how it can have an impact on behavior, usage hours, and overall enjoyment of using Firefox. What we learn will also help to improve other onboarding touchpoints we have with our users such as the First Run experience. The benefit of creating the controls and majority of the UI in the web means that we are not tied to our release cycle and can iterate quickly.

An interesting challenge we have is that interaction occurs both in the browser chrome and web page. We would like you to use the browser and not just interact with a web page, so high interaction in a web page doesn’t necessarily equal success. Success is when the user finds value in the message we are communicating and that results in using something new in the browser, using the browser more, or adopting new behavior. If we notice changes in user behavior and long-term use of the browser, knowing if they are direct result of an onboarding experience will guide our improvements and next steps.

What we’ve learned isn’t about an exact process that will work for every project, but about how answering these questions and collaborating early will lead to a better experience for our users.

We love to discuss all things onboarding. If you have any questions, please reach out to Holly Habstritt Gaal and Zhenshuo Fang.  

Designing Tools

Darrin Henein


I was hired at Mozilla 7 months ago. While my primary role is as a Senior Design Engineer on the Firefox Desktop team, I’ve since spent a considerable amount of time working with the amazing Developer Tools team. The hope was that with my experience in UX design and my passion for web development and programming, I would be able to provide some informed design direction for our tools.

Continue reading …

Are you a mobile Web app developer? Let us know how we can improve your experience!



The Mozilla User Experience Research team is looking for developers in the Bay Area who have experience writing mobile Web apps to participate in a paid research study that will have a significant impact on making our developer-focused efforts even better.

To qualify for the study, please take this 10-minute survey. If you’re eligible, a member of our team will contact you to tell you a little more about the research and schedule time with you. Developers who qualify for and fully participate will receive an honorarium of $250.

We’re looking for developers who are:

  • willing to participate in a 2-hour in-person interview at their workplace or home
  • available for the interview the week of March 10 to 14  (the weekend before / after may also be possible)

The interview will be recorded, but all materials will be used for internal research purposes only.

You DON’T have to use Mozilla products or be part of our community to participate (in fact, we’d like to hear your voice even more!).

Your feedback has the potential to improve the experience of other Web app developers and influence the direction of our products and services, so we would love to get a chance to talk with you! Please feel free to share this opportunity widely with your own network as well.