Optim

The Progressive UI Improvement of the Cloud Service

 

Overview

At the same time that a new style guideline is in progress, Optim also has a couple of things to overhaul. Technician Dashboard, particularly, is the most visited page of Optim, where users come to troubleshoot, look up for clients’ data and statistics, and operate different kinds of configurations at individual and/or system levels.

Time 2020/11 - 2022/1 (Slower UI updates and iterations)

Handled Tasks

  • Incubation

  • Defining product scope

  • Sprint facilitation

  • Prototyping & motion studies

  • Stakeholder presentations

  • Documentation

  • Testing (A/B, integration, usability)


Challenges

There are three key areas Optim Equipment Details Dashboard(short in ED dashboard) might improve:

Look and feel
with a few changes, the ED Dashboard can still feel powerful, but more approachable and organized. It can retain its utilitarian aesthetic while being more forgiving of a user’s mistakes. And this page can use color and shape more effectively to guide attention, create a scannable interface, and help people immediately identify their current state and the next step to take.

Interaction design
there are many places where we can streamline interactions, provide clear feedback about the result of a given interaction, and in some cases remove certain interactions entirely to simplify the interface further.

Layout and hierarchy
key changes to the layout and visual hierarchy will make ED Dashboard easier to understand and navigate.

 

Major Observation

Optim Equipment Details Dashboard feels technical, utilitarian, sharp, and unforgiving.

Many interface elements are squeezed in a small area and positioned in a wired way. Also, using the same weight font for almost everything in a table provides more density at cost of scalability and difficulty of understanding the information. Buttons, element positions, font weights, and color, trading a requirement for high user concentration with the ability to understand a lot of information in one page.

With the constraint of the minimum change that won’t affect the current user habit, the most important thing I started from is to rearrange the layout and refine the interaction.

VISUAL

  • Use color to better distinguish interactive and destructive interface elements. Deep orange is signaling for attention, light blue is interactive, gray is disabled.

  • Improve the action state by color and mini-interaction.

  • Reorganize the table column and row, add tabs to categorize data that was going to be scattered all over the place.

Dashboard - Equipment Details (Large size)

Dashboard - Equipment Details (Medium size)

Dashboard - Equipment Details (Small size)

 

Old Technician Dashboard

Ideation for redesign

 

Current login page

Ideations for the launch screen & login page

INTERACTION

  • Simplify the prompt process of destructive actions(excluding actions that are “semi-destructive” like resetting configurations), like rebooting equipment (confirmation and operation state toast).

  • Considering looking at it on a smaller device, prevent the in-table and whole page horizontal scrolling.

  • Provide feedback to users when interactions cause changes to happen out of view.

    For example, trigger the Reboot button → confirm to proceed with the action → waiting for the process to get started → waiting for the action result. The user would need to be notified of the outcome of each step that keeps him waiting.

 

Micro-interaction on a mobile device while triggering the WPS button

 

Micro-interaction while triggering the WPS button

 

Other Problems

  1. In the CPE config management page

    Many interactions require too many clicks or steps when they could be streamlined or removed entirely.

  2. The entire application should be clearly communicated at all times.

  3. The common app functionality is spread apart, making it unintuitive to know where to look for certain controls. For example, the feature naming:

  • Dashboard

    This whole site is actually a big dashboard, and what I know about this page is actually a subscriber’s collection library

  • Scheduler & Reports

    What scheduler and report specifically? Or should we even separate these two features?

  • DevOps

    Does it stand for Development Operations or something else? How to tell the users what service it provides through this name?

  • Equipment Look Up

    There is literally just a search input after I enter this feature. After learning more about what it is about, I got it. But as a standalone feature? :/ I wonder if this be integrated into other pages like the Technician Dashboard.

etc.

Recommendation

We could group common functionality in many ways, but a more grouping might be:

  • Core functionality (config + stats e.g. Equipment Dashboard, Software Module Dashboard)

  • User information (profile, settings − including theme selection, log out, etc)

  • Secondary functionality(DevOps, Debug, Documentation)

Some sketches in early discussion

Sidebar - partial expanded

 

4. Within the Technician Dashboard aka the Homepage, we can simplify the layout, considering:

  • using an expandable-collapsable layer or sheet to make the section hierarchy more distinguish

    try subscriber info - CPE info - Network info

  • removing all extraneous controls/information that doesn’t fit neatly into the particular user flow.

    • For example, the global banner containing the username, login role, login time, and current time may not need to be displayed as part of persistent information

    • The information contained in Equipment Look Up is totally contained in the Equipment Details page.

  • improving the visual consistency. Elements vary across functions and pages, which increases the effort to learn and adapt to differences when switching between screens.

Functionality

Optim Dashboard is made up of many small projects. Aside from the problems of aesthetics, accessibility, and usability, functionality is almost always the first thing to work on. Every feature plays a role in the system, and each of the requirements, as the user needs, may find itself developing the user flow dozens of paths to go. Relevant features and any interconnected actions all need to be considered to proceed with the design afterward.

that’s why we have a flowchart and highlight where an edge may occur for each feature

 

Takeaway

The good part

Despite a lot of compromise being made, there is still room to improve the workflow within the team. Being the only designer of a hardware-centered organization, things like clarifying the requirements, evaluating the usability, interactions, interfaces and workflow of every feature that requires me a while of time to deal with without a little solid foundation of understanding from the real users, I’d take it as a great chance to level up my more precise intuition to the user needs.

The less good part

As the infrastructure of design system is working in progress, the new feature requirements keeping coming is definitely a challenge to me. It’d be better to conduct this project as a team that PMs and developers can point out the feasibility issue or any potential needs before any decision is made. Also, with limited time resources, the testing plan wasn’t been conducted thoroughly. We applied new design to new features as an MVP and collected feedback after release. That is to say, iterations and migration inevitably progress slowly.

This to me is absolutely a fresh and humble experience to learn that

  • working as a team, collaboration is the key

  • designing at scale, test in detail.