WebSphere Automation
Lead User Experience Designer, Nov 2020 - Present
WebSphere Automation is an on-premise application servers automation product which is provided as one of the offerings of IBM Automation platform. The product reduces the manual toils of IT administrators to keep the environment up to date and safe by providing a holistic view of security and health of the WebSphere environment, automated experience of security vulnerability remediation.
I lead the whole experience design with one fellow UX designer. I worked closely with PMs to prioritize the feature design, and got immense support to get direct engagement with clients.
Background & Foundation
When I was assigned to the project, the project was at the stage where the market opportunity and the customer needs were validated, and established the initial roadmap. The team needed design support , I was assigned to the project as the only UX designer in the beginning. The team was relatively small compared to my other project and the startup-like culture was something I greatly valued.
Release small deliverables quickly and often.
Instead of cooking the project too long to perfect the experience and every feature, our strategy is delivering small achievements continuously so our clients can see the immediate values and ROIs. In this agile development, I tightly communicated with the PM to understand the bigger roadmap goals and clarify design problems we are addressing in each release.
Ensure consistency with other products on IBM Automation platform.
As one of the offerings on IBM Automation platform, I collaborated with other designers to make consistent experience of navigation, user roles and permissions. With the potential possibility to make integrated experience with other offerings on the platform, make sure using the same design patterns such as create assets, notification settings.
Collaboration with IBM Automation platform designers to define navigation categories and groupings.
Infuse the design thinking process
The team hasn’t had design support before. I engage the PM and engineers in every design process such as defining the design problems, need statement, brainstorming and design iterations. I pitched to have design workshops to have the team on the same page about the vision, users, challenges and constraints. The team was very excited and supportive to be involved in the design process.
Virtual workshop with stakeholders
Case study: self secure
The preliminary conversations and generative interviews with our major clients such as financial and medical institutions found they have been using WebSphere servers for decades, and have a large complex environment. However, there is no tool that can display a holistic view of the overall environment’s security and health. Therefore, IT admins of our clients manually maintain a spreadsheet to keep track of problem determination and resolution status. When a new IBM security vulnerability notification is published, the administrator reads the details, analyzes the impact on the environment, and consults with the security focal to determine how serious the vulnerability is and when to deploy the fix. The spreadsheet is used to create an up-to-date report to ensure security compliance.
Deploying fixes also requires manual process. After figuring out WebSphere servers to fix, the administrator needs to find the right fix type for the server, manually download it from IBM download site through multiple steps and fetch it to their repository. This manual toil is a huge pain for our clients, they want to reduce the effort and cost.
Design statements
Before we explore solutions, we define design statements (which is called Hills in IBM design process) that describes something a specific user is enabled to do. Creating this statements with the PM and team really helped to make everyone on the same page and refer back through the design process.
Todd, a WebSphere admin, can see all of the unresolved security vulnerabilities that affect my servers and identify his environment is up to date in 3 minutes.
Todd, a WebSphere admin, can find fixes that are ready to install to resolve security vulnerabilities and schedule fix deployment so he no longer needs to stay up late or work in the wee hours of the morning.
Solution
Security dashboard
The first step to reduce users’ manual work is to provide a better presentation of the whole WebSphere environment and the security posture so the users can move away from the spreadsheet. I created a dashboard where the users can see the security vulnerability detection and affected servers so they have better awareness and can quickly respond to risks. The user can see affected servers by risk level, which reduces a great amount of time to conduct manual assessment.
While we were validating the initial dashboard design with the customers, we learned the users want to see the security status by various ways such as vulnerability centric view and customizable groupings. So I created CVEs view where users can find vulnerabilities currently affecting their environment with information about how long the risk is exposed and resolution status. To address the users’ need to customize their views, we’re currently working on custom grouping with the ability to import users’ existing grouping and tags.
To address users’ pain point of manually looking at their spreadsheet, analyzing security vulnerabilities are resolved within the enterprises’ own security compliance time window, I designed the view users can find the fix history that clearly shows vulnerabilities are resolved in time to share with the audit team.
Fix deployment automation
To understand better about users’ needs about the fix deployment, we conducted In-depth interviews with 8 customers and 1 business partner. After analyzing the data, we found three main insights. Current fix deployment process involves lots of manual effort and they want to reduce it as much as possible. However, there’s a hesitation for the full transition to automation. What if something goes wrong when automated deploying on production servers, and I’m not there to resolve? Managing storage with the fix download is another concern. With automated fix download, storage can be full and without noticing.
With the understanding of users' hesitation of full automation especially for production servers, we decided to deliver the solution in two phases. In the first phase, users have a full visibility of fixes to resolve vulnerabilities that are currently affecting their environment, and can manually install the fix. This reduces a lot of effort and process to find out the right fixes. The user can keep track of the fix deployment status and gather the idea of how much downtime takes. In the second phase, we introduce automated fix download and install scheduling. By the related vulnerability risk level and fix type, users can configure fixes that are already fetched to their repository and ready to install. To address users’ concern about the storage, they can set the auto storage clean up policy based on the fix download date and the fix type.
As I explored the fix deployment design, I questioned what would be an intuitive user flow to start installing the fix as WebSphere Automation presents the security posture by servers and vulnerabilities centric views. From early design concept feedback sessions, we found it depends on the customers: some prefer one way over the other path, or find all paths are valuable. We decided to provide multiple paths to install the fix.
Install a fix from a CVE detail page
Install a fix from a server detail page
AI recommendation for fix deployment window
Both customers and IBM business goal align about having an AI experience in WebSphere Automation. Customers expressed their need to get the AI recommendations of managing their environment optimally, and one of IBM’s design goals is to embed Watson Moment experience of many of core products. To flesh out what kind of recommendation we can provide, I and the team collaborated with the AI design team to utilize their guidelines. We conducted a series of workshops to identify opportunity areas, data we can gather and to brainstorm ideas. We narrow down to an idea of a fix deployment window: Watson Moment finds the ideal time for patching a security vulnerability on a server, helping proactively deploy fixes during low traffic times so admins can minimize downtime from weeks down to days.
The design concept is approved by the AI team and the head of design, I’m currently polishing the detailed experience.
Hosted trial experience
WebSphere Automation offers 60 days of free trial but due to the product’s on-premise nature, there’s a hurdle of installing it on the environment to try it out. To create a better trial experience, I led a 6 weeks design education program called Patterns. With diverse team members of user researchers, designers, and engineers, I guided the team to successfully come up with design recommendations by providing constructive feedback, introducing design thinking frameworks and coordinating customer interviews. Based on the recommendations, I polished the design to be consistent with other products on the platform, and the team implemented a hosted trial where the user can test WebSphere Automation features without installing the product on their environment so they can make a more informed decision to purchase.
MEasure the design impact
Unlike my other project of SaaS, WebSphere Automation is an on-premise product and has limitations of collecting the usage data. With this constraint, we use the formal IBM design & experience review as one of the metrics to measure the design impact. IBM’s design review panels assess the entire experience by different dimensions each release. In the latest release, we increased the overall grade by providing better trial, improving identified UX issues from the previous report.

