Aralia Education Technology
Aralink
Unifying contract signing and tuition payments into one seamless workflow
AraLink is an enterprise client management platform designed to consolidate contract signing and tuition processing into one continuous experience.
Leveraging integrations across Google AI Studio, Documenso, and Flywire APIs, the platform aims to automate manual handoffs, resolve data silos, and boost 300% operational efficiency.
Timeline
August 2025 - May 2026
Tools
Google AI Studio
Figma MCP, MS Clarity
Documenso API, Supabase
About
Aralia is a global EdTech company pairing students with seasoned U.S. educators for tailored tutoring and college prep. However, rapid expansion exposed a critical bottleneck: fragmented contract procedures, data silos, and overloaded communication channels. With a worldwide client base, Aralia's core business challenge is efficiently managing legal agreements while maintaining client trust.
The goal of this project was to architect AraLink - a centralized portal unifying contract signing and tuition payments - to reduce administrative overhead, ensure legal compliance, and seamlessly synchronize user data across platforms.
My Contribution
As founding UX designer and aspiring PM, I led the effort to replace Aralia’s fragmented workflow to a centralized portal:
Automated contract signing and tuition payment into one consistent flow.
Eliminated manual handoffs and data silos (via system design) across operations.
Sped up client onboarding efficiency and reduced drop-off.
Research
Discovery and Audits
Audits
To understand the gap between contract receipt and payment, I audited both the user journey and the underlying system architecture. My goal was to pinpoint where the existing tech stack and manual processes were failing the users. This discovery phase focused on two core tracks:
Workflow Auditing: Traced manual handoffs across sales reps, email threads, and external payment links to isolate friction points and system disconnects.
Sign-to-Pay Benchmarking: Evaluated onboarding patterns in modern SaaS platforms (like Stripe, Plaid, and DocuSign) to establish UX best practices for multi-step verification and cross-border payments.
Market Analysis
To establish a baseline for AraLink, I evaluated prevailing sign-to-pay platforms in the market. The goal was to identify which onboarding problems existing tools had already solved, allowing us to focus our system architecture on the unresolved friction points in cross-border payments.
Interviews & Shadowings
Quick 15-min follow-up: The task -> The words -> The frequency -> The failure -> The Screen
THE USERS
What do you check first when you open the tool, and how often do you check it?
What do you do right before and right after this step?
What do you do if the client exceed the deadline?
"Honestly, it's a huge hassle cross-checking all these different tools just to figure out if we can bill a client. Not to mention the time wasted chasing down paperwork."
THE STAKEHOLDERS
Who is allowed to see, edit or delete what?
Which documents must be retained as legal proof?
What are the key metric of current monthly/annually review?
"Some parents paid but forgot the signature step, which caused complaints down the line. And yes, it’s very common."
THE ENGINEER
What happens when the data is missing, late or wrong?
What is our single source of truth when systems fall out of sync?
How are we securing PII during transfer?
"... I don't know, um, if someone else has already taken care of that case or if it's just sitting there."
Understand
Define
To bridge the gap between business needs and client friction, I facilitated alignment sessions with key stakeholders across Leadership, Operations, and Tech:
Translating UX Friction into Business Impact: Presented the audit findings to illustrate how fragmented hand-offs directly correlated with drop-off rates and heavy operational follow-up burden.
Proposing the Unified Sign-to-Pay Architecture: Mapped out an integrated user flow showcasing how leveraging DocuSign and Wise APIs within a single session would streamline onboarding while adhering to legal compliance and cross-border payment requirements.
Problem
Aralia’s contract process runs across four disconnected tools, with admins acting as the only link between them. Because (1) signature status, (2) client records, (3) conversations and (4) payments live in separate places, admins can’t see where a contract stands, repeat manual work on every cycle, and can’t be sure an agreement is binding before money moves. On the client side, they sign in one product, pay in another, and chase answers elsewhere. This costs admins hours on every cycle, and it risks billing a client before an agreement is verified, which exposes Aralia to payment disputes and affects client trust.
Userflows and Sytem Mapping
To pinpoint bottlenecks, I translated research notes and business requirements (BRDs) into diagrams.
Because standard user flows only tell half the story, I chose swimlane diagrams to visualize these complex, asynchronous handoffs between admins, the third-party API, and our clients. This allowed the team to clearly see cross-role dependencies, identify potential API bottlenecks (as shown below), and plan for system edge cases before engineering began.
By separating what the system needs to do in the backend from what the user actually needs to do on the screen, we identified some opportunities for our new system.
Ideation
Ideate
Wireframing
Working within an Agile framework, I started with low-fidelity wireframes to secure the main user flows and preserve my original design intent. From there, I leveraged AI-generated tools to rapidly explore design variations and open up new structural opportunities without slowing down the process. This accelerated workflow resulted in 40+ prototype screens ready for stakeholder review and user testing. By the end of this phase, all system functionalities and UX architectures were fully established.
System Architecture
We're building this on three specialized tools: Supabase for the database, Documenso for e-signatures, and Flywire for payments.
In brief, the system has one place that stores contract data, a backend layer that acts as the traffic controller, and three outside tools that handle the heavy lifting: reading PDFs, storing files, and managing signatures. The backend's whole job is making sure those three tools talk to the database correctly, so a contract's data, its file, and its signature status never fall out of sync.
For more information, please refer to: Documenso API, Supabase Data REST API, Flywire Dev Portal
Prototyping
Rather than building static click-throughs, I used AI to accelerate a live staging environment for our MVP. This allowed us to immediately test and validate actual system behaviors and user interactions. AI gave AraLink a plausible starting point, but refining the prototype still required heavy human judgment. I had to ensure data-heavy flow made sense in real life and handled error states without friction. However, by using AI to build a stateful, interactive MVP rather than a static Figma file, we were able to test system behaviors early, completely changing the quality of our user validation.
Tools: Google AI Studio, Figma MCP
Structural Validation & User Flows
Prioritize intuitive user flows and content hierarchy to ensure the primary user goals could be met without friction.
Visual Hierarchy & Micro-interactions
Refine typography, spacing, and component states while integrating subtle micro-interactions to guide user attention
Criteria & Constraint Validation
Evaluate core interactions against BRD constraints and potential system failure.
Technical Feasibility & Accessibility
Address responsive scaling, optimized for system latency
Interations
Design Iterations 1 | Structuring Data & Hierarchy
What specific problem is this screen solving? If we could only ship one of these in MVP 1.0, which would it be, and why?
To manage complex records without overwhelming the user, I weighed cognitive load against engineering scope and chose progressive disclosure. Also, I chunked this complex data into logical thematic groups.
Current Trade-off: Users need a 2nd click to perform full-table bulk actions, but we can obtain a clean default view over data visibility to reduce cognitive load.
Advanced filtering (TBD)
Bulk actions (TBD)
Design Iterations 2 | Edge Cases
What does the zero-data/error state look like?
To protect our delivery velocity from unmanaged design debt, I focused on balancing automation with admin control across our Documenso and Flywire API integrations. If a third-party API fails silently, the UI is explicitly designed to give admins transparency, robust audit trails, and manual override capabilities.
Design Iterations 3 | Optimizing API & Rendering Performance
How might we prioritize checkout conversion over absolute data immediacy?
To handle the edge case of international clients on high-latency networks trying to load 20-page educator agreements, I plan to decouple the data fetching, loading the critical checkout data (Flywire) instantly while lazy-loading the heavy Documenso PDF payload in the background.
Current Trade-off: Users must explicitly click a button to view the rendered contract, keeping the initial page load quickly.
Design Iterations 4 | What's next?
Accessibility Ensure focus order, keyboard navigation, and aria-labels into the spec tokens.
Audit tech constraints API latency, and edge cases handled with fellow engineer.
Deliverables
Deliver and Test
Installing Google Analytics and Mix Panels
As we rolled out our first MVP last week for Aralia's Sign-to-Pay Portal, this testing framework focuses on validating our core toolstack and tracking performance metrics to ensure operational success.
Core Metrics & Success Benchmarks
Completion Rate: Target >95%. Eliminates client drop-off by avoiding external signing links.
Manual Data Handoffs: Target 0. Automates data transfer between contract execution and billing status.
Contract-to-Payment Latency: Target 24–48 hours. Accelerates time-to-decision from signature capture to payment readiness.
Admin Overhead: Measures total reduction in manual reconciliation and document-chasing hours.
Retrospective
Key Takeaways
Afterthoughts on Testing My AI-Integrated Workflow
Research → Define → AI Exploration ↔ Prototype / AI Build → Testing → Ship
Using AI on AraLink didn't replace my need for critical UX thinking. Honestly, I found it to be a really handy tool for getting a big-picture view of the development process.That said, it definitely doesn't replace engineering expertise or make devs obsolete but rather endorse our communication between design and development.
What Worked Well
Rapid Iteration with UX Intent: AI generated four layout variations for the customer lookup page. Instead of picking one at random, I evaluated them against real user needs + technical feasibility, tossed out three due to weak information hierarchy, and refined the one that actually fit the core user flow.
Testing Real Logic with Figma Make: Instead of just clicking through static prototypes, I had a chance to test against live-coded data flows using Figma AI. To some extent, this helped catch edge cases early, like a subtle contract status bug and a broken permission check, that would’ve stayed hidden in traditional Figma frames (and would have taken me more time to find out).
What I’m Continuing to Work On
"Prompting Techniques" as User Stories: To prevent AI from generating generic UI patterns, I learned to treat prompt engineering like writing technical user stories. Crafting precise specs through a Product Manager lens yields significantly better code and UI output.
Navigating the "Black Box" & Continuous Learning: Working with AI requires active oversight to prevent unaccountable logic gaps. I tried to keep up with evolving frameworks by a blog post a day (Check out the lastest thread Product Manager Roadmap from Acy Doan, which helps me ground these toolsets in my structured product strategy)