Overview

A seven week speculative project to tackle security patch planning and installation on IBM Power Systems servers. The project went so well that IBM assigned a team to turn it into a real product and it's been used as an example by Phil Gilbert, the General Manager of Design at IBM, in multiple talks. 

“This is the best story of design at IBM in the last three years… The team came to them saying they need one-click firmware updates for Power Systems… By doing field research, they found out that this was a human problem, not a system problem. Not only did research inform what they built, but what they built was beautiful itself as well.”

— Phil Gilbert, General Manager of Design at IBM

Role

I was one of two UX Designers on this project on a team of six Designers and Developers. I also helped our Design Researcher perform user interviews and user testing sessions. 

The Ask

The IBM Power Systems team tasked us with designing a better way to perform security updates on their servers. These servers often contain the most critical workloads and data at companies and governments who use them. A security breach could cost millions of dollars and the loss of customer trust.

One of the asks was to design a one-click update system, which, through research, we later realized was not what users wanted.

Research

We interviewed an array of users from multiple companies to gain a better understanding of the user journey and start identifying the painpoints.

We found that there were three phases of the patching journey: find, fix, and report. Talking to users it became clear that though the fixing part of the process was one of the more painful, they didn't want an automated one-click process. They knew there there was too much variability from system to system to depend on automation, and this was the part in the process when things can go wrong.

We discovered that the big opportunities lay in the finding and reporting phases. These were areas that required hours of manual searching, reading, and data wrangling, but could easily be automated. 

"I spent 25% of my time during the first half of the year prepping for our audit in July. Project Monocle would have probably saved me easily 5-10% of my time to get this done. That may not sound like much, but multiply it by 50 hours per week, at a manager pay rate, with all of the weeks required and that is a lot of time."

— IBM Power Systems Customer 

Design Process

Armed with a clear path forward, we started wireframing, prototyping, and testing with our users. By the end of the project we had a functional front-end prototype that our users.

Final Designs

Action Oriented

A theme that came up time and agin with users was that they wanted a tool that was action oriented. They didn't want another dashboard of data, they wanted a toll that told them were their problems were and helped them fix the issues.

"I only want to know what’s wrong. It would be great if it could just tell me exactly what I need to do, rather than searching for it everywhere."

— IBM Power Systems Customer

Extensibility

This project was focused on a security patches for a specific component, the HMC, but we needed to design a platform that was extensible to other components in the future.

HMC updates are generally not as difficult to take care of…where this will really make an impact is when it scales out to VIOS, OS, etc."

— IBM Power Systems Customer

Outcomes

This project was a widely celebrated success. We were selected as the only new hire team to present to Phil Gilbert, the General Manager of IBM Design. Since then a team was assembled to build Monocle into a real product and it is currently in a public beta.

Watch Doug Powell, an IBM Design Principal, use Monocle as an example of how IBM uses design to drive outcomes.