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