If you are a product design manager or a product designer. Now you need to design an application that contains many pages and modules and cannot display completely in one screen. You will first think of designing a tab navigation at the bottom or top. However, the extra navigation lines seem a little inconspicuous. What if I try to get them in the sidebar, such as "side drawer navigation? Today, let's take a closer look at this product design course. This article is from E liangshi Yiyou network and elsyy.com.
If your applications are also multi-view, the following topics in your team will be subject to intense discussion:
It is to display all the navigation options on the screen, so that your users can clearly understand the app structure and avoid unnecessary operations to discover; or use side navigation to make the display area of the main screen larger.
Currently, side navigation is popular on Android devices, while it is not widely used on iOS platforms. Therefore, our discussion also faces the following question: do Android and iOS apps have the same user habits and use the same navigation mode?
I think it is very valuable to share our experience here.
Availability vs. clean design
When we started the zeekbox project for the first time, we used the tab navigation on the top. Our reason is simple: "Don't remember what you don't see ". Since you cannot see these entries at first glance, you may not know where they are.
For example, if you do not see the guide on the left, you may not find the navigation path. If you find it once, do you remember the side navigation portal every time you come back to zeebox? Even if you remember, you still need to click twice each time you switch the topic.
However, from another point of view, there is no such line of tab navigation, which makes the design look much cleaner. By putting the navigation in the side drawer, there is more room for the main content area.
The design of side drawer navigation emerged 18 months ago.
Facebook used a new method of navigation around September 2013-or perhaps the Facebook app I was using as a sample of A/B test. Of course, since Facebook has done this, this solution should be good, I think so.
The Google Play team, which is friendly and willing to provide guidance, then recommends navigation drawers as a new navigation method for Android apps.
So six months later, we decided to take the risk and try to switch to the sidebar navigation. To ensure that users can clearly find the side navigation, we set the sidebar to expand and display when the application is opened for the first time, as shown in the following figure:
When the new version was just released, our user feedback was great (such as "like new design, all 5 points !" Such feedback) but when we see our own data, this is really a disaster! The user engagement is halved, as if the sentence "don't remember what you don't see" was fulfilled.
Surprising fact
After realizing the severity of the result, we used a two-week release to restore to the top tab navigation mode. At the same time, in order not to disappoint users who like new navigation, we reserve the option of side navigation in settings.
Six months later, zeebox has undergone many changes. We have a new "my TV" page with richer content, including subscription and advertisement, it is a very important page for users. To display more content on this page, we thought of trying to side navigation. Based on our previous experiences, this time we decided to use a smarter way to test a/B test.
My favorite A/B test tools and methods
We use flinto to create a high-fidelity clickable prototype, which makes the design look like a real application, and users can complete it in a short time. Here you can see the flinto prototype we created: Case 1, Case 2 -- get the best click on the iPhone: click in any area of the page, A highlighted prompt is displayed in the heat zone that can interact with each other. You can click these hot zones, just like using a real application.
We recruited users who liked watching TV programs and came to our studio twice a week to test different concepts and our design prototypes. In some cases, we can use a small sample user to test the selection scheme, as mentioned above for a prototype test on the "my TV" page. In other cases, such as verifying the use effect of the sidebar navigation, You need to observe the real use records of a large number of users. In this case, we need to use a/B test.
For mobile app A/B test, we use swrve -- in my opinion the most mature a/B Test tool, which not only provides goal seeking (when the winning scheme is clear, a/B testing server can automatically switch all users to the best option), and can choose to provide different experience solutions for different users.
For example, if you are a Comcast source subscriber and you do not find that our application has the Xfinity remote control function, swrve will let zeebox pop up a window to tell you the relevant information. Through the adjustment and control of this message reminder mechanism, A/B test tends to have a more reasonable test result every day.
We used the 15/85 method to test the effect of sidebar, that is, we put the sidebar solution for 15% of users, and 85% of users maintained the tab navigation mode. We released this new version for A/B test, waiting for the final test results...
For example, the test results are amazing.
The Influence of Drawer navigation and Tab navigation on user Usage Frequency
The frequency of weekly use is decreasing (obvious comparison), the frequency of daily use is decreasing, and the time spent by users in applications is decreasing. Navigation on the sidebar looks like a disaster in the first round of testing.
Thanks to a/B test, we can quickly switch all users to the tab navigation solution after a period of verification.
If the argument about using the sidebar or tab also appears in your team, I think our research experience is worth sharing with you.
When we decided that the sidebar was not suitable for our products through A/B test, Facebook also released a new version of the application, or adopted a fixed bottom tab navigation. Therefore, on the iPhone, they finally chose a conservative navigation method.
On Android, how do they deal with it. On my Android device, the solution is displayed on the left (switch different pages through the secondary tab), and on my colleague's mobile phone, the solution is displayed on the right, switch between different pages through (navigation ). Facebook must also use A/B test to test users' different responses to drawer navigation and tabs. I am looking forward to the final results of Facebook's test.
In the latest face version, solution 1 is used, that is, Tab navigation, as shown in
Facebook's latest decision
So when is side navigation suitable?
It is recommended that the main functions and content of the application be included in a page. Some user settings and options must be displayed on other pages. These auxiliary functions can be placed on the sidebar for the purpose of making the homepage look clean and beautiful.
If your applications have different views and they are of the same level, you must treat them equally, the Sidebar will waste the potential engagement and interaction of most users for the entries in the sidebar.