Background

The problem

After launching the product, we started to get feedback from the field about how they were using the product and what kind of issues they ran into. One of the pain points identified (and one of the most requested feature enhancements) by the field was to provide more feedback when publishing an integration.

When creating an integration, many of our users often needed to frequently publish the work in progress integration to test things out. They want to know if the integration is working properly based on how they set up the integration. Therefore, the action of publishing an integration become an integral part of the user workflow. However, because multiple factors - and some of these can be out of our control - could affect the integration publishing time, we only had a “pending” spinner to communicate to users that something was happening.  

Clearly, a “pending” spinner was not enough, and our users wanted information to assure the publishing process is happening. I was asked to explore design solutions that address this problem.

The design goal

How might we provide better feedback to inform our users during the integration publishing process, and make them feel more in control?

Design

Research

Earlier in the year, the team conducted a comparative usability study and one of the findings from the study was about users’ reaction to applications that went into non-responsive state -

"I’m not sure what it’s doing...it was a little nerve wracking…" — from one of the participants

Aside from feeling nervous, we also discovered users often stop and restart the application as a way to recover from the unresponsive state and to regain control. In addition, we learned that even users claimed they would wait and killed an unresponsive application at 5 minutes, they actually gave up around 2 minutes.

From usability study and secondary research, I learned that -

• Providing appropriate feedback lets users know the publishing process is working and reduce uncertainty. It helps to ensure they are on the right track. Visibility of system status is one of the ten heuristics for user interface design.

• Users have very limited patience when it comes to dealing with an unresponsive application. While spinner may be good for some other interaction, it’s best to avoid it and use a progress indicator when a process needs longer time to finish.    

• On top of providing informational feedback, we can also provide actions oriented information to help users be more in control.

Initial Design

Putting myself in users’ shoes, here are some of the questions I might ask when I am facing an unresponsive application or a “pending” spinner -

• What’s happening? Is it hung?

• Did I do something wrong? What can I do to make it right?

• What can I do other than to wait?

With these questions in mind, I created a few design concepts.

Concept 1 - Linear progress bar

Concept 2 - Circular progress indicator

Concept 3 - Dynamic loading state on list view

Here are some rationales behind my design decisions -

• Given the limited screen real estate, use short header and current states/total states to support scannability. Having the number of total states helps to set the right expectations and lets users know how many states are involved during the publishing process.  

• Provide tooltip on hover to provide detailed information. This was to make sure we do not overload our users with technical information.

• Included a link to view log information in another platform. Having this link not only gives users more control but it also helps us add value to the user interaction with our application. And it aligns with the research findings - “more information translates to better decision making” (from the visibility of system status article).

Final Design

We decided to go with a linear progress bar since it conveys the idea that something is moving forward, and it also aligns better with the concept of states. One of the challenges of nailing down the final solution was to draw a line between giving users too much information and not enough information. In other words, how fine-grained do we want to show users the states? We ended up including 5 states that are distinguishable enough from one another to keep the information useful and understandable.