Work sample from this case study

Case Study:
Secure Threading for Encrypted Email

✔ In Production (2021)


Overview

Virtru’s Secure Reader (SR) is a web app that allows reading and replying to encrypted email. But SR displays only one message at a time. Following an encrypted email conversation means jumping between your email client and SR to read more than one message. Virtru customers need to see earlier encrypted emails in a thread with minimal friction in a performant way, even for long threads.

Skills Used

Problem Definition

Secure Reader users want to read all the messages in an encrypted email thread even if they open a later message. Currently, users have to find separate emails in their email client and click a link to Secure Reader to decrypt each individual message.

Step 1. Find latest encrypted email (2 of 2)

Encrypted email 2 of 2 in email client

Step 2. Authenticate & decrypt latest email

Decrypted email 2 of 2 in Secure Reader

Step 3. Find previous encrypted email (1 of 2)

Encrypted email 1 of 2 in email client

Step 4. Authenticate & decrypt previous email (1 of 2)

Decrypted email 2 of 2 in Secure Reader
Challenges:
  • Understand if users expect "threading" to mean conversation view, quoted content, or something else.
  • Preserve as much email context as possible.
  • Must not sacrifice performance or time to decrypt.
  • Must work well on mobile web.
  • Ideally, support threads of any length (1 message to many).

My Role on the Team

Design Process

Product Management asked me to design for Secure Reader (SR) threading in Spring 2021. Engineering had already started evaluating technical feasibility and exploring implementations. My first discussions and anecdotal research ensured we built the best slice of this feature, not everything various customers thought it should be.

1. Choose “threading” definition

The first problem was that email “threading” is ambiguous.

Conversation view in Gmail and Outlook

Gmail conversation view example of threading - 5 messages
  • Messages with a shared subject line are displayed in a list where each message is given a similar visual treatment.
  • Earlier messages are visible by default.
  • Messages may or may not have quoted content in the body of each
  • email. Expanding the quoted content shows earlier messages.
  • Typically chronological (oldest to newest)

Quoted content in the body of an email

Quoted email example of threading - 2 messages
  • When composing a reply or forward, most email clients insert the
  • previous message body as a quote into the bottom of the new email.
  • When reading an email with a quoted message, earlier messages are
  • collapsed by default.
  • Quoted messages are given different visual treatment from the
  • currently viewed or composed message.
  • Typically reverse chronological (newest to oldest)
Both conversation view and quoting preserve context. Either would help SR users understand more about where the currently unlocked message fits in. So which should we do?

Conversation view as "SR threading"

Upsides
  • Easier to follow the conversation because each message has the same visual weight.
  • Existing message design already works for smaller resolutions like mobile web.
  • Future-proofing SR — a similar visual treatment of each message leaves room to show security controls (e.g. revoke, expire, watermark, etc.). This enhances the security of messages you send.
  • Future-proofing SR — a similar visual treatment of each message leaves room to reply to earlier messages directly from SR.
Downsides
  • For performance reasons, we shouldn’t load the entire conversation like an email client. Decrypting every earlier message would make reading the latest message take too long.

Quoted content as "SR threading"

Upsides
  • Since the UI emphasizes the current message and not earlier ones, it’s faster to read.
  • Also faster to scan for and read in cases where earlier messages aren’t useful or necessary to the context of the current message.
Downsides
  • Each quoted message shrinks the width available to display the message body, like Russian nesting dolls.
  • Readability suffers for longer conversations.
  • Because SR has to work on mobile web at a minimum resolution of 375x667, there may be no readable mobile layout for longer conversations. Landscape orientation could help here, but if the quotes continue, that will eventually find a limit as well.
I choose conversation view as "SR threading", because it had more upsides and felt like a more modern approach.

2. Account for all message states

I sketched out the message states in my notebook as I understood them. Engineering helped me confirm and revise the possible transitions: Proposed transitions for Secure Reader threading

I'm a fan of using the five states from Scott Hurff's UI stack as a starting point for most designs: ideal, loading, error, partial, and blank.

But the five states wouldn't be enough considering how many possible states there are for each encrypted messages. These became my design checklist to confirm I covered the entire experience:

3. Design for mobile web

I started with mobile designs; it's easier to scale up to larger screens than shrink the experience down.

If this is our current state (1 of ? messages in a thread decrypted)… Current state of Secure Reader - 1 decrypted email, no threading

An ideal state would be (all messages in a thread decrypted)… Ideal state of Secure Reader - 2 decrypted emails in a thread

We just need a transition affordance, like "Read previous [message]" or "decrypt previous [message]" to start off the process. Ideally, reading previous messages scales to long threads without security or performance penalties. Threading states in Secure Reader - unsupported, 1st message, 2nd message, Nth message

Here's what a transition looks like… Decrypting the previous message in a thread in Secure Reader

