Two distinct product platforms shaped through research-led design: a globally used scientist-facing subscription platform for external users and a payroll system built from the ground up for internal teams.
Designing for complexity at scale
⛔️ NDA Restrictions - Detailed information, visual assets, and product screens for these projects cannot be shared.
Skills:
• SaaS Product Design • Workflow Design • Information Architecture • Interaction Design • Competitive Analysis • Design Systems • Cross-functional Collaboration
Collabration:
- Product managers - Engineers - HR & Finance Stakeholders - CEO
Company:
AAK Tele-science, INC.
Duration:
May 2024 - May 2025
AAK Tele-Science, Inc. is a technology company building tools that help the global scientific community collaborate, publish research, and access funding, all in one place. At AAK Tele-Science, I worked on product experiences that supported both external users and internal teams. My work focused on simplifying complex workflows, improving usability, and designing scalable systems.
Project
1. Scientist Subscription Platform
2. Payroll Management System
Type
Customer Product
Internal Tool
Focus
SaaS monetization
Enterprise workflow
PROJECT 1Designing an End-to-End Subscription
Platform for Scientists
The team needed to introduce a subscription model to support advanced capabilities and long-term growth. The challenge was to design a subscription experience that clearly communicated value while remaining simple and trustworthy for researchers.
Problem
Conversion from free to paid was unclear: Scientists couldn't distinguish between tiers or justify the subscription ROI.
Feature tiers needed to be structured in a way that scientists could easily understand and compare.
International users faced currency confusion, unfamiliar payment flows, and low trust.
The goal was to design a clear, scalable subscription flow that communicated premium value,
simplified the path from free to paid, and gave scientists flexible control over their plans.
Research
Research was conducted through secondary methods — competitive analysis of subscription models in B2B SaaS and research tools, and behavioral insights from user feedback analysis and stakeholder discussions.
The platform serves researchers at different stages: academics, early-career researchers, and independent researchers. Each had different needs and different reasons to upgrade. Understanding that helped me define what each paid tier should include and who it was actually for, rather than grouping features arbitrarily.
Using affinity mapping and the Jobs-to-be-Done framework, I reframed features as outcomes, shifting focus from "what the feature does" to "what it helps the researcher accomplish."
Understanding Who Was Actually Subscribing
🔍
Researchers value clear and transparent pricing, vague tiers kill trust instantly.
🧪
Users want to explore before committing, the free tier needed to feel like a real starting point.
💡
The upgrade decision is outcome-driven, scientists ask "will this help my research?"
Design Approach
The challenge wasn't just reducing clicks, it was reducing the mental effort behind each one. I broke the experience into three focused areas.
Making It Simple, Step by Step
Simplifying Plan Comparison
I restructured the plan tiers with a clear hierarchy and benefit-first descriptions. Instead of listing every feature upfront, I used a dropdown to let users expand details on demand. This kept the page clean while still giving users the full picture if they needed it.
01
Reducing Checkout Friction
The upgrade flow was simplified into a short, guided checkout, minimal fields, clear confirmation, no dead ends. For international users, I added auto-detected location with local currency conversion and secure payment indicators so users felt confident before entering any details.
02
Subscription Management
Scientists work on grant cycles, their needs shift. The dashboard let users view their plan, upgrade anytime, and check billing history. Simple, flexible, and in their control.
03
Key Design Decision
The hardest call on this project was deciding how much information to show on the plan comparison page. The stakeholder's instinct was to show everything, every feature, every detail, all at once. That's a fair ask. Full transparency builds trust.
But when I looked at the layout with all that information expanded, it was a lot. Too much to scan. Too much to decide from. For a scientist who just wants to know "is this worth it?", a wall of features doesn't help, it stalls.
How Much to Information to Show
The question I kept coming back to: what does a user actually need to see right now, versus what can wait until they ask for it?
I landed on progressive disclosure, show the key benefits upfront, and let users expand the full feature list with a dropdown if they want to go deeper. It respected both the stakeholder's need for completeness and the user's need for clarity.
UX Challenge & Iteration
My first version of the plan comparison had everything visible by default. It felt thorough, but when I stepped back, it was overwhelming. There was too much competing for attention, and nothing clearly stood out as the reason to upgrade.
I took it back to stakeholders with a simple question: what's the one thing we want users to walk away understanding? That conversation shifted the direction. We agreed the priority was helping users see the value of upgrading, not listing every feature.
What changed in the iteration
Collapsed feature details by default — only key benefits shown upfront
Added a dropdown so users could explore the full list at their own pace
Reorganised the visual hierarchy so the upgrade value was immediately clear
Result: a cleaner layout that felt easier to navigate and less like a spec sheet
Outcome & Reflection
The final design gave the platform a clear, scalable subscription experience, one that communicated value without overwhelming users, and made the upgrade path feel like a natural next step rather than a sales push.
The design patterns built here were also reusable, structured in a way that could support future pricing changes or new feature tiers without starting from scratch.
What the Project Left Behind
What I took away
This project taught me that simplifying something complex isn't just a design problem — it's a communication problem. I had to learn how to explain my decisions clearly to stakeholders, especially when my instinct differed from theirs. Showing the "why" behind a choice — not just the "what" — is what made those conversations productive. And honestly, that skill has stuck with me more than anything else from this project.
PROJECT 2Designing an Internal Payroll Management Platform
Redesigned a fragmented payroll workflow into a centralized internal platform that simplified payroll processing and improved data visibility for HR and finance teams.
Problem
Payroll processing involved multiple disconnected tools and spreadsheets.
HR teams struggled to track employee data, deductions, and updates in one place.
Finance teams lacked clear visibility into payroll summaries and reports.
Managing payroll across multiple countries added another layer of complexity.
Research
Through stakeholder interviews and workflow mapping, it became clear that this platform needed to serve two very different types of users, and what they needed from it wasn't always the same.
HR Team
Need speed and accuracy. They're updating employee records, managing deductions, and processing payroll under tight monthly deadlines
Understanding Who I Was Designing For
Before jumping into solutions, I mapped the full payroll lifecycle, from employee onboarding to pay-slip generation. This helped identify critical friction points:
Updating a salary change required going through four different screens including HR data, payroll settings, tax details, and approval, with no clear progress or guidance.
Exited employees kept showing up in active payroll cycles weeks after leaving the company.
Finance had no way to know if payroll was still being processed or already disbursed without pinging the HR team.
Complex navigation between employee records and location-based payroll calculations led to hard-to-trace errors.
This showed the platform needed more than better forms, it needed clear payroll status, smarter employee states, and one unified workflow.
Design Decisions
Finance Team
Need visibility and confidence. They need to see payroll summaries, department breakdowns, and historical data
Three Things That Shaped the Platform
UX Challenge & Iteration
One Long Page Wasn't Working
My first version of the payroll processing flow put everything on a single scrollable page — all employee data, deductions, bonuses, and the approval action in one view. The thinking was that having everything visible would help users feel in control.
But Finance teams pushed back during feedback. Their concern was real: when everything is on one long page, it's easy to miss something. And in payroll, missing something means a mistake that's hard to undo.
I redesigned it into a structured four-step flow:
01
02
03
1
2
3
4
Role-Based Dashboard for HR & Finance
Since HR and Finance had different needs from the same platform, I designed role-based views, the dashboard automatically adapts based on who's logged in. HR teams land on a view focused on actions: payroll status, pending tasks, and upcoming cycles. Finance teams see a summary-first view: total payroll costs, department-level breakdowns, current status, and historical trends. Same platform, same data, but the right information surfaced for the right person from the moment they log in.
Structured Employee Profiles
Employee profiles were redesigned to keep everything in one place - personal details, salary structure, benefits, deductions, and payroll history. The goal was simple: an HR team member should be able to find, update, and confirm any employee detail without leaving the profile or switching to another system.
Review Employee Data
Confirm each employee's details are accurate before calculations begin
Validate Deductions & Bonuses
Review and confirm all adjustments — one focused step, less chance of anything slipping through
Step-by-Step Payroll Processing Flow
The payroll workflow was broken into four clear stages - review employee data, validate deductions and bonuses, approve payroll, then generate payslips and reports. Each stage had one job. This made it much harder to miss something important and gave teams a clear sense of progress through what had previously felt like one overwhelming task.
Review Payroll Summary
A full overview before any approval — totals, breakdowns, and flags for anything that looks off
Approve Payroll
Only reachable after all previous steps are verified — making approval a confident action, not a nervous one
Breaking it into stages gave users a clear mental model of where they were in the process, and made it much harder to accidentally skip something important.
Design System
Built to Grow With the Platform
Since this was a new internal platform that would keep evolving, I built a set of reusable components alongside the designs, including table patterns for employee data, form components for payroll updates, and status indicators for tracking progress through the payroll flow.
The goal was to ensure future features could be added without starting from scratch each time, with consistent patterns and less design debt.
Outcome & Reflection
The platform centralized what had been a fragmented, manual process into a single, guided workflow. HR teams gained a clear step by step process that reduced the risk of errors. Finance teams got visibility into payroll at every stage, not just at the end. Both teams also had a single source of truth for employee and payroll data.
From Scattered to Structured
What I took away
Designing for internal tools taught me something I had not fully appreciated before, the users are not just people using a product, they are people whose jobs depend on it working correctly. A mistake in a consumer app is annoying, but a mistake in payroll affects someone’s salary.
That raised the stakes for every design decision. It also taught me to really listen during feedback. When finance teams said the long page layout worried them, it was not just a preference, it was a signal about how they actually work and what they need to feel confident. Learning to hear that kind of feedback and act on it quickly is something I carry into every project now.