SYMPHONY

Data Loss Prevention

Min_Lpt_DLP.png

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.

My role

UX designer (in collaboration with PM partners, front- and back-end developers, and design team peers and manager).

Users

Once enabled in an organization DLP impacts all Symphony user types, with the "trader" persona considered primary.

Scope

The design process

Project kick-off

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

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.

Initial brainstorming

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

Next concept...

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.

1.a DLP_ Mockup.png

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

Guiding principles

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.

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 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

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)

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.

SendingFLOW.png

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).

Mobile flows

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.

Next steps

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.

  • Twitter - Grey Circle
  • LinkedIn - Grey Circle