Data Loss Prevention
About the project
Admin policy setup flow and 14+ end-user touchpoints. To simplify, this case study focuses only on phase 1 and 2 of the message sending experience in chat rooms.
The project shipped in 2018.
Symphony is a team collaboration platform. Key clients needed to reduce the risk of sensitive information being leaked. Data loss prevention (DLP), helps manage risk by preventing messages with user-specified attributes from being sent.
UX designer (in collaboration with PM partners, front- and back-end developers, and design team peers and manager).
Once enabled in an organization DLP impacts all Symphony user types, with the "trader" persona considered primary.
The design process
I met with the lead PM and devs to review the technical spec. The initial timeline was estimated at a couple of months. Due to the complexity of the project, a few followup meetings with the PM were needed.
When felt I understood the problem, I started looking for competitive products. Most competitors apply DLP systems to email and the workflows were more complicated than what we needed. Even so, the research helped clarify how DLP systems work, terminology they use, and how our system could evolve in the future.
The first idea I explored along with some team members was to initiate DLP scanning in the text editor as the user types.
We sketched ideas on a whiteboard and reviewed the concept with the PM and lead developers. Unfortunately, this approach wasn't ideal:
Keyword dictionaries would be updated as often as every 15 minutes, forcing a client refresh (and possible re-login) for each update
Policy storage and heavy data crunching in the local client would negatively impact performance
Since scanning as the user types wasn't possible, the next concept I explored was to scan in the text editor after the user hits "send". This would prevent messages in the chat stream from becoming out-of-order and avoid potential confusion for recipients.
I created some basic wireframes to illustrate the flow.
I reviewed this idea with lead PM and 2 other PMs whose teams would be involved in development, and there were some problems:
Sending state in the text editor inhibits rapid-firing messages, which wouldn't work for the primary "trader" persona
There were too many existing patterns and strong pushback against introducing a new pattern at this time
A separate project to update the text editor was underway, and the text highlighting was too expensive to justify
Going forward, to keep user and business needs front and center I outlined some basic principles that would help guide the design process. DLP must:
Be attention-getting in an information-dense UI
Provide enough information to make users confident in their actions
Reuse existing patterns whenever possible
NOT interrupt or block normal user workflows
NOT impact system performance
2nd iteration - user testing + dogfooding
Incorporating the feedback from previous ideas, I created a new flow based on the existing pattern for failed messages. This flow scanned messages after posting and presented the error in the chat stream.
Project stakeholders were on board with the idea so I created a low-fidelity prototype for testing with internal users.
Because the "busy chat room" environment couldn't be replicated well in an Invision prototype, we implemented a live version for dogfooding.
"I keep having to go back and forth between the banner and the message."
Test results: Users struggled with the proximity between the banner and the failed message. They also felt that the actions being in a menu created an extra click, and that the failed message was disconnected from the error details.
Dogfooding also revealed some banner conflicts that were unexpected.
Aside from the problem with proximity, there were some other issues with the banner proposal. I met with some design team members to review the test outcomes and most problematic edge cases:
File scanning would create even more information density in banners
Conflicts with multiple banners
Behaviors in tiny chat modules (modules can be as small as 300x300 px)
Banner content doesn't reflect current state as the user takes actions
Conclusion: A new pattern was needed - although using existing patterns technically "worked", it didn't produce a good UX.
I partnered with the research team to create a journey map to visualize the essential steps for the MVP and ensure nothing is missed. (Recreated with Mural)
Back to the whiteboard...
The previous solution wasn't cutting it from a UX perspective so I got together with some design team members to figure out how we could improve on the experience.
We landed on a pattern that resulted in a pass rate over 90%.
DLP errors appear inline with the offending terms highlighted
Actions are visible in proximity to the errored message
Error details are displayed in a modal
Phase 2: Scanning attachments
This phase of the project included scanning file content and metadata. I circled back with the PM to map out the end-to-end process of attaching, previewing, and sending files, and came up with three possible flows for scanning attachments.
Each approach had pros and cons, so we brought in the system architect to determine risks and feasibility.
Flow 1 - Scan during attachment preview: Not technically possible - files are stored in the front-end at this point
Flow 2 - Scan as files are uploaded: Possible but not feasible in the short term due to time and resource constraints
Flow 3 - Scan after sending into the chat: Possible and feasible in the short term, so this is the approach we took (with the agreement that flow 2 will be revisited in the next phase)
Phase 2: Sending state
The flow chart illustrates rules for sending states before DLP and after.
Note: More than one error could occur due to encryption and network errors.
System performance is critical for Symphony's primary users. Animations are minimally used due to performance impacts on older systems - some clients disable them entirely.
The system was architected such that from the sender's viewpoint a message can appear as sent before the recipient sees it.
DLP processing can add significant time to this ambiguous state now that file scanning is in play. To address potential for confusing interactions if an error occurs after a message is seemingly sent, a "sending" state was needed.
State transitions & "ignore" flow (low-fidelity)
Phase 2: Incorporating files in the error pattern
There were some complications in phase 2 that had to be considered:
Message content can generate warnings that can be ignored
Files can only be blocked
It's possible to have each type of error in a single message
The error pattern had to accommodate the most complex scenario, a message that has a warning and can still be sent + files that are blocked and can't be sent (edge case, added to support trader workflow).
I helped the mobile designer to develop the initial flow used in the mobile app. These were finalized by the mobile team, but I created the first concepts using mobile screens and patterns.
Two patterns were under consideration - one using an overlay and one using banners. I collaborated with the mobile team throughout the process.
We planned to continue to improving the experience and instrument the workflows to analyze usage patterns. More immediate improvements:
Extend highlighting to the text editor for the edit flow
Update parts of the system architecture so file scanning is more efficient
What I learned...
A solid project plan and more up-front work to think through the technical aspects would have helped reduce churn and manage expectations. We started on a short timeline but kept bumping up against technical limitations, and the project was paused multiple times.
Also, the initial thinking that DLP would affect all users equally was wrong - it turned out that certain personas with unique workflows would be more impacted. Because of this I spent some time iterating designs that wouldn't meet primary user needs.