Field notes from Hong Kong

alam

0

As someone who’s spent his life divided between Hong Kong and Canada, I’ve seen and experienced some very interesting differences (and some similarities) between the two places. The differences that I’m talking about extend to conventions in design and user experience. Hong Kong’s compact geography combined with a diverse group of people makes for one concentrated melting pot of technology, geography, demography, and well, just about anything you can think of. While it would be fun to write about all the different dynamics, I’m going to focus on the conventions of design and user experience here.

Let’s start with the lowest common denominator: screens. The first thing I noticed was the size of these things. Sure, larger screens can be popular anywhere but there was an obvious preference for larger screens in Hong Kong. This creates some interesting use cases that we would be less likely to find here in North America. Streaming entire TV series and movies (sometimes while driving/working), extensive gaming, and even the use of a tablet as a phone come to mind. Yes, we can find these examples in North America too, but I would say it’s far more common there. I’ve also noticed a tendency to use larger screen devices for greater legibility, this of course would be more common amongst the older users but it does exist.

HK_ipadphone

Next up, would be OS, and it can basically be broken down to iOS versus Android (there are some very intriguing extensions, but more on that later). In a place where everything comes in an infinite combination of colour and specifications, Android obviously has the upper hand here. Plus, they actually have a selection of phones with larger screens. Users also get apps (like movie streaming apps) that would either take a lot longer or just would not be allowed to make it onto the App store. In addition to this, many mid-sized companies in Hong Kong have their own apps and the Play store is just easier to deal with. When it comes to games, installing an .apk file is fairly straight forward as well and users seem to be ok with the process (with regards to hassle, privacy and security) as long as it’s a something they really want. Yet interestingly enough, there still doesn’t seem to be a clear cut winner between the two operating systems.

As I mentioned in the beginning, a great way to describe Hong Kong is compact. On a telecommunications level, it means getting cell service and coverage to everyone is fairly easy. Not only is the market price competitive, but coverage is available almost everywhere. Yes, that means the subway too (or MTR as it’s called over there), and a lot of time is spent underground in those tubes. While I wouldn’t say that everyone has a data plan, it’s definitely not as expensive and therefore much more common. I won’t ramble on here about the downside of having somewhat of an oligopoly in the telecommunications sector, but I hope I am painting a clearer picture of the situation. In summary, we have a densely populated area with widely accessible, relatively fast internet.

HK_mtr1

For designers, device type, screen resolution, connectivity, bandwidth, and battery life are all interconnected and affect the design choices we make. What’s interesting is that Hong Kong offers a very different landscape of restrictions than the North American norm. In many ways, it is less restrictive and allows for more “intricate” user experiences. This is where an interesting gap begins to form. For example, mobile apps like Foursquare or Car2go that requires your geolocation via some sort of internet connection would be a lot less fun if you weren’t connected.

The flip side to this is battery life. If everyone is connected all the time, streaming videos, updating apps and gaming online, you would think that battery life would be an issue. Since work hours are longer, I assumed that most devices would simply charge throughout the day. I found that it didn’t necessarily hold true because the day itself was longer, and people were using their devices proportionally more. Enter the external lithium batteries. These also come in about 10 thousand different colours and combinations (approximately).

My external battery

The different people and cultures that make Hong Kong what it is also makes it one difficult audience to design for. Of course, assuming that there is only “one” audience is always a bold assumption. But the level of competition is really high and I think this can be attributed in part to the population density but also to the culture. One of the reasons why there are so many different variations of the same product is because a lot of it isn’t actually produced by the same manufacturer but instead available as “knock offs” in the aftermarket.

Let’s take a look at Xiaomi. I noticed that their presence was a lot greater than when I last visited in early 2013. Back then, I had heard of them but didn’t really pay much attention to it. This time around, they’re being called the “Apple of China”, their extension of Android’s OS (MIUI) is gaining momentum, and their products are in high demand. Their website is a great example of the per-audience differences I’m talking about. The first thing I noticed when I landed on the page was obviously the design of the page: simple, lots of white space, large HD photos, with a generally modern feel to it. Then, I noticed the language drop down.

Copy aside, there are clear visual/design differences between the English, Simplified Chinese, and Traditional Chinese versions of the site, to the point that they are essentially different sites.

What’s also interesting here are the behaviour of links: no matter what version of the site you’re viewing, all links open in new tabs. This was something that I noticed when I worked in Shanghai and when I visited Chinese sites. I think the use of browser tabs as a natural navigational bread crumb stems from older Chinese sites that typically have a lot more links on a given page compared to the typical website designs we see over here in North America. I think it actually works quite well in some cases. I know this may seem minimal at first, but to me it feels like this may be the start of a trail and I’m interested to see what it may lead me to.

To some extent, I feel like Hong Kong today is a physical manifestation of the open web; in fact, it offers a natural depiction of why silos don’t work. With so many people so close to each other, ideas and products can develop really fast but also burn out just as fast. This makes sustained growth and continuity even harder to achieve. Trying to keep users confined without a reasonable alternative just doesn’t seem to work in the long run.

These different conventions to UX and design are very interesting to say the least. Personally, these types of things are compelling to think about. But, as a designer I feel obligated to be aware of as much as I can and when it’s a whole third of the world, it’s just nice to know.

Indonesia Follow-up: Ecommerce

Bill Selman

2

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

6

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

3

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

  • Usertesting.com, 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

3

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 …