My Contribution：UX design     Length: 3 weeks     Project Type：Company project

Background

When I interned at Huaban, an online picture community, I participated in a project to add a user forum to the App as the only product designer in the team. During the project, I collaborated with a UI designer and 3 developers to carefully study each step of the new function, expecting to deliver a delightful experience to users. This forum is expanded to a new app "Wee" now.

Here I will talk about how we designed the post publishing progress bar, which has gotten very positive feedback from users after being released online.

Problem

When designing post publish function, we encountered a problem:

How could we let users know they’d already successfully published a post when they were browsing other contents and had scrolled down many pages？

Ideate and Iterate

I tried out almost every popular product with a similar design and found that common solutions to this problem can be divided into two types:

1 Showing an inconspicuous progress bar and users can continue browsing.

2 Directing users to the top; letting them see what they had just published.

In order to determine what kind of approach would be best for our users, I did a small test. Due to the limitations of testing resources, I initiated a vote in a forum where the primary users are similar to those of our product:

The result showed that nearly 75% of the 184 voters felt that being directed to the top after publishing a post would interrupt their reading progress and annoy them; about 25% of users thought that even this would interrupt their browsing process; they still felt it was necessary to see what they had just published.

Iteration 1

In the first version of the solution, I tried to take into account the expectations of both types of users: first, users can continue browsing, and we show a progress bar on the nav bar. At the same time, in order to satisfy the 25% of users, they can choose to click the progress bar and jump to the top to see the published post.

I used Balsamiq to make an interactive prototype and conducted user tests (due to limited testing resources, I usually chose a variety of colleagues to test it); the test indicated some shortcomings of this solution:

1. The visual display of the progress bar is not obvious enough, so it’s hard for users to notice it and even harder to find that it is clickable.
2. It's difficult to display the progress of multiple posts when users publish several posts continuously.

Iteration 2

Based on this feedback, I optimized the design:

1. Show the progress bar on the publishing position, and enlarge its area and enhance the visual cue.
2. At the same time avoid continuous publishing in the publishing process: the publish button disappears when one post is being published.3 Users can still click on the bar when the publishing succeeds and jump to the top to see what they just published.

Again in the user testing we found new problems:

1. The visual display of the progress bar is still too weak, and few people realize that it's clickable since the progress bar doesn't afford click interaction.
2. Click the operation bar on the bottom of screen then scroll to the top, this operation has a larger distance from a user's mental model (it’s more intuitive to click on the top then jump to the top).

Most importantly, I found that what people say is not necessarily what they do when using the product. For example, I found that while someone said they would like to continue browsing without interruption when voting, they actually clicked to jump to the top when testing. While some others, despite voting to immediately see it, continued to browse content when testing. There were also some people who showed hesitation in the test: unable to decide whether or not to jump to the top.

Iteration3

What was the real goal?

Although I was not sure what the problem was, the testing made me feel that this design did not solve the real problem of the user. So I started thinking backwards: what exactly are the users wanting?

I started observing my co-workers’ and friends’ habits of using such products, asking them for their thoughts. I also tried many similar products to experience the flow as a user.

During this process, I slowly found out that the research I conducted before, asking users whether they "want to jump to the top" or "want to continue browsing", these are options I provided based on existing common solutions. But neither of these is the users’ real goal. What they really want is to see what they are publishing and to continue the reading process conveniently, which is exactly what I really needed to solve.

How could I achieve this goal?

After brainstorming with our team’s developers and designers, we came up with a simple way to accomplish this: Jump to the top when finish publishing to let users see what they've just posted; at the same time fold the content they'd read. Now they could directly scroll down to continue browsing from the previous position, and if they wanted to see the folded content, they could click to expand. This design perfectly met the needs of the users.

This solution got almost everyone's approval during the testing phase. When they were shown the idea, they felt, “It should be so.” So this became our final solution. After the new version was released online, I asked some of our users, most of whom were not aware of the new features of the published process until I asked them, and they gave me positive feedback when they again experienced it intentionally. I guess this is what Dieter Rams called, "unobtrusive design."

Reflection

Although this is a very small project, repeated attempts and tests have given me a new understanding of user experience design:

1. What people say is not necessarily what they actually do: This is the first time I've really experienced the phrase at work. Most users do not know what they really want before a real solution is given. What we, as designers, have to do is unwrap the real needs of the users instead of simply implementing the solutions they imagine.
2. Widespread solutions may not be the best or right for our products. We always need to find out the optimal solution from our own users by removing the prejudices created by common patterns.