Many things can go wrong when trying to decrypt a previous message (as listed in the section above). My designs included many auxiliary screens to describe security logic: Numerous checks when decrypting a previous message in a thread in Secure Reader

Though the number of interactions and hotspots exploded… Screenshot of dozens of Sketch hotspots to support Secure Reader threading design …most error states were as elegant as this… Screenshot of typical error state designed for Secure Reader threading

4. Confirm direction with stakeholders

When I demoed the mobile web design prototype before proceeding, there was pushback from stakeholders. I persuaded the team to not decrypt more than one previous message at a time.

Everyone was excited we were bringing threading to Secure Reader (SR). But most people asked why we weren't decrypting the entire thread of previous messages.

How I defended my design of one previous message at a time:

  1. Simple enough to learn
    We decided to not pause for primary user research up front, but there's more than one possible solution. Customers did not express a preference for how Secure Reader should do email threading. The quoted approach to threading, which we are not pursuing, could be what ultimately works best. So why build the maximum version of conversation view without this clarity?
  2. Performance concerns
    How would decrypting more than one message at a time stay quick and accessible for longer threads? We already have at least half a dozen error states for each message, how would we handle errors for multiple messages?
  3. No historical data
    We had no data on how far back in a thread customers read or want to read. This was not something we tracked in Virtru's other email products.

5. Design for desktop web

The mobile screens scaled up nicely to the larger resolution of desktop browsers.

Here's what a transition looks like… Decrypting the previous message in a thread in desktop web Secure Reader

An example error state… Screenshot of typical error state designed for desktop web Secure Reader threading

An ideal state (all messages in a thread decrypted)… Ideal state of desktop web Secure Reader - 2 decrypted emails in a thread

6. Usability test

Before launch, I worked with one of our User Researchers to evaluate the effectiveness of the design with 10 external users. We recruited participants via UserTesting.com. We split participants into two groups—current experience vs. new experience.

Current experience—no threading

  1. See Gmail inbox with unread messages
  2. Open Gmail conversation to see latest message encrypted
  3. Load Secure Reader in new tab to decrypt
  4. See latest message decrypted (2 of 2) A decrypted message without threading in desktop web Secure Reader
  5. Navigate back to Gmail conversation
  6. Expand previous message in Gmail conversation
  7. Load Secure Reader in another new tab to decrypt again
  8. See previous message decrypted (1 of 2)

New experience—threaded secure messages

  1. See Gmail inbox with unread messages
  2. Open Gmail conversation to see latest message encrypted
  3. Load Secure Reader in new tab to decrypt
  4. See latest message decrypted (2 of 2) with link to previous A decrypted message with threading support in desktop web Secure Reader
  5. Load previous message
  6. See previous message decrypted (1 of 2)

We hypothesized that participants would spend less time to get to previous messages with the new experience and rank it as easier to use.

Our hypotheses proved accurate, so we proceeded to production. Slack results of high-level takeaways of user test of Secure Reader threading

7. Track production metrics & customer feedback

I advocated for us to measure more than simple clicks on the previous message CTA. With my involvement and planning, we were able to instrument the entire threading experience. Our resident product data expert was glad to be included and helped refine events and properties.

Within a day of launching, threading was available for ~33% of encrypted messages: Screenshot of day 1 - Secure Reader threading available on 43,940 messages, not available for 134,826 messages.

Quantitative answers I sought

  1. How many people that decrypted an SR message that’s part of a thread, used SR threading to read at least one earlier message? This helped us know the new UI was being noticed and used. Screenshot of week 1 Secure Reader threading funnel from previous message shown to successfully used
  2. Of those people (in 1), how many previous messages did they try to read? This helped us decide if we need to build any kind of bulk decryption for previous messages. Since most users only went back 1 message, we built the right subset of this feature. Screenshot of week 1 < 4% people read more than one previous message with Secure Reader threading
  3. What is the success rate of decrypting previous messages in SR threading? How does that compare to the success rate of decrypting in SR overall? This helped prove we actually solved the user problem of seeing earlier parts of the conversation without going back to their email. Screenshot of week 1 98.4% successful decrypts for Secure Reader threading

Qualitative feedback

Equifax loves it. Verizon didn't realize it rolled out but after we showed them they were happy about it. Capital One felt similarly.

- Virtru Enterprise CSM

Art's willingness to dig in quickly and iterate on a minimal, slick UX for the feature was key to getting this win. And Secure Reader threading was essential to our successful roll-out at two of our largest customers - Dish and Equifax.

- Virtru CEO

It comes up occasionally and customers are delighted by it.

- Virtru SVP of Customer Success

Retrospective

I'm satisfied with the initial impact of this design. I'll revisit the retrospective when I have more distance from this effort.

✔ In Production (2021)