Some elements on this page may not function normally with JavaScript disabled. Please enable JavaScript for the best experience.
Case Study:
Db2 Warehouse on Cloud: Audit
Outline
Overview
Description
IBM Db2 Warehouse on Cloud (WoC) is a fully managed, elastic cloud data warehouse. Database administrators working in Db2 WoC must follow regulations with auditors to ensure that all the operations on their database are within compliance rules. Until now, all of the auditing functionalities were hidden behind APIs and custom SQL scripts. My task was to transform this clunky, documentation-heavy tool into a simple and efficient UI-driven process.
Roles
As a UX/Visual Designer, I designed the flow of the experience, the user interface, and the various interactions within the UI.
I also took on tasks that a User Researcher would complete, such as drafting a research plan, testing my concepts with users, and synthesizing the results to iterate on the design.
Collaborators
Jillian Quiller - Design
Maryia Rakina - PM
Kanchana Padmanabhan - Eng
Zhiyi Xiang - Eng
Vaishnavi Ramapriya - Eng
Theresa Faught - Research
Chris Alfonso - Content
Methodology
Personas
Storyboarding
User Stories
User Flow Mapping
Concept Testing
Lo-/Hi-Fi Prototyping
Foundations
Business Request
I collaborated with our PM and dev stakeholders through Mural. Blurred for confidentiality.
The original request for this design work came from our PM, who had been talking to customers with multiple complaints. One, our users, who are primarily database administrators (DBAs) were currently being forced to store audit files in their own database, clogging up storage space that could be used by other things. Two, auditing was very complex to set up; our users had to read through extensive documentation and work through SQL to set it up themselves. The goal was to design a UI-based solution that simplified the process of setting up auditing and gave users an alternative file storage solution.
Requirements Gathering
With this information, I set out to gather my bearings. As an established, enterprise product, there was a lot of history for me to understand first. This involved reading through the documentation myself and having difficult conversations with developers to understand the architecture, which was one of my biggest challenges. In order to illustrate some technical requirements, my developers were kind enough to develop a rough implementation of a concept that would fulfill these customer requirements.
Through reviewing this implementation with our PM and going through various design thinking activites together, including writing user stories, we were finally able to align on a single design goal:
Developers provided a quick and dirty implementation to illustrate the basic requirements.
Design a solution to help DBAs easily manage the collection and access of audit logs so that they can always ensure compliance without worrying about complex, time-consuming details.
Final Screens
Back
1. Empty State
Upon the user’s first visit to the “Audit” tab, they will not have anything set up yet for auditing. The empty state makes this clear and provides the user with a simple call to action. This way, the user clearly knows what to do in order to proceed.
2. Enable Auditing
As the user goes through the flow to enable auditing, the steps are clearly outlined in the progress indicator on the left side of this tearsheet. As the user steps through the flow, each page has descriptors and guiding text to help the user as much as possible.
3. Custom Audit Policies
Since configuring audit policies must still be done through SQL, the users are now provided with a few templates that they can use to quickly get started with auditing. The decision for which templates to include came out of user research sessions.
4. Review and Save
When the user is finished with all of the necessary steps to enable auditing, they have a chance to review the settings they’ve selected and make any last minute changes before moving on. The settings are grouped logically and presented in a scannable format.
5. View All Audit Files
After auditing has been enabled, the system will begin to automatically collect audit files. This is where the user can browse through all of the files that have been generated so far, with options for searching, sorting, and filtering to find the exact file they need.
6. Preview a File
These audit files can potentially be huge—but our users still want to be able to quickly preview a file to ensure that it’s the one they’re looking for. Within our UI, our users can preview the first 10 rows of a file, with a quick link to download the file if they think they’ve found the right one.
Next
Design Process
Storyboarding and Flow Mapping
To begin the design process, I first wanted to better understand the process that our users go through, both in its current state, and in the new, reimagined experience. Not only would this help myself ensure that I would be designing with our users in mind, but it also helped me gain alignment with other stakeholders on the kind of experience we were aiming to deliver. To do this, I created a few storyboards to illustrate the current, non-ideal experience, contrasted with some user flows to represent where we wanted to be.
Through the storyboards, we can see that there are quite a few frustrations that user might encounter in today’s experience. The barrier of extensive documentation, only being able to work in the command line, and lack of configuration options make database auditing a tedious action to set up.
The reimagined user flows are both simple and straightforward. I wanted to ensure that our users would have a clear work flow through our tool, minimizing the chances to get lost or stuck. Database auditing and compliance with regulations is enough of a headache on its own—the process of setting it up should not be adding any undue stress.
Two simple storyboards I created to illustrate the frustrations of the current experience.
The reimagined user flow, emphasizing straightforwardness and simplicity.
Lo-fi Concepting
With my foundations fully set up, and alignment on the high-level requirements from product management and software development, I moved on to create low fidelity wireframes in order to continue our discussions. While I iterated on these wireframes, I regularly brought them back to our cross-functional syncs to facilitate discussion from our stakeholders about more technical and granular requirements. During this stage, many things came up that we had not considered when we were just looking at storyboards and flows because now, the UI microinteractions could be properly scrutinized, in terms of both technical feasibility and product release timelines.
One challenge in particular came up during this stage in the design process. We had originally aligned on allowing users to set up an external storage option (using object storage) for storing their audit files. As I was creating quick lo-fi mockups, it became evident to the rest of our stakeholders that this feature was not something we could contain for the upcoming product release. Thankfully, because I was working in low fidelity, it was easy to have rapid back-and-forths about what could be feasible and what couldn’t. In the end, we ended up deprioritizing that aspect and pushing it out to a future release, but it was thanks to the quick, iterative nature of lo-fi concepting that we reached that alignment.
An example of a quick and dirty pencil sketch for my first stab at imagining the UI layout.
A screenshot of some lo-fi wireframes created using InVision Freehand. Blurred for confidentiality.
UX Enhancement
As I continued to iterate on our designs, an idea popped into my head: since the design goal is to reduce as much complexity as possible, why don't we give our users some templates out of the box to get started as soon as possible?
To provide a bit of context, the way that users can configure what events to collect logs for is through audit policies. These audit policies are written in SQL, which is not a problem for DBAs, our main persona. However, I proposed that we could still make their job simpler by removing the need to sift through IBM-specific documentation and get started quickly with predefined templates.
A comparison of the current flow with the reimagined, ideal flow.
Concept Testing
An excerpt from the research plan and script for the study.
The proposal was well-received by my product stakeholders. However, we quickly ran into a roadblock during internal discussions: which policy templates should we provide out of the box?
In order to provide real insight to drive the design forward, I decided to conduct a user research study that consisted of a generative section and a concept test. Not only could I provide answers to the most pressing question, but I could also test my flow for general usefulness and ease of use—two very important aspects of good design. I came up with a research plan and in total, conducted 5 user research sessions.
The results of the study were invaluable; not only did the users provide us with all of the answers that we were looking for, they went above and beyond, providing additional insights about how to improve the layout and flow of the UI designs. The experience further reinforced the fact that research is essential—there is no replacement for talking with real users. With the results in hand, I went back to my product team to summarize the results of the study, providing design recommendations and next steps for our stakeholders to commit to. Below is a summary of the major findings.
My idea to provide predefined sets of policies for our users to take advantage of for quick and easy set up was well-received. Through this study, we were able to understand what events DBAs were auditing most frequently and incorporate them as templates in our product.
While conducting the study, we also uncovered some settings that DBAs wanted to configure when enabling auditing, in addition to the ones we already had. Through the concept test, we were able to identify these gaps between the design and our users' expectations, which I addressed with further design recommendations.
Design & Implementation
Armed with the results of the user study and the go-ahead from PM and development, I began to design the UI and experience in high fidelity. One unique aspect of working as a designer at an enterprise like IBM was the need to adhere to design system guidelines and patterns. While I had kept those in mind even while I was working in lo-fi, this was the time to ensure that my design was compliant with Carbon, IBM’s design system. Thankfully, this was the easiest part of the whole process and I was able to quickly convert my designs into hi-fidelity, handing off the screens you saw above, along with design specs, to my developers for implementation.
Of course, the design process didn’t end there. As the developers implemented my designs, I remained on stand-by as they regularly consulted me with questions about the design. I also conducted a QA review by going through a mock implementation they provided for me and documenting visual bugs and issues with the interactions. Although I ended up switching teams within IBM before the implementation was finalized, the code was eventually completed and went live in our product, IBM Db2 Warehouse on Cloud.
Conclusion
Design a solution to help DBAs easily manage the collection and access of audit logs so that they can always ensure compliance without worrying about complex, time-consuming details.
Result
Reflecting on the original design goal, I feel that I had met all of the criteria needed to consider the design of this feature a success. Where DBAs previously needed to sift through extensive technical documentation and struggle through complicated SQL syntax, I had now given them a way to quickly and easily set up auditing through a graphical user interface. I worked efficiently with our stakeholders and backed up design decisions with user research, delivering a full end-to-end experience in time for our product release cycle.
Retrospective & Next Steps
Start Researching Earlier: The feedback that we had gotten from users through the concept test was invaluable and enabled us to get unstuck. In retrospect, I wish that I had been able to begin speaking with users earlier in the process—perhaps we would never have even gotten stuck in the first place. Obviously, with limited time and resource, this isn’t always possible, but I definitely see its value.
Look Towards the Future: Although I ended up switching teams at IBM shortly after handing off the designs, I would have liked to continue looking at items that we deprioritized and items that came up during user interviews. By continuing to iterate and incorporate customer feedback, we would be able to provide a truly delightful experience.
