Publish Page Redesign Project

publish page.png

Role: UX Designer/Researcher

By analyzing data performance and customer interviews, we uncovered one pain point of KADA key user flows—publishing projects. When users entered the “publish page,” some of them did not realize that they were still one step away from successfully publishing their projects. Initially, in order to save development resources, our team built the publish page out of the “project’s main page,” so these two pages looked very similar. Details unveiled by data from GA and NetEase YouShu showed that on the publish page, there was a 7.5% bounce rate from the navigation bar section, which potentially caused more “unpublished projects.” We needed to fix that.  

Screen Shot 2019-06-22 at 12.28.05 AM.png

Figure 1:GA shows a 7.5% bounce rate due to clicking on the navigation bar

Screen Shot 2019-06-22 at 1.15.01 AM.png

Figure 2: The project’s main page. The publish page used to look similar to the project’s main page. The different copy on the buttons tell users which page they are on

Assumptions

The facts I discovered above caught my attention and I started by developing several assumptions:

  1. Users who thought their project was published already might click on the “discover” button on the navigation bar to look for their project in the list.

  2. Some users navigating our site on a low resolution display might not be able to see some CTA content on the page (for example, the buttons on the lower side of the screen).

  3. Improving the content layout while highlighting CTA design would lead users to continue to stay on the main task flow, which was publishing the project.

  4. Simplifying the interaction design to make the page easier to navigate and enhance communication efficiency.

Verify the Assumptions

We set up interviews with users who addressed this issue, as well as some new users who were not very familiar with the publishing process yet, in order to gather diverse perspectives on how users publish their projects on our platform. At first, we held conversations with these users using open-ended questions to try to understand when, why, and how they were going through learning, creating, and sharing (publishing) projects on KADA. Later, we gave them a task. We asked them to watch a Scratch tutorial and then they participated in a hands-on session to make a project on Scratch 2.0. During that time, we recorded any questions and frustrations they expressed. We learned a few key facts about their publishing project process:

  1. Users mis-recognized the “publish page” as the “project’s main page” since they looked quite similar.

  2. None of the interviewees clicked on the project’s thumbnail on the publish page.

  3. Only 1 out of 10 interviewees actually used/recognized the mobile keyboard setting feature on the page.

  4. 4 out of 5 young interviewees (5th grade and below) chose to skip the project’s introduction section because of their limited typing ability.

  5. Children get distracted easily. The new design had to help them focus on getting their projects published efficiently.

These findings showed the “Why” of the usability issues we initially discovered. I discussed the findings with other designers on the IxD team and decided there would be two potential directions we could take other than to improve the CTA design in general:

  1. Differentiate the publish page from the project’s main page.

  2. Prioritize and simplify the content and tasks presented to users.

I started the design process by sorting out the use cases on the publish page:

  • Project thumbnail: Shows how the project looked on the platform once it was published. Users could also run the project from the thumbnail.

  • Introduction of the project: Users could add descriptions for their projects.

  • Operating instruction of the project: Users were able to instruct others about how to play and interact with their projects.

  • Adding tags: Users could categorize their projects by adding tags.

  • Keyboard selection for mobile device: Users were able to select different keyboard settings based on the content of their projects. This allowed them to experience their projects on mobile devices.

  • Keep projects private/public button: Users could choose to keep their projects private or public based on whether they wanted them to be publicly accessible.


The most important fact that I learned from user testing was that children were easily distracted. Having too much content, or a floating action module, etc. quickly misled them from completing the main task. In other words, helping them to focus on the main task was to be the top priority of this iteration design. 

After prioritizing the assumptions, I set off to build prototypes to gather quantitative feedback from stakeholders and users.

Prototypes

The first prototype presented the progress indicator feature, which gave users a hint about where they were in the main task. He/She was still one step away from successfully publishing the project.

 
Figure 3: Prototype No.1 features a progress indicator to show users the publishing process is not done yet

Figure 3: Prototype No.1 features a progress indicator to show users the publishing process is not done yet

 

Pros

☑︎ The progress indicator gave users a hint about where
they were in the task and indicated that their projects
were not yet published
☑︎ Required minimum changes to the previous publish
page

Cons

⊠   The progress indicator was not show anywhere
else which was not consistent across the platform
⊠   The “select keyboard” module was not child-friendly
⊠   The information layout was not ideal and the visual
perception tracking was not intuitive 

