Conditional masking

Org

Redgate Software

Timeline

2018

Role

Product Designer

Challenge

Our team was creating a new product to help users implement data masking in their organisation. Data masking replaces personally identifiable information (like credit card number, date of birth, address) with realistic (but fake) data. This realistic data is then used by developers and testers.

One such problem we were trying to solve was masking data based on conditions. We learnt from research about the two key scenarios:

A) Masking based on the value of another column

Some data are logically right only when paired with data in another column. E.g. Mr for Jon, Ms. for Jane. Losing that relationship can possibly break an app or introduce bugs.

B) Skipping rows based on condition

Some rows of data shouldn't be masked either because they are not sensitive or have internal meaning for developers. E.g. Row 005 in a table has a username and password that developers use to login with. Masking that row would revoke their access.

This is what we set out to solve.

Approach

Brainstorming

We kicked off this project with a workshop I facilitated. I had two goals for this session: a) be aligned around the opportunity b) generate ideas on how to solve it.

I started by replaying the problem and context, using what we learnt from research to support it. I did a quick exercise with the team to derive the value we'd be providing to our users.

We did a group exercise to ask why and so what about the problem and arrived at the value we'd be providing.

Workshop: why and so what exercise — Why and so what exercise to derive user value

By working on this, the value we'd be providing was: Masked data is more realistic if it matched the application constraints, read logically and avoided non sensitive rows of data. This would give developers and testers confidence in their work even when using masked data instead of real.

After that we started ideating, where the team put down as many different ideas as they could in 10 minutes. Each person shared their ideas while other asked clarifications. Through 3 rounds, we narrowed our ideas down to 3.

Ideation — idea 1 — The final three ideas from the ideation session

For these, as a room, we deep dived to discuss how well we thought it solved the problem, possible limitations they had and trade offs we might make.

Prototyping & Testing

All our ideas were similar where users could choose the kind of replacement data they needed and then add conditions to it. I designed the pages with Sketch and put the prototype flows together in Invision. While designing, I accounted for usability and the content.

Through 2 rounds of testing and iterating, we arrived at a design that met the user need and was usable. For each round, I conducted task tests and asked users to think out loud as they used it. The product team attended these sessions to observe, note take and debrief.

Round 1

The idea we wanted to test was providing a condition switch. The switch was available within each mask. Users can turn it on and add conditions. As they add a condition, preview data shows a sample of rows and how they'd look before and after masking.

Round 1 — Step 2: turn on conditions — Step 2: Turn on the conditions switch

Round 1 — Step 3: add conditions and a default case — Step 3: Users add conditions and a default case

Round 1 — Step 4: preview data updates as conditions are added — Step 4: As users add a condition, preview data shows how rows will be affected

We tested this prototype with 8 DBAs who expressed this need. Key findings and decisions:

Round 1 findings

2 of 8 users got stuck on the first step — they had scenarios where conditions spanned multiple masks. Decision: ideate on a new approach and retest.
Seeing before and after data change helped users feel confident their conditions would work. Decision: keep and continue testing.
If preview data had no examples matching their conditions, users lost confidence. Decision: sample and display data that matches their conditions.
'Add a default' at the top confused users — only after exploring did they realise it was a catch-all. Decision: move to bottom, rename to 'Add a fallback'.

Round 2

We needed to update the designs to support the scenarios uncovered in round 1.

Most users wanted to add conditions within the same mask. For example, if gender was F, replace with female names. If not, replace with male names. However, some users needed to add conditions across multiple masks. For example, if credit card number was from Barclays bank, use a UK address. If it was from DKB bank, use a German address. The current design couldn't solve for this.

To solve this, I suggested we move Conditions up in the hierarchy to make it its own type of mask. This mask can then support both within and across scenarios.

Round 2 — Conditional mask as its own type — Conditions promoted to a first-class mask type, supporting both within and across scenarios

We tested with 8 more DBAs who had a mix of within and across scenarios. The change tested positively and specifically satisfied the scenario we discovered in the previous round.

Impact

Delivering this feature added significant value to beta users. Adding conditions meant they could provide more realistic data to developers than they could before.

For the team, it was a milestone to solve this user need. It gave us confidence as we were progressing towards a v1.

Reflection

Usability testing shouldn't just be viewed narrowly as a way to see how usable the designs are. In this project, by testing iteratively, we uncovered a gap in our understanding and were able to solve for it.

← All work