diana
bloom
SYMPHONY
Data Loss Prevention
Summary
Symphony is a team collaboration platform. Key clients needed to reduce the risk of sensitive information being leaked internally and externally. Data loss prevention (DLP), helps manage risk by scanning messages and attachents, and preventing content with specific text strings or other attributes from being sent.
My role
Lead UX designer. I collaborated with PM partners, front- and back-end developers, and design team peers and manager throughout the process.
Users
Once enabled in an organization, DLP impacts all Symphony user types, with the "trader" persona considered primary.
Scope
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.
Design Process
To kick off the project, 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.
Competitive research
Once 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.
Initial brainstorming
The first idea I explored along with some senior design 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
Next concept...
Since inline scanning 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
Challenges
DLP had some unique challenges due to the nature of the feature, the Symphony system architecture, and the inherently "noisy" work environment of its users. As the designer, I had a lot to think about:
-
The feature had to grab the user's attention, but not interrupt or block their workflows
-
A notification center was planned for a future version of Symphony, and was not able to be developed in advance of this project
-
Users had to be provided enough information to make confident choices without being overwhelmed with details
-
Existing patterns needed to be used whenever possible, and the pattern had to be reusable across multiple touchpoints (including mobile devices)
-
The DLP engine is on-prem, and scanning required a complex process could not appear to 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 so I could do some user testing. 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.
Team review
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.
Journey map
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 teammates 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
Low-fidelity mockup
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)
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.
Phase 2: Display of attachment errors
There were more complexities 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).
Inline error with warned terms and a blocked file
Modal showing error details
Inline error with warned terms and a blocked file
Mobile flows
I worked closely with the mobile designer to develop the initial flow used in the mobile app, and created several screens illustrating two initial concepts.
The mobile flows required heavy collaboration because the use cases and technology stacks were so different from the desktop app, so there were several adjustments needed. For example, it wasn't possible to edit a message and retain attachments on mobile.
Next steps
We planned to continue to improving the experience and instrument the workflows to analyze usage patterns. More immediate improvements:
-
Incorporate a new notification center
-
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 issues and 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 work. Up-front time to make sure all stakeholders had input would have helped clarify primary user needs earlier.