Rocket: Internal Tool & Conversation Designs
TL;DR: 12-week Project Overview
Project 1
Internal Tool: Reducing administrative burden and times spent on check requests
Rocket's current check request process is through an external site – it was burdensome, overloaded with spreadsheets, layers of approvals, and manual verification.
As a design intern for the enterprise team, I reimagined an internal tool for the check request process, projected to be open to all 18,000+ Rocket employees.
Before
After
Project 2
Structurize Sample Conversation Flows for Rocket’s Chat experiences
Designing conversational flows manually takes about 7 days for a design cycle, and teams must interpret dense PRD documentation, extract logic, and manually map out conversation branches.
I helped design a custom flow in Rocket's internal chatbot tool that automates the generation of sample conversation flows. Mainly, I worked on the conversational flow logics – including mapping of the happy paths, edge cases, error conditions, and digressions.
Final Demo by Julius Patto, using my conversational paths
Sample flow chart I created
prompt-testing in Rocket's own internal AI chatbot
Deep Dive PRoject 1: Rocket Pay
Invisibility in bulk processing
The legacy site was never designed for Rocket's bulk processing scale or structure. So employees compensated with shadow processes: Excel templates, emailing them to accounting, and manually tracking status outside the product — in side spreadsheets and informal check-ins. In the payments context, that kind of invisibility is a risk when totals, error states, or ownership weren’t obvious.
Bulk processing wasn’t an edge case. Batches commonly ran 20–50 items per day, and could spike dramatically. Partial actions also created a risk multiplier. If a bulk is partially denied and a user resubmits incorrectly (or resubmits the whole file), duplicates happen.
Rather than Approval Flexibility, Prevent errors and make decisions safe.
Because I started with known users and existing business requests, I was able to narrow the research scope early. I began with screenshots of the old site, then moved into multiple rounds of discovery interviews with requesters, accounting staff, and Team Leader approvers.
I mapped the Team Member → Team Leader → Accounting chain, defining what each role needed to see, act on, and pass forward.
IA of the current and future state, with questions on sticky notes to confirm with stakeholders
Bulk Request Flow Iterations
My research informed me that, the main concern wasn't how to build a more flexible approval flow. It was how to prevent errors and duplicate payments while keeping bulk decisions understandable and safe. That helped reframe shaped the entire MVP direction.
Solutions
I iterated across multiple rounds, each shaped by feedback from end-users, delivery managers, and senior designer reviews.
Structured bulk upload to replace the Excel email handoff
Submission routes automatically into the approval chain
One unified workflow with 3 role-aware views
Required denial reasons with notifications so requesters knew exactly what to fix.
Visible batch context at every stage
Count, amount, validity, and status are surfaced at the batch level so users can confidently approve or deny without leaving the product to verify in a spreadsheet.
The same event reads differently depending on where a user sit in the workflow – A Team Leader's denial is a success action; but an Accounting denial is informational context.
Experience outside of the Platform
Beyond in‑app notifications, I treated email touchpoints as part of the out-of-product experience. In a cross‑team workflow, email is often where accountability and next steps actually land—so I aimed to make messages actionable (who needs to act, what changed, and what to do next) rather than generic alerts.
Email Flow, Questions on Sticky Notes to align with stakeholders
Key Tradeoffs
All-or-nothing over partial approval
Partial approval sounded user-friendly but testing showed it multiplied duplicate payment risk. I advocated for the simpler model – maximum clarity at the moment of decision, not maximum flexibility.
Deferred send-back to post-MVP
A "send back for revision" pattern was highly requested but introduced state complexity that couldn't be safely scoped for MVP. I documented it with constraints for a future iteration.
Mobile Responsiveness
I chose to sacrifice some table readability on mobile, since mobile usage is secondary, and we have limited time.
Happy to chat about the full case study – reach out to me at [yzhang4176@gatech.edu].