Case Study
01
Back to Work
Case Study 01
Digital
payments platform
A mobile digital payments concept designed around trust, verification, and progressive access to financial features.
FintechMobile UXKYC FlowsWallet DesignPayments Journey
Scroll for the story
By the numbers
3
Progressive access states orchestrated (pre-KYC, partial, full)
5+
Core mobile journey flows shipped end-to-end
100%
KYC-integrated onboarding, with compliance visible on every screen
The challenge
Financial products have to earn trust before they ask for compliance. Most get it backwards.
The real design challenge wasn't the flows or the screens. It was the sequencing. When users hit a locked feature with no explanation, the app stops feeling like a product and starts feeling like a wall. Every dead end is a trust deficit.
The Frame
The shift
Instead of treating compliance as a hidden technical layer, something to get past, I made access states a visible, legible part of the journey. So the product feels honest and predictable from the first screen, not just after verification.
Progressive unlock. Users earn access by clearing trust milestones, not by filling forms upfront.
Compliance isn't a barrier, it's the journey, designed.
A
The Frame
Scope of work
Regulated flows feel blocking
Compliance as a hidden layer
Access state confusion
Fintech user flows
KYC UX patterns
Competitive audit
Access state architecture
Progressive unlock system
Guided restriction pattern
Onboarding & KYC screens
Wallet & payments UI
Utility & support flows
Mobile UI kit
Figma prototype
Interaction specs
The Frame
3 calls I made
01
State before screens
I mapped three user states (pre-KYC, partial KYC, and fully approved) before designing a single screen. The alternative was to build features first and add access gates later. That approach creates an interface full of unexplained dead ends. State-first meant every restriction was designed in, not bolted on.
02
KYC as a trust journey, not a gate
Instead of treating verification as a checkpoint to get past, I designed it as a product moment. The in-review state tells users what they can still do, what's coming next, and that the app is working with them. No disappearing into a black hole after submission. Compliance becomes part of the story, not the end of it.
03
Every restriction earns its presence
Any feature the user can't access has to explain why, show the path forward, and signal when it changes. The tradeoff was more states to design and more conditional specs to write. The payoff was an app that feels honest rather than hostile, one where restrictions are understood, not just encountered.
Key Decisions
Key design moves
Payments Home
The home surfaces wallet balance, quick actions, and utility payments in a single glance.
Video KYC
Identity verification runs as a guided live video call, framed as a product moment rather than a gate.
My Wallet
Balance, quick actions, and a clear transaction history with completed and queued states.
Wallet Limits & KYC Status
Once KYC is complete, transfer limits and beneficiary rules are shown explicitly, not hidden.
Payment Methods
Saved cards and a clear verify prompt keep everyday payments quick and trustworthy.
01
Compliance Without Bureaucracy
Designing a regulated payments experience that still feels useful and approachable.
02
Inclusion Before Approval
Making pre-verification users feel part of the product rather than excluded from it.
03
Consistent Product Logic
Connecting onboarding, KYC, wallet, and payments inside one understandable system.
Takeaway
What this project shows
Compliance and onboarding don't have to feel like a wall. Making access states a first-class surface turned regulation into a guided journey, not a gate, so pre-KYC users feel included instead of locked out.
←
All Projects
Back to Case Studies
Next Project
Studio Project Operations System
→
Case Study
02
Back to Work
Case Study 02
Studio project
operations system
A workflow-driven project and shoot management system for photography studios, built inside a broader studio business platform.
Workflow DesignDashboard UXService Business ToolsProject PlanningOperations Design
Scroll for the story
By the numbers
100%
Studio adoption across the launched cohort
100+
Active studios using the platform
30%
Monthly active users post-launch
The challenge
Studios stitch together spreadsheets, calendars, and trackers, because no product was built around how they actually work.
A wedding studio managing 20 clients doesn't have a project problem. They have a coordination problem. Multiple events, multiple photographers, multiple payment milestones, all moving in parallel, all connected. Generic project tools model tasks. Studios model relationships.
The Frame
The shift
Instead of adapting a generic project management model to studio work, I treated the product as a studio-specific operating system, one that mirrors how photography work actually unfolds, from booking intake through final delivery.
Workflow-first. Every screen connects to the next real step a studio actually takes.
Studios run on shoots, not tasks. The whole system follows that grain.
A
The Frame
Scope of work
Generic tools don't fit studios
Multi-event project complexity
Payments disconnected from work
Studio workflow mapping
Photography business patterns
SaaS workflow audit
Workflow-first project creation
Connected shoot management
Integrated payment tracking
4-step project creation flow
Shoots management view
Projects dashboard
Desktop web system
Figma prototype
Workflow specifications
The Frame
3 calls I made
01
A guided flow, not a form
The new project experience is a 4-step guided journey (define details, set up shoots, plan deliverables, track payments) rather than a single flat form. This matches how studios actually think about a booking: first what, then when, then what's produced, then what's owed. Breaking it into steps makes a complex setup feel like a conversation.
02
Shoots as first-class objects
I treated shoot events as distinct entities with their own crew assignments, status, and context, not just items on a project checklist. That decision unlocks operational visibility: filter by overdue shoots, see unassigned crew, track each event independently. When shoots have their own identity, managing them stops being memory work.
03
Payments inside the project, not beside it
Client payment milestones live inside the project view, not in a separate finance module. I considered keeping finances separate, it's cleaner in isolation. But a studio managing 20 projects can't afford the context switch. Keeping payments adjacent to the work they're tied to means one less place to check and one fewer thing to forget.
Key Decisions
Key product decisions
Projects Dashboard
A single operations view rolls up shoots, client payments, and deliverables across every active project.
Guided Project Setup
Project creation starts with client, package, and wedding details in a guided multi-step flow.
Deliverables Planning
Deliverables are planned with quantity, due dates, and cost, with suggested items to speed setup.
Shoots Management
Every shoot event is tracked with schedule, crew assignment, and status on one board.
Shoot Event Detail
An event drawer captures crew, categories, and notes for each individual shoot.
01
Real Studio Fit
Designing a system that matches the actual workflow of a photography studio.
02
Planning and Execution
Connecting project creation directly with staffing, scheduling, and delivery.
03
Financial Visibility
Surfacing payment and delivery progress alongside production progress.
Takeaway
What this project shows
Studios don't have a project problem, they have a coordination problem. Treating shoots as first-class objects and embedding payment milestones inside the project view collapsed five tools into one operational surface, adopted by 100+ studios.
←
Previous Project
Digital Payments Platform
Next Project
Decentralized Interchain Platform
→
Case Study
03
Back to Work
Case Study 03
Decentralized
interchain platform
A decentralized interchain dashboard concept designed to make governance, staking, portfolio visibility, and transfers more structured and usable.
Web3 Product DesignDashboard UXGovernance FlowsDesign SystemCross-chain Experience
Scroll for the story
By the numbers
35%
Lift in task completion across governance flows
25%
Reduction in staking flow abandonment
4
Modules unified under one navigation rail
The challenge
Web3 asks users to switch tools just to understand what they hold. That's not a content problem, it's a structure problem.
The crypto-native assumption is that users already understand the protocol. Most don't. The result is interfaces that are technically accurate but experientially exhausting, lots of information, almost no guidance. Governance participation especially suffers: raw on-chain data with no context for why it matters.
The Frame
The shift
Instead of building around protocol capability and expecting users to navigate around it, I designed around user intent, what are you trying to do, what context do you need, and how do you act with confidence in a domain where trust is earned slowly.
A participation platform, not a wallet. Governance, staking, and visibility on one surface.
Make the interchain bits feel like product, not protocol.
A
The Frame
Scope of work
Fragmented Web3 tools
Protocol complexity for users
Governance hard to participate in
Web3 UX patterns
Governance workflow analysis
Interchain product landscape
Unified participation platform
4-module dashboard system
Structured design language
Dashboard & overview
Governance voting flows
Staking & transfer UI
High-fidelity screens
Component system
Interaction documentation
The Frame
3 calls I made
01
Four workflows, one navigation
Governance, staking, transfers, and portfolio overview all live in one persistent navigation rail instead of separate disconnected tools. A narrower product might have done one thing better. But interchain users don't have one job, they monitor, participate, and move assets. One nav keeps context intact across all of them.
02
Structure first, visual language second
I spent the first design phase on layout logic and information architecture before committing to any visual direction. The dark, high-contrast purple system came after the product structure was resolved. In Web3, trust and clarity are both weak by default. The visual direction had to reinforce both, not just signal premium.
03
Governance as readable decisions
Proposal screens were designed to give users enough context to vote with actual understanding: full description, voting distribution, and an integrated voting interface. The alternative, surfacing raw on-chain data, would have been accurate for protocol experts. But accurate and usable are different things. I designed for the person who needs to vote, not just the one who already knows how.
Key Decisions
Key structural decisions
Portfolio Dashboard
Holdings, staked balances, rewards, and value sit in one interchain overview before any action.
Token Swap
Cross-chain swaps expose network, pricing, and slippage without hiding the mechanics.
Staking
Delegations, unbonding, rewards, and validator selection live in one staking surface. Long page · scroll inside the frame to view.
Governance Proposals
Active proposals are browsable with status, deadlines, and a summary preview.
Proposal Detail & Voting
A proposal detail brings timeline, current tally, and voting into one decision view.
01
Structure Over Fragmentation
Holding portfolio visibility, governance, staking, and transfers inside one coherent system.
02
Readable Governance
Designing participation as a decision-oriented experience instead of a lightweight add-on.
03
System Maturity
Evolving from wireframes into a stronger visual and reusable interface layer.
Takeaway
What this project shows
Web3 interfaces fail when they ask users to assemble context themselves. A unified four-module navigation, structure-first IA, and decision-oriented governance flows cut staking abandonment by 25% and lifted task completion by 35%.
←
Previous Project
Studio Project Operations System
Next Project
Data Governance Platform
→
Case Study
04
Back to Work
Case Study 04
Data
governance platform
A multi-module enterprise platform for managing datasets, policies, access permissions, audit trails, and compliance workflows.
Enterprise SaaSGovernance UXAccess ControlPolicy DesignAdmin Systems
Scroll for the story
By the numbers
6
Governance modules unified (catalog, datasets, policies, access, audit, simulation)
4
Distinct user role types orchestrated
1
Policy simulation layer added, impact-preview before activation
The challenge
When governance can't show how its pieces connect, teams stop trusting the system and start building workarounds.
Enterprise governance tools are usually assembled department by department. Policies live in one system. Access lives in another. Audit is somewhere else entirely. The result is governance as overhead, something you do after the real work, not something that enables it.
The Frame
The shift
Instead of building isolated modules for each governance function, I designed the platform around the relationships between them, so that a policy decision connects visibly to the datasets it affects, the users it governs, and the audit trail that proves it worked.
Decisions before data. Every module helps teams make calls, not just store records.
Governance is a layer of trust, design the trust, not just the table.
A
The Frame
Scope of work
Governance tools are fragmented
Policy decisions are opaque
Audit has no product home
Enterprise governance patterns
Admin workflow analysis
AI integration models
Catalog-first architecture
Policy simulation layer
AI-assisted drafting
Dashboard & module views
Policy creation & preview
Access & audit flows
Enterprise UI system
Figma prototype
Flow documentation
The Frame
3 calls I made
01
Catalog as the foundation
I started with the data catalog layer because if teams can't understand what data exists and how it's organized, every downstream decision (policies, access, audit) becomes abstract. Catalog-first meant every other module had something concrete to anchor to. Governance about nothing in particular is just documentation.
02
Policy simulation before activation
Instead of making policy changes irreversible or opaque, I designed a simulation and impact-preview flow. Teams can see which subjects, actions, and resources a policy affects before going live. The tradeoff was added product complexity. The payoff was a governance workflow that doesn't require perfect confidence upfront, test, revise, then activate.
03
AI for drafting, not deciding
I positioned AI inside specific high-complexity tasks, policy creation in plain language, catalog setup, schema conflict handling, not as a general assistant. The design question was where AI reduces genuine cognitive load versus where it adds noise. In enterprise governance, the answer is drafting and discovery, not decision-making. AI helps you start. The team decides.
Key Decisions
Key product decisions
AI Governance Assistant
An AI entry point routes catalogue, policy, dataset, and access tasks from one prompt.
Compliance Dashboard
A governance health view surfaces coverage scores, risk heatmaps, incidents, and the access backlog. Long page · scroll inside the frame to view.
Add New Catalogue
A guided wizard connects sources like Snowflake, Databricks, and Purview with a live config preview.
Create Policy With AI
Policies are drafted in natural language, then previewed as structured rules before activation.
Policy Simulation & Testing
Before a policy goes live, a node-based canvas maps its impact across data groups and returns a compliance score — so you test the consequences, then activate with confidence.
Audit & Compliance Monitoring
Real-time audit logs track access requests, severity, and violations across the platform.
01
Cross-Module Clarity
Making relationships between datasets, policies, users, and audit trails easier to understand.
02
Admin Decision Support
Designing interfaces that support both routine management and high-stakes governance choices.
03
Useful AI Integration
Integrating AI into enterprise workflows in a practical, non-gimmicky way.
Takeaway
What this project shows
Governance breaks when policies, access, and audit live in separate tools. Anchoring the system to the catalog and adding policy simulation gave compliance teams a place to make calls, not just store records.
←
Previous Project
Decentralized Interchain Platform
Next Project
Ground Operations Intelligence Platform
→
Case Study
05
Back to Work
Case Study 05
Ground operations
intelligence platform
A two-part dashboard system for airport ground support operations, combining live monitoring with fleet health and operational analytics.
Operations IntelligenceDashboard DesignMap MonitoringFleet AnalyticsOperational UX
Scroll for the story
By the numbers
2
Dashboards from one platform, live monitoring + analytics
5+
Operational zones with configurable geofence rules
3
Insight categories, incident response, utilization, optimization
The challenge
Operations teams don't lack data. They have the wrong data at the wrong moment.
Airport ground support runs under tight time pressure. One delayed response cascades into a missed departure. But the tools built for real-time response and the tools built for operational planning have always been separate, because they were designed for different people, at different moments, with completely different needs.
The Frame
The shift
Instead of forcing both needs into one overloaded dashboard, I separated the two jobs, a monitoring dashboard for live situational awareness, and an operations dashboard for longer-term fleet intelligence, while keeping both inside one connected platform.
Different decision horizons need different interfaces, same system, different surfaces.
Two surfaces, not one. Real-time stays real-time. Planning gets room to think.
A
The Frame
Scope of work
Real-time and planning in one tool
Alert stream with no context
No link from insight to action
Airport ops context
Fleet management patterns
Control-room interface research
Dual-dashboard architecture
Map-based monitoring layer
Predictive analytics module
Monitoring dashboard
Operations analytics view
Alert & zone management
Desktop dashboards
Figma prototype
System documentation
The Frame
3 calls I made
01
Map-based monitoring, not a data table
The live monitoring dashboard uses a spatial map as its foundation, not rows or abstract metrics. Airport assets have location, and that location affects urgency, response routing, and zone assignment. Seeing an asset in spatial context is a fundamentally different and faster decision than reading its status in a table. The map is the interface, not just a widget inside it.
02
Zones as alert logic, not decoration
Geofences and operational zones (terminal ops, cargo, fuel, emergency services) aren't just visual overlays on the map. I used them to structure the alert model: an incident in a fuel zone carries different urgency than one in passenger services. Without spatial context, the alert stream is just noise. With it, teams can triage by location, not just by timestamp.
03
Operations dashboard that recommends, not just reports
The analytics layer was deliberately designed to suggest interventions, predictive maintenance schedules, smart redeployment, AI-driven allocation, rather than stop at diagnosis. Most reporting tools tell you what went wrong. In airport operations, knowing something is broken is only useful if you know what to do about it next. The dashboard closes that gap.
Key Decisions
Key product decisions
Live Monitoring
A live satellite map tracks fleet position, alerts, and geofences for real-time ground awareness.
Geofence Drawing
Operators draw custom geofence zones directly on the airport map to scope alerts and rules.
On-Map Asset Detail
Selecting an asset surfaces its live status and diagnostics without leaving the map.
Fleet Health Insights
Fleet health analytics reveal breakdown frequency, utilization, and optimization guidance. Long page · scroll inside the frame to view.
Operations Dashboard
An AI-assisted operations view rolls up KPIs and fleet-wide health for longer-term planning. Long page · scroll inside the frame to view.
01
Real-Time and Strategic Views
Supporting immediate response and longer-term planning in one product ecosystem.
02
Actionable Maps
Making map-based interfaces useful for prioritization rather than visual overload.
03
Decision Support
Connecting asset-level monitoring with network-level patterns and recommendations.
Takeaway
What this project shows
Real-time response and long-term planning need different tools. Splitting the product into a live monitoring map and an analytics dashboard let the same ops team triage incidents in seconds and optimize fleets over weeks, without either job compromising the other.
←
Previous Project
Data Governance Platform
Next Project
Third-Party Risk Intelligence Platform
→
Case Study
06
Back to Work
Case Study 06
Third-party
risk intelligence platform
A dual-surface AI-agent platform for continuous third-party risk management. A Manager-facing TPRM platform and an Analyst-facing Risk Portal, designed for audit-ready evidence and continuous vendor oversight.
AI Agent UXEnterprise SaaSRisk & ComplianceDual-Persona DesignTrust UX
Scroll for the story
By the numbers
2
Distinct portals designed, TPRM Manager + Risk Analyst
6
Vendor lifecycle states orchestrated, invitation through onboarded
5
AI trust signals built in, confidence, citation, sources, reasoning, repopulate
The challenge
60% of breaches start with third parties, yet vendor risk is still tracked through once-a-year spreadsheets.
Risk and compliance teams need continuous oversight, not annual paperwork. And in a regulated product, AI output isn't useful unless it's defensible. The real design challenge wasn't building dashboards. It was making continuous AI agent analysis trustable enough to stand up to a regulator.
The Frame
The shift
Instead of treating vendor risk as paperwork to refile annually, I designed the product around continuous AI-agent oversight, surfacing risk shifts as they happen, with every score, citation, and recommendation traceable to its source document.
Trustable AI by construction. Every agent output ships with confidence scores, citations, and visible sources, auditable, not a black box.
AI carries the load, the user keeps the judgment. That's where the trust sits.
A
The Frame
Scope of work
Annual assessments lag reality
AI output hard to trust
Two roles, one tool tension
Stakeholder interviews
TPRM workflow audit
AI compliance UX patterns
Dual-persona surfaces
AI trust framework
Lifecycle as IA
Manager TPRM platform
Risk Analyst portal
VCM Agent surfaces
High-fidelity system
Component library
Stakeholder reviews
The Frame
3 calls I made
01
Two surfaces, one product DNA
A TPRM Manager owns vendor lifecycle; a Risk Analyst does the deep evidence work. Forcing both into one interface would have produced a tool that did neither well. I split them into a Manager-facing TPRM Platform and an Analyst-facing Risk Portal, with a shared design language and data model so context never breaks across roles. The harder call was where to draw the line: Vendor Continuous Monitoring lives in both, but the surfaces around it are tuned to who's looking.
02
AI output that earns audit trust
In a compliance product, the question isn't "is the AI right?" It's "can I defend this to a regulator?" I designed the VCM Agent surfaces around three trust signals: a confidence score, inline citations linking to the exact source document, page, and paragraph, and a visible Source Documents list. A Repopulate control keeps the analyst the final approver, not a passive consumer. A black-box summary would have failed the use case the first time a regulator asked "where did this come from?"
03
Onboarding as a visible state machine
Vendor onboarding has six discrete states: Invitation, Third Party Response, DD Initiated, DD Review, DD Approved, Onboarded. I made that timeline a first-class surface on every vendor page, not a status field tucked into a detail row. The tradeoff was screen real estate; the payoff was that the manager never has to ask "what's blocking this vendor?" The answer is always visible.
Key Decisions
Key design moves
Selected Screens · Manager Platform
Conversational Entry
The Manager portal opens with a TPRM Assistant: recent vendors, quick actions, a chat-first launchpad. A bold call for a compliance product, where most defaults are table-first.
Vendor Lifecycle At A Glance
Risk score, service type, and lifecycle status in one row. Pill filters at the top count each state so the manager can triage where the queue is bottlenecked.
Onboarding As A Visible State
The six-stage timeline lives on every vendor detail page. Status, time elapsed, time remaining, and next action are surfaced together, not buried in fields.
Profile As Source Of Truth
When a vendor reaches DD Approved, the profile unifies preliminary questionnaire, profile data, due diligence, and IRQ into one continuous reviewable surface. Long page · scroll inside the frame to view.
Selected Screens · Risk Analyst Portal
Continuous Monitoring Dashboard
The analyst's home: every vendor with CER ID, review status, risk level, and how many test scripts are pending. This is the work queue.
Test Scripts At Vendor Level
Drilling into one vendor exposes the test scripts the analyst needs to evaluate. AI-suggested insights, confidence, and disposition all live on the same row.
AI Output With Citations
Every VCM Agent analysis pairs a confidence score with the exact source: document, page, paragraph. The citation panel makes reasoning audit-ready.
Source Documents In Frame
The same analysis with the Supportive Documents rail open. Analysts can verify, download, or request re-upload without leaving the review.
01
AI Where Trust Is Non-Negotiable
Designing AI surfaces in a regulated product where every output has to be defensible.
02
Two Personas, One Product
Resolving the tension between executive-leaning workflows and deep analyst work.
03
State-Driven Architecture
Making lifecycle states the primary IA so risk shifts are never hidden.
Takeaway
What this project shows
AI in a regulated product is only useful if its output is defensible. The dual-portal split, confidence-plus-citation pattern, and visible source documents made VCM Agent analysis audit-ready, not just accurate.
←
Previous Project
Ground Operations Intelligence Platform
Back to First Project
Digital Payments Platform
→