The second prototype presented a much more drastic departure from the previous design, which embedded a progress indicator as part of the form. 

Figure 4: Prototype No.2 features a step-by-step progress indicator embedded in the form

Figure 4: Prototype No.2 features a step-by-step progress indicator embedded in the form

Pros

☑︎ Accompanied users throughout the task
☑︎ Differentiated the publish page from the project’s main
page

Cons

⊠   Required extra clicking to skim through the form and
go through/skip optional fields
⊠   Hiding and folding up some content did not contribute
to clear and efficient communication
⊠   Required existing users to change their habits
⊠   Relatively costly to develop

Starting with the third prototype, I decided to take a different path. I realized that the project’s thumbnail did not match the scenario with its usability for two reasons. First, users had just finished creating and testing the project before coming to the publish page. Second, users had no control over which frame would be chosen as the thumbnail.

As a result, I removed the thumbnail from the publish page. 

 
Figure 5: Prototype No.3 features no thumbnail and folded advanced setting options

Figure 5: Prototype No.3 features no thumbnail and folded advanced setting options

 

Pros

☑︎ Provided a more natural and intuitive communication
☑︎ Produced a more task-focused flow

Cons

⊠   Folded keyboard settings risked projects’ performance and user
experience on mobile device, so it is a NO

The fourth prototype was a further improved version based on the third prototype. It presented a clean and minimum-learning-curve experience. The keyboard setting process was more user-friendly and featured a stronger CTA design.

Figure 6: Prototype No.4 is an improved version based on the previous prototype

Figure 6: Prototype No.4 is an improved version based on the previous prototype

Pros

☑︎ Provided a more natural and intuitive communication
☑︎ Produced a more task-focused flow
☑︎ Differentiated the publish page from the project’s main page

Cons

⊠   Visually less appealing

Prototype Testing

We conducted approximately 10 tests with users and the stakeholders on board. We ended up agreeing upon on the last prototype for reasons listed below:

  • Although folding up advanced settings was a common way to reduce complexity, based on my observation, children did not like hide-and-seek games on a web page.

  • Almost all the users recognized the disappearance of the project’s thumbnail, but none of them had problems finishing the task.

  • While other prototypes worked fine in terms of usability, the last prototype proved to have better legibility and efficiency by reducing the number of other unrelated task flows, which meant users could stay focused on the main task.

Other Details

In order to highlight the temporariness of the publish page, I twisted it a bit to make it look like a temporary modal in order to enhance the feeling.

I also adjusted the order of keyboards in the keyboard select tool based on users’ behavioral data from YouShu and GA.

One of the testees said that the last prototype reminded him of taking an exam on a computer at school, which could either be good or bad. The good thing was that the content was clear from top to bottom. Plus, the prototype resonated with previous experiences. The bad thing was that it could be boring to go through. Since the task could be done within a couple minutes, however, it was not a big problem. 

Later On

I worked closely with our visual designer to apply the minimum design idea while embedding the KADA identity into the final UI design and other details, which included editing within the fields and the keyboard select visual transition effect.

I also summited the event tracking plan to the engineering team to make sure we had a holistic understanding about users’ behavioral patterns with regard to this new iteration. 

What did I learn?

While we got positive qualitative feedback from our users during the user testing process, the metrics from YouShu and GA also supported the new design from a quantitative perspective. The page bounce rate was at a low point of 4.07% (within one month after the update) compared to 15.06% (one month before the iteration). This was the first time in a year the publish page had been optimized and the outcome was encouraging to our team. 

  • Think out of the box. Initially, I tried to hide options to minimize the volume of the content on the page, but completely ignored the existence of the project’s thumbnail because it was a longstanding feature. I forgot to ask the question “Why is it here?” and “What is the hierarchy of the content on the page?”

  • Start small. My first idea was to try to radically re-imagine the entire interface of the publish page, but that did not help me focus on the whole picture. Even though there might have been merit to those ideas, I needed to make sure that I stayed focused on the pain points we uncovered through research and quickly doing something with minimum cost so we could observe, learn, and iterate rapidly.

  • Details do matter. I believe as designers, we are all most likely aware that details matter, but designing a small feature like this helped elevate the holistic experience. For example, would clicking the right or left arrow buttons in the keyboard select tool show another keyboard option or another keyboard collection? I wanted the copy to speak to our audience by crafting copy that would make a dull page less boring. I like to take time to find opportunities like this where small changes could lead to a bigger impact.