2020 • boundless.com

Every green card application has potentially dozens of issues buried in its hundreds of pages of content.

And our team used to handle all of them by emailing back and forth with our thousands of customers. You can imagine what their inboxes started to look like.

01. Setting the Stage

01. Setting the Stage

As the product design lead, I worked with ops and engineering to devise a new system from scratch.

As a test case for our MVP, we only implemented it in one piece of our process: the Quality Assurance (QA) stage. The plan is now to extend it to at least 3 other phases. Here's how the tools work:

02. The Admin Tool

02. The Admin Tool

Part 1: An admin tool MVP for creating and managing issues

The first tool in a new system

This project coincided with a push to build a new admin system from scratch to house all of our various ops tools, so we had no previous UI to build off of. Visually, it's clean but barebones–a gestural sketch that's flexible enough for us to continue adding to and moving our old admin tools over.

Providing structure to issues

When an ops member used to create an issue, that meant writing free-form text into an email; no structure to the process at all. In our MVP, ops folks create discrete issues that can have communications and status attached to them.

The secret sauce: the fly-out thread panel

To track the context of an issue all in the same place, we needed messages on an issue to be threaded. I designed the thread as a scrollable fly-out panel to avoid needing to retrofit it into every other tool.

03. The Customer Tool

03. The Customer Tool

Part 2: A simple customer UI

Reusing the thread model

Although I explored other ways of displaying a thread to customers, we found that the fly-out model worked well enough for the MVP and cut down on development time. Customers get a main list of issues, each with a thread attached to them.

Building off of an existing layout

Other parts of our info gathering experience use a similar 3-column layout – a great starting point for building a quick new info-gathing tool. This is an example of it being used in a pre-pay eligibility checking flow.

Batching communications

We couldn't send a customer's answers back to the ops team piecemeal as they answered them (imagine getting bits and pieces of answers over the course of a few days), so we based it on a batching system where everything is sent back to us when it's finished.

04. Project Results

04. Project Results

A smashing success

After about two months of collecting data post-release, I was excited to see some concrete quantitative proof that our tool had helped. Our primary metric for success was how long it took to get the customer through the whole QA process. Here's some fun stats from a pool of 485 customers:

Before & after the product release

2x lift in same-week completions

25% of customers finished in the same week their QA started, compared to 12.8% previously.

50.1% of all customers finished after 1 week

Compared to 29.7% of customers before – a 1.7x lift.

30% reduction in customers taking 4 weeks or longer

Only 9.6% of customers took 4 weeks or longer, compared to 39% before.

CS team delight

It wasn't a high bar to clear from the previous email-driven experience – but the CS team loves their new tool.

05. Details to Come

05. Details to Come

Thanks for reading so far – I'm working on adding more details to this project.

Consider this a case study MVP. I'll add more detailed designs and the process once I get the chance.