Automating ASIC Compliance Through Self-Serve Investor Profiles
Information Architecture
Logic Mapping
UX Auditing
Workshop Facilitation
product
Boulevard Global
INDUSTRY
Fintech B2B
TIMELINE
Aug 2022 – Feb 2023
ABOUT
Boulevard Global (now Liquidise) is a regulated share registry, the official record of who owns what in a private company, helping private companies manage equity and ASIC compliance. As the sole designer, I led the redesign of a broken, static profile system into a logic-driven self-service experience.
CHALLENGE
Every profile update required manual intervention. The CEO and Head of Product were editing production data directly and hand-filing ASIC forms for routine changes. On a team of 6, this wasn't sustainable.
IMPACT
For the first time, investors could manage their own profile data without contacting the team. Daily support requests almost completely disappeared, and roughly 10 hours of founding team time went back to building the product every week.
TEAM
CEO Head of Product Product Manager 2 Engineers Product Designer (me)
My Role
UX/UI Design Logic Mapping Workshop Facilitation QA & Handoff
Before Redesign
After Redesign
Context
Look but don’t touch
Eight to ten update requests a day, every one ending with a founder editing a live financial database by hand.
Boulevard was built read-only by design, to protect the integrity of legal records for its two user groups: Investors and Company Administrators. That made sense on paper. In practice, as the user base grew, every data change, however minor, had to be handled internally, and the backlog kept growing.
What is ASIC Form 484? It's the form Australian companies use to tell the corporate regulator (ASIC) about changes to who's connected to the company, officeholders, shareholders, and share structure. If a shareholder's name or address changes, the company has 28 days to file one, or risk a late fee. It's a real legal requirement, not paperwork for its own sake, which is why every routine profile update carried actual regulatory weight.
This case study covers the investor profile card scoped to the Owner and Contact sections first, since that's where 100% of support requests originated. We were scaling the user base and scaling a mountain of administrative debt at the same time.
My job was to untangle the logic and design a system that gave users real control while keeping the platform compliant and the data clean.
UX Audit
It looked like a missing edit button. It was a data ownership problem.
Profiles were never just individual or company. Six ownership structures were buried in flat, unlabelled data.
Before designing anything, I needed to understand why these profiles were so complex. On the surface it looked like a simple edit problem. But the deeper I looked, the more I found hidden logic that the existing UI had never accounted for.
There were joint owners, beneficiary structures, trust arrangements, and edge cases that varied depending on ownership type. None of this was visible or structured in the current interface, it was all buried in flat, unlabelled data blocks.
Auditing the Existing UI
I mapped my findings against Nielsen's heuristics. Three things stood out immediately.
Audited against Nielsen's heuristics: no labels, no hierarchy, no editability signals.
No Labels or Hierarchy
Every piece of investor data sat in a single flat block, owner details, contact info, and compliance data all at the same level, hard to find anything quickly.
Visual inconsistency
Everything else on the platform used a card-based layout. The investor profile didn't, making the screen feel unfinished before a user even tried to interact with it.
No Editability Signals
No edit button, no hover states, no affordance of any kind. In a platform handling real financial data, that's not just a usability problem, it's a trust problem.
Defining the Six Profile Types
I ran a workshop with the Head of Product and PM to map out every investor profile type the platform needed to support. For each type we identified what data was required, what was missing from the current design, how ownership structure affected the fields shown, and which fields carried compliance implications. This gave us a shared foundation before a single wireframe was drawn.
Six investor types mapped in a workshop with the Head of Product and PM.
Mapping the Full Field Logic
With the profile types defined, I worked with the PM and Head of Product to map every field across all six types in detail. For each field we documented whether it was required for the first release, whether the user could edit it, and how it mapped to ASIC requirements. Some fields, like TFN (an investor's Tax File Number), still needed a call on whether they belonged in the first release at all.
This wasn't just a design exercise. It became the single source of truth that engineering, product, and compliance could all work from.
Every field across all six types: required, editable, and how it maps to ASIC.
Iterations
What the first wireframe could not do
I put an early wireframe in front of the team specifically to find what it could not handle.
A flat card consistent with the rest of the platform: investor name, type, address, email, phone. Deliberately minimal, and put up to be broken.
Before committing to the full system, I presented an early wireframe to the team to pressure-test the direction. The layout was simple: a flat card consistent with the rest of the platform, showing the investor name, type, address, email, and phone number. Clean and deliberately minimal.
The first wireframe. Clean, consistent with the platform, and not scalable to six profile types.
The team responded positively to the direction, but the session surfaced three things the first version had not accounted for:
Multiple contacts were needed. Investors often needed more than one contact to manage their holdings.
Contacts needed to be invited directly from the card, rather than going elsewhere in the product.
The first investment date and beneficial status were missing entirely from the display view.
I observed that this layout was also not scalable to accommodate all 6 profile types. Each type would require a different layout. We needed a layout that would scale across all profile types with as few components as possible.
I incorporated all three pieces of feedback into the next version. The single contact row became a multi-contact table with an Add contact action and a Send Invitation link per row. I expanded the Owner section to include First invested date and Beneficial status.
The revised version: a multi-contact table, invitations per row, and the missing Owner fields.
Stakeholders signed off with one final addition: TFN to be included as an editable field for future feature compatibility. It was intentionally descoped from the first release as it was optional and not required for ASIC compliance at launch. The modular table structure meant adding it later would require no redesign.
That feedback loop, from first wireframe to stakeholder response to revised design, compressed what could have been weeks of back and forth into two focused sessions. It also gave the engineering team confidence that the designs they received had already been stress-tested by the people who knew the compliance requirements best.
Design
One component, six investor types
Rather than six layouts for six profile types, I built one that could become any of them.
With the profile logic mapped and the field rules defined, I had everything I needed to redesign the experience from the ground up. The goal wasn't just to add an edit button, it was to build a system that could handle six distinct investor types, enforce the right rules for each one, and make the whole thing feel simple to the person using it.
Individual, joint, and company profiles all needed different amounts of owner data. Some holdings are owned directly, and some are held on someone else's behalf, in a trust or a Self-Managed Super Fund (SMSF), a retirement account an investor runs themselves. Those non-beneficial profiles, where the person named isn't the one who actually benefits from the shares, required an additional Beneficiary section showing the trust or SMSF name and ABN. Beneficial profiles did not.
I used tables for the Owner and Contact sections instead.
One row for an individual owner, two for a joint investor. Same component.
Company profiles reuse the structure, with ACN/ARBN added, Australia's company and registered body ID numbers.
Beneficiary visibility tied to Beneficial status, appending ATF to the investor name automatically.
The Beneficiary section visibility was tied directly to the Beneficial status field. When Beneficial is set to No the section appears, and the investor name is automatically appended with "ATF" (short for "as trustee for," the legal way of naming someone holding shares on another party's behalf) followed by the beneficiary name, reflecting the legal trust structure.
One component covering all six types, so a single fix applies everywhere.
Solving for Financial Jargon
During internal walkthroughs, terms like 'Beneficial Status' were stopping users in their tracks. Rather than simplify the language and risk losing legal accuracy, I introduced the platform's first tooltip component, so users could get an on-demand definition without leaving the flow, addressing a real risk of abandonment in a context where confused users had no option but to call support.
The platform's first tooltip component, added so legal accuracy did not have to be simplified away.
Role-Based Editing
The edit form had to handle a fundamental tension: investors needed enough control to update their own data without creating compliance risk, while admins needed full access to fields investors should never touch directly.
Field-level permissions: read-only for investors, editable for admins.
I solved this through field-level role permissions. Fields tied to legal ownership status appear read-only for investors, with a tooltip explaining why, and become editable when an admin opens the same form, one design serving two roles without becoming two designs.
The same form serving two roles without becoming two designs.
The same edit form served two different users without needing two separate designs. The structure communicated access levels without the system needing to explain them in words.
Handoff
Compliance logic breaks silently, so the handoff had to be exact
If engineering misread the logic for even one profile type, compliance would fail silently until a Form 484 went out wrong.
Closing the Loop with Engineering
I ran a dedicated review session with the engineering team before a single line of code was written. We walked through the logic together, clarified ambiguous states, and caught several edge cases that would have caused validation errors in production. That session saved us at least a week of back-and-forth during QA.
Organising the Handoff
I structured the Figma files by ownership type across rows and flow type across columns. This meant engineers could go directly to the exact screen they needed without reverse-engineering the logic from a sea of screens. Every state, every edge case, and every field variation was accounted for and easy to find.
Figma organised by ownership type across rows and flow type across columns.
Writing the Tickets
I worked with the PM to write Jira tickets for each investor type and user state. Rather than leaving interpretation to the developer, each ticket included the field rules, visibility logic, and expected behaviour for every variation. This significantly reduced the number of clarification requests during the build.
Jira tickets carrying field rules and visibility logic, not just screens.
Testing
Every type, every role, before anything went live
Role-based rules and compliance logic give you a lot of ways to break quietly.
I partnered with the PM and Head of Product to run internal QA before anything went live. Six investor types, two roles, and dozens of field-level rules meant testing from memory wasn't an option, so we built a test matrix covering every combination and worked through it systematically over a few days.
What We Tested
We worked through every investor type end to end against that matrix: right fields for the right roles, correct form validation, editable fields saving accurately. We also stress-tested the edge cases from the audit, joint ownership, beneficiary rules, trust arrangements, to make sure the logic held everywhere.
Outcome
The CEO stopped editing the database
Investors could finally edit the fields that were theirs to edit, and the founding team got out of the database.
The system launched successfully across the full platform after internal QA validation. Here is what changed.
1
Support Tickets Disappeared
Based on the support team's own assessment, profile-related tickets almost completely disappeared after launch.
2
Two Hours a Day, Back
Profile admin was consuming roughly 2 hours of the team's time every day before launch. That time went back to building the product.
3
Risk Eliminated
The CEO, Head of Product, and PM stopped editing production records directly. The risk of a senior team member corrupting live financial data was gone.
4
Compliance, Automatically
Name and address changes that once needed manual regulatory filings are now handled by the system. Compliance became a byproduct of normal use, not an extra step.
5
Every Filing, Correct
Every Form 484 the system filed after launch was filed correctly, the outcome that matters most for a compliance feature, and the one nobody notices when it works.
Reflection
Looking back
The interface was the small part. Six investor types and their field rules were the work.
What I’d do differently
The assurance was manual, and it should not have been. We worked through every investor type and role by hand, caught several issues before launch, and the filings the system produced afterwards were correct. It held. But it held because people were careful, not because the system checked itself, and a manual pass only ever finds what you thought to look for.
On a system where a wrong field quietly becomes a wrong regulatory filing, I would push for automated validation on the compliance rules themselves, so the logic is checked on every change rather than once before launch. That's not hypothetical: months later, while fixing an unrelated minor bug, a regression let Investor Type, a field meant to be admin-only, become editable by investors. A user reported it and we fixed it immediately, before anyone had changed it, but it's exactly the kind of thing a manual pass only catches after the fact. Designing the rules and then testing them by eye is the weakest part of what we built.
The strategy at that stage was ship first and fix later, and for a company that size and that runway it was the right call. It is why I would argue the exception rather than the rule. Compliance logic is the one place where fixing later means someone external finds it before you do.