Dates: June 2021 – October 2021
My role: UX Architect
Disciplines involved: Interaction Design, User Research
Overview
IBM Support home page using the Carbon design system.
When I joined the IBM Support product team, they were in the middle of a much-needed redesign of the customer-facing support experience (https://www.ibm.com/mysupport). The goal of the redesign was to:
Migrate to a Salesforce back-end,
Update the design to IBM’s Carbon Design System, and
Make whatever user-experience updates we could along the way.
The redesign was a large multi-year effort with many parts. This case study tells the story of how I conducted some design explorations & user research for the migration of the outdated “My Notifications” experience on IBM Support.
The problem
“My Notifications” was an area on IBM Support where customers could manage their notification preferences & settings for email alerts for product content and Known Issues. These were defined as follows:
Product Content: This was defined as information about a specific product, such as news, fixes, downloads, and other product information.
Known Issues: These were basically bug reports for a specific product. They were called “APARs” at the time. Known Issues could have their own lifecycle: initial report, updates while a fix is being found, and information about a fix once it’s available.
Some of the problems I needed to solve for the team were:
The current “My Notifications” experience was separate from the rest of the IBM Support site. Users were taken to a new tab with an outdate design with many usability problems. I needed to find a way to translate the current experience into the new design.
The product team needed information on how big of a lift if would be to do the migration from a design standpoint. This had not been properly defined, and I needed to do some investigating into that.
Some requirements had already been defined. However, the main developer responsible for notifications had additional requirements, as well, which I needed to learn.
My task was to start doing some investigating into the requirements, explore some design ideas, and report back in a few weeks to the Product Owner to decide on next steps.
My Process & What I Did
Discovery sessions with the solution architect
I reached out to the Senior Architect to set up some meetings. I found out that while I was 100% dedicated to the project, he was not. The most he could really devote to this endeavor was about 1 hour a week.
We were both working remotely at the time. Because of this, proposed the following approach:
First, I would capture the current experience in a Mural board. We would review what I captured for completeness and identify areas that were causing problems.
Then, I would start iterating on some designs for key use cases. The Senior Architect and I would be meet 1-2 times a week to review what I had done and decide on next steps.
We decided to start on Product Content first, and then work on Known Issues. This was because the Product Content subscription experience had fewer touchpoints with the rest of IBM Support than Known Issues did.
Mural board showing the current experience.
During our sessions, I learned about some additional requirements from the Solutions Architect, such as:
The current “Browse for a product” experience would need to be changed because the taxonomy that was being used was outdated and difficult to keep up-to-date.
Much of the delivery preferences would be moved to a new Profile tab in Support Preferences & Settings.
We had people subscribing to RSS/Atom feeds (to my surprise), but we didn’t have any information about how they used the feeds.
I also learned that there were several touchpoints with the rest of IBM Support that we needed to consider, such as:
The actual notification emails that users received. These contained links to subscribe or unsubscribe, so we had to account for these.
The Known Issue detail page that was being worked on by the Visual Designer.
There would be a directly of all Known Issues that users could search for.
The product pages we had on IBM Support. How should we incorporate the ability to view & subscribe to Product Content and Known Issues from these pages?
Mural board showing touchpoints with the rest of IBM Support.
Design iterations
It took a few sessions, but once I had a clear understanding of the current experience, and the direction we were heading in, I started on my design iterations. I did these in Sketch using the IBM’s Carbon design system.
As part of our design iterations, I came up with three approaches, each with enhancements building on the previous option:
A parity option. This approach would meet the project requirements with minimal changes, such as text updates and adding a search widget that was being used elsewhere on IBM Support.
A parity option with some additional enhancements, such making enhancements to the subscription flow and Notifications screens for products.
A final option that also included a design approach for searching similar to what was being designed for the My Products section.
Mapping out a proposed subscription flow in Mural for Product Content.
Example of a new page for viewing all notifications & settings for a specific product. I added the ability to let the user manage their settings on this screen.
Presenting options to the product owner & larger team
After we had some options in place, we decided that it was time to update the rest of the team on where we were at. We needed decisions made on which options to chase down and what the next steps would be.
I organized my Mural board that laid out the three options and walked the team through each one.
The review went well. After some discussion, the product owner decided to go with the additional enhancements & My Products approach in the hopes of leveraging something we’ve already built.
However, the product owner wanted to run the designs by some users first just to make sure users understood them before building them out – especially the auto-subscription process that was being proposed. He wanted to make sure that he wasn’t going to get a bunch of complaint from customers about that.
I recommended that I would do some 1x1 sessions with 3-5 users, and report back after that. I chose this number because I wanted to get qualitative feedback, and wanted to see if I could find any patterns with this number. Basically, a quick reality check.
Planning the user test
The first thing I needed to do was to find some participants. I contacted the Bridge Team at IBM, which was an internal group that had done user research previously for IBM Support. They were not only helping in finding end users, but they also had research ops in place I could leverage, such as IBM-approved outreach emails.
They gave me some names and emails of customers and business partners. In the end, I got four participants to respond.
Some of the research questions I had were:
How did users react after being automatically subscribed to either Product Content or Known Issues? Would this irritate them, or would they see this as helpful? Would they care at all?
Could we leverage the same designs for both Product Content & Known Issues? Or would we need to treat them a little differently?
Would users have any issues understanding the design for the My Products approach?
How do they use and interface with notifications from IBM Support?
I was responsible for scheduling the sessions, running the test, and reporting the results.
Creating the prototype for testing
As part of the use test, I created a clickable prototype InVision. I used the designs I created and mapped out the flow like what I was proposing in the Mural board with clickable hotspots.
Map of the screen flow for the user test.
Interviewing the users
After a brief break, I was able to return to the task at hand – conducting the test.
I used the following format for the user interviews:
They would be 1-hour interviews
We would start with having them share their screen and talk to me about their current experience. What they were subscribed to & why, and how they interacted with the notifications as they came in.
Afterwards, I would send them the link to the InVision prototype and have them pull it up on their screen. I had them click through it as they would expect to and think out loud as they were doing so.
Finally, we would discuss the screens and their experience.
Highlights of my findings & reporting the results
The Product content tab tested ok – not perfect though. We would need to make a few adjustments, but nothing too huge.
On the other hand, the Known Issues concept bombed. Users were very confused about this, especially ones that had never subscribed to known issues before.
Nobody like the idea of being auto-subscribed to anything, especially bug reports.
Users viewed the experience of browsing known known issues and subscribing to them as being tightly related. We had these in separate places on IBM Support. Users expected to be able to easily view all known issues for a product while viewing a list of the Known Issues they were subscribed to.
Users viewed Known Issues as Product Content. They say the separation as artificial, and assumed (correctly) that this was because of legacy systems on IBM’s side.
I presented my findings to the Product Owner. Based on my findings we decided to move in two tracks:
Track 1 - Finalize Product Content: Move ahead with incorporating updates from the user interviews, and delivering the UX specs to the Visual Designer.
Track 2 - Take another stab at Known Issues: I would spend some time with the Senior Architect regrouping on this based on our findings.
Activities after the user test
Track 1: Finalizing UX Specs for the Product Content tab
This track was straightforward. I incorporated updates from the user interviews into the designs. After reviewing them with the team, I added my UX Specs to them and delivered them to our Visual Designer to apply detailed visual specs to them.
Example of the UX specs I delivered to the Visual Designer
Track 2: Re-thinking some key use cases for Known Issues
I set aside two weeks to re-group with the Senior Architect to take a deep-dive into the use cases that were causing problems. We met twice a week to discuss the following use cases in Mural:
Subscribing to a specific Known issue from various parts of the experience, such as:
From the Known Issue tab
From a Known Issue detail page
From the “view all known issues for this product” page
Viewing a list of available Known Issues to subscribe to…
From the subscription screen, and
From the notifications screen
Subscribing to a product
What would appear in the subscription view?
What would appear in the notifications view?
My Products: How could this page reflect that you’ve been subscribed to a product for Known Issues and Product Content.
Moving on from IBM and wrapping things up
Around this time, I took a position at another company. This worked out well in terms of the project, as the Product Owner felt that we needed to put the project on hold for a few months since I was several months ahead of development, and he needed me to work on some other projects.
I wrapped up my design work on Known Issues with the Senior Architect and handed them off to our Visual Designer to pick up at a later time.
I recommended that when they were ready that they run the new designs for Known Issues by end users again.
OUTCOMES
Based on my work, the product team had a much better understanding about what a massive undertaking it would be to perform this migration. In addition, they had a design direction they could follow based on user feedback. Because of this, the team decided to wait and tackle implementation later when they had enough resources and time to devote to the migration.