Project Overview and Role
Challenges
My Approach
Before and after comparisons
Outcome and reflection
Fydron
Compliance Operating System for Teams
Project Story:
End-to-end product design for a multi-tenant compliance management platform connecting advisory firms, their enterprise clients, and internal audit operations plus the accompanying public marketing site.
Project Information:
Project: 10Ants
Role: Lead Product Designer (sole designer on the project)
Scope: Full platform UX/UI — onboarding and authentication, the advisor workspace, dossier and requirement workflows, the audit review system, role-based access across three tiers, billing and mandates, client management, and the public marketing site
Collaborators: Product and engineering stakeholders
Methods: Requirements translation, systems and information architecture design, workflow mapping, UI design, design system definition
Status: Approved and currently in development. View website here.
Overview
Fydron positions itself as the operating system for compliance teams, a platform that lets advisory firms manage multiple clients' compliance dossiers (ISO 27001, ISO 45001, VCA, and others) from framework activation through formal audit and evidence export.
Three distinct audiences share the same underlying data, each with a fundamentally different relationship to it.
I was brought on as the sole product designer for the project, working from product requirements to design a system where all three tiers could work from the same source of truth without stepping on each other's permissions, workflows, or trust boundaries.
Project Information:
Project: 10Ants
Role: Lead Product Designer (sole designer on the project)
Scope: Full platform UX/UI — onboarding and authentication, the advisor workspace, dossier and requirement workflows, the audit review system, role-based access across three tiers, billing and mandates, client management, and the public marketing site
Collaborators: Product and engineering stakeholders
Methods: Requirements translation, systems and information architecture design, workflow mapping, UI design, design system definition
Status: Approved and currently in development.
View website here.
Overview
Fydron positions itself as the operating system for compliance teams, a platform that lets advisory firms manage multiple clients' compliance dossiers (ISO 27001, ISO 4500, VCA, and others) from framework activation through formal audit and evidence export.
Three distinct audiences share the same underlying data, each with a fundamentally different relationship to it.
I was brought on as the sole product designer for the project, working from product requirements to design a system where all three tiers could work from the same source of truth without stepping on each other's permissions, workflows, or trust boundaries.
Challenges
The brief was not to design a handful of screens. It was to make a genuinely multi-tenant, multi-role compliance system feel coherent from every seat at once.
The core challenges:
A layered data model. Clients, dossiers, frameworks, requirements, indicators, evidence, and assessments all needed to resolve correctly across three platform-level roles and five per-dossier roles (Admin, Auditor, Reviewer, Contributor, Uploader) — without the interface becoming a maze of permission edge cases.
A review lifecycle with real consequences. A dossier moves through preparation, submission for review, and a locked audit state. The interface needed to make the difference between an editable working record and an immutable audited one immediately legible, not just enforced in the background.
One task, three completely different tools. Exporting the same underlying evidence needed to look and behave differently depending on whether an Advisor, an Enterprise client, or an Auditor was the one requesting it — each with different needs for speed, control, and format.
Trust as a requirement from day one. Mandatory MFA, per-dossier roles, framework versioning, and a full audit trail weren't polish added at the end — they were structural requirements the interface had to carry from the very first screen.
No existing design system. Every pattern — status models, inspection drawers, bulk actions, locking states — had to be established from nothing and then held consistently across dozens of interconnected screens.
The Goal:
The ground-up design needed to produce a platform that was:
Legible to three audiences with very different stakes in the same data
Honest about the state of a piece of work at every stage: draft, in review, locked, audited
Trustworthy enough for a compliance-sensitive buyer to hand over sensitive client and financial data
Scalable across many clients, many frameworks, and many concurrent audits without the interface buckling under its own data
For advisors, this meant a portfolio view that scaled from one client to hundreds without losing clarity. For enterprise clients, it meant knowing exactly what was expected of them and by when. For auditors, it meant a workspace built around how an audit actually gets done: evidence next to criteria next to verdict.
My Approach
A secure, invite-based onboarding flow
Access to Fydron isn't self-serve sign-up — it's invitation-based, matching the reality of an enterprise compliance tool. I designed the account-activation sequence (password creation with an explicit 12-character policy, mandatory MFA enrolment via authenticator app, and profile completion) as the first trust signal a new user encounters, before they've seen a single piece of client data.
A Five-tier, per-dossier permission model
Given as a product requirement, I translated a genuinely complex access model into an interface people could actually reason about. Platform-level roles (Advisor, Enterprise Admin, Standard Client, External Auditor, and Tech Admin) sit above dossier-level roles (Admin, Auditor, Reviewer, Contributor, Uploader), so the same person can be an Uploader on one client's dossier and an Auditor on another's. I designed distinct, minimal navigation for each tier — the Auditor, for instance, sees only Dashboard, Turbo-View, and Export Center, rather than the Advisor's full portfolio-management shell — so each role's interface reflects only what that role needs to do.
The dossier and requirement workflow — the core loop
This is the product's spine: a framework loads into a dossier, requirements sit in a five-state lifecycle (Proof Needed, Awaiting Review, Reviewed, Approved, Not Approved), evidence gets attached at the requirement level, and a reviewer works through a detail drawer that pairs the requirement's criteria directly against the evidence and the verdict being recorded. I designed this drawer pattern — criteria, verdict, rationale, and evidence on one surface — as the reusable unit of inspection across the whole product, later reused for the Activity Timeline and per-requirement discussion threads.
The review lifecycle and locking mechanics
Also a defined product requirement: once a dossier is marked ready for review, it locks. I designed the interface to carry that state honestly through every surface it touches — a status banner explaining why the dossier is locked, disabled controls that don't just go dim but say what they're waiting on, and a narrower, audit-appropriate status vocabulary (Approved, To review, Failed) that replaces the five-state working model once a dossier enters formal review. Rejection during review requires a written reason before it can be submitted, so a "Failed" verdict is never delivered without an explanation attached.
Differentiated export experiences by audience
Given as a requirement, three distinct export flows needed to exist for three distinct users. I designed each to match how that user actually works: the Advisor gets a single-action ZIP scoped by client, year, and dossier; the Enterprise client gets a simpler, self-serve download with no client-addressing step, appropriate for a buyer managing their own compliance record directly; and the Auditor gets a granular export builder — selectable content (public chats, official assessments), a choice of Word or Excel output, and a preview of the generated document's structure before committing — appropriate for producing a formal, defensible deliverable.
Client and billing management
I designed the client lifecycle from creation (a two-step onboarding form capturing legal identity, billing details, and a primary contact) through to an ongoing client profile that separates legal data, account ownership, and payment/mandate status — the latter deliberately delegated to Stripe rather than handled natively, so the platform itself never needs to touch raw financial data directly.
Extending the system to a public marketing site
I also designed Fydron's public-facing marketing site, carrying the same product vocabulary — frameworks, dossiers, role-based workflows, mandate confirmation — into the messaging, positioning, and content strategy. The site's "one workflow for every role" section mirrors the platform's actual three-tier permission model directly, and its FAQ answers real product mechanics rather than generic SaaS copy.
Key Decisions
One person can hold different roles across different clients: Roles resolve per dossier, not per account, so the same login carries different permissions into different contexts — an Uploader on one client's dossier can be an Auditor on another's.
A locked audit state with no explanation reads as broken: Every lock pairs a status banner naming the phase with inline messaging explaining why a specific control is unavailable, rather than leaving a disabled button to speak for itself.
A single export button can't serve three very different users: Three purpose-built export flows exist, each scoped to how that audience actually works and what they're allowed to see — a scoped ZIP for the Advisor, a self-serve download for the Enterprise client, and a granular, format-flexible builder for the Auditor.
Auditors were switching between evidence, checklist, and verdict: A single three-pane workspace (Turbo-View) holds all three in view at once, navigable as a queue rather than a series of disconnected lookups.
A rejection with no explanation isn't defensible later: A written reason is required before a Failed verdict can be submitted, so no rejection reaches a client without justification attached.
Sensitive financial and identity data shouldn't sit natively in the platform: Payment mandates are delegated to Stripe, with the platform surfacing status rather than holding raw account data itself.
Outcome
Fydron is currently in development and has not yet launched. The work to date has produced a coherent, implementation-ready design across the full platform — onboarding, the three-tier permission model, the dossier and audit workflow, differentiated exports, billing and client management — alongside a marketing site built to carry the same product vocabulary to prospective customers.
Because the product has not yet shipped, product impact will be evaluated after release, using activation, review-completion, and audit-turnaround data once real advisors, clients, and auditors are working inside it.
What I learned
Designing Fydron reinforced that a permission model is a design problem long before it's an engineering one. The hardest work wasn't any single screen — it was making three audiences with genuinely different stakes in the same data all feel like the interface was built specifically for them, without fragmenting into three unrelated products.
It also sharpened how I think about locking and irreversibility in an interface. A disabled button is not a design decision on its own; it only becomes one once it explains itself. Every lock, every rejected verdict, and every disabled control in Fydron had to answer "why" in the same breath as "no."
Finally, working across the product and its marketing site side by side showed me how much a shared vocabulary matters. When the language a prospect reads on the homepage is the same language they'll see inside the product on day one, onboarding starts before the first login.
Closing statement
As the sole product designer on Fydron, I translated a set of demanding, requirements-driven constraints; a five-tier permission model, a locking audit lifecycle, and three distinct export experiences into a platform that reads clearly from every seat at the table: the advisor managing a portfolio, the enterprise client proving compliance, and the auditor rendering a verdict.