Case Studies
Three problems, one flexible toolkit
Redgate Software
SQL Census
The challenge
Database permission management is a deeply complex space. Large organisations often have thousands of permissions spread across many servers. Making this landscape understandable and actionable was the core design challenge.
The existing database permissions landscape: thousands of interconnected nodes
My role
Product Leadership Team: Product Designer
My toolkit
The calls and interviews
Continuous discovery calls were made, keeping in contact with participants almost every week.
We created a co-creation Early Access Program for users who were particularly keen on solving this problem with us.
The surveys
We used surveys to understand what, rather than why. We surveyed to find out:
- The value of the problem
- The profile of our users
- What they were trying to solve
- The extent of the problem
- The regularity of the problem
The async research
In order to keep in close contact with our participants, we opened several avenues for them to give feedback async. This included in-application feedback via Intercom and also we invited them to join a private Slack channel so feedback could be done in a conversational format.
Research analysis: synthesising discovery findings
Usability testing
We ran usability testing sessions throughout the project to validate designs and surface friction in the flow.
Usability testing: validating designs with participants
The personas and JTBD
We identified 3 core personas and JTBD in our research. The consultant, the DBA and the IT Manager, each with their own set of core pains, JTBD and organisational constraints.
Which was defined by sub-jobs such as:
Example persona
User persona: core pains, JTBD and organisational constraints
Value props
We broke down all the Value Props for each persona type. We used these to gain an understanding of the user types. We discovered that not all Value Props are created equal and each had a business value more significant than another.
Value Proposition Canvas: mapping gains, pains and jobs-to-be-done
The feedback loop
Throughout the entire life cycle of the project, the continuous feedback through all our mechanisms allowed us to keep on track on what we were building. It made sure we were going in the right direction and added problems onto the roadmap. We would quickly solve issues and pivot if needed.
Workshopping
We ran multiple workshops from How Might We's to Sketching sessions to Crazy 8's. Each with the intention of going wide with our chosen problem.
User flows and architecture
By mapping decision trees for the user and breaking down UI flows and architecture we built a few prototypes. These early flows and designs were tested with users during our regular research sessions.
Early wireframe sketches from workshopping sessions
Workshopping session
Core problem 1: Understand
Feature: "Trace user access"
Users could understand their permissions landscape. Given 1000's of permissions, we allowed them to understand what was given, how it was given and surface the most dangerous.
Inspect Server: tracing permissions at a glance
Core problem 2: Remediate
Feature: "Extract database role"
The user could create manageable groups from the current state. Merge many common permissions to ease the pain.
Extract Database Role: grouping permissions for easier management
What we built
We created a product called SQL Census.
Let us imagine you are in charge of security of physical building. You have to give keys to several workers who need access. And now imagine these keys also need access to other rooms in other buildings. You can lose track easily.
We built a product to help people secure their "buildings" by figuring out who had keys, who has master keys, how they obtained those keys. It also helps you understand if you can combine certain keys so your management task is easier.
The results
Project still had people interested in it 1 year after we closed the research project, with no real marketing effort.
User feedback
Redgate Software
REST API
The context
Large enterprise organisations typically need a "single pane of glass" to understand several sources of application data. Redgate Monitor only provided part of that story.
Redgate Monitor: the starting point, one tool in a larger enterprise stack
My role
Product Leadership Team: Product Designer
My toolkit
The calls and interviews
Enterprise customers are sometimes tricky to engage with. Their time is expensive and their problems are bigger and more complex. Feedback cycles are longer. So we had a handful that worked with us privately to understand their core problems.
Key enterprise partners
We also leaned on the expertise of an internal ex-DBA who had worked extensively in enterprise orgs.
The surveys
Aside from qualitative data we also ran surveys to gain quant. We knew that users wanted to use Redgate Monitor data in other places but still wanted to learn:
- The profile of our users
- What they were trying to do with the data
- The cadence and level of pain
- Where the data would be utilized
The JTBD
Which was defined by sub-jobs such as:
The workflow
Redgate Monitor only provides part of the database devops and monitoring story. Large orgs need a single pane of glass to understand several sources of application data.
Workshopping and ideating
We ran several workshops such as HMWs and assumption mapping to letting users expose their underlying data was not only a question of usability. It was a matter of how to do this is a secure manner which worked with the users workflows.
Internal usability workshop with the team
The solution
We shipped a read-only REST API. This allowed us to maintain control of the flow of the data for stability, yet also stay flexible in how we change our internal data structures.
The REST API documentation, designed for clarity and ease of integration
Design value opportunities
Unlike traditional UX, the opportunities for design value for developer experiences are a little hidden but still plentiful. Some identified where we could bring design value were:
Feedback so far
We keep in close contact with our co-creation cohort and have been gathering feedback to see design opportunities. Although uptake has been slow, which is might be expected in Enterprise orgs, we are now beginning see more interesting problems to solve.
Further opportunities
Redgate Software
Compliance and Policy Audit
The starting point
The team inherited an MVP from a research team. Our mandate was to identify its gaps, understand what users truly needed, and design a scalable solution that could serve multiple compliance frameworks and database engines.
The inherited MVP: functional but inflexible and not solving the core JTBD
My role
Product Leadership Team: Product Designer
My toolkit
Research participants
We also leaned on the expertise of internally hired subject matter experts, specifically Ex-DBAs who specialised in the financial sector who needed to maintain and prove secure database estates.
Additional feedback
I also did a deep dive into support tickets and ad-hoc feedback from customers regarding the MVP. It became apparent that the product had a number of pain points. The MVP was:
- ✗ Inflexible
- ✗ Not scalable to support other database engines
- ✗ Not providing accurate scoring
- ✗ Not solving for "Reporting" as a core JTBD
- ✗ Not scalable to support more benchmarks
The JTBD
Which is defined by sub-jobs such as:
The workflow
A lot of enterprise companies are given external benchmarks to adhere to: CIS benchmarks, NIST, HIPAA, STIG etc. The workflow needed to support many benchmarks and be scalable enough to support many types of database engine: SQL Server, Postgres, Oracle.
Key roles in the workflow
In charge of compliance and security of entire infrastructure
In charge of compliance and security of database estate
Ideating with Claude
After fully understanding the JTBD, I paired with Claude to build a prototype to show to users and internal experts.
What we designed
- ✓ See a live compliance score across the entire SQL Server estate
- ✓ Apply industry-standard CIS benchmark policies out of the box
- ✓ Build custom policies tailored to the org's own controls and obligations
- ✓ Scope policies to specific servers by SQL Server version and tag
- ✓ Browse and select from a library of predefined security checks
- ✓ Write custom T-SQL checks when the library doesn't cover the need
- ✓ Edit existing policies without starting from scratch
- ✓ Drill into failing checks to see which assets are affected and why
Policies overview: built-in and custom compliance policies at a glance
Custom T-SQL Checks: write your own security rules when the library doesn't cover it
What we're building
I have created a clickable prototype representing the first-stage design vision for the product, intended for user testing and starting discussions.
This prototype acts as a valuable communication tool across internal and external stakeholders, helping us identify the highest-value features and make informed prioritisation decisions, irrespective of what is ultimately built.
User feedback so far
Further opportunities
