CAREER JOURNEY · JAN 2022 – PRESENT · ACYLOGIX GROUP (ACY SECURITIES / ZEROLOGIX)

Four Years at ACY
The chapters behind the case studies

The project pages on this site show what shipped. They don't show the four years of judgment calls, staffing changes, regulatory deadlines, and slow-burning lessons that produced the work. This page is that context.

I joined ACY Securities (an Australian-regulated retail CFD / FX broker — ACY Securities Pty Ltd, AFSL 403863 — one of several operating entities under the ACYLogix Group, which also owns Zerologix Pty Ltd and its Taiwan / APAC subsidiaries) in January 2022 as one of four designers. I'm still there. Over four years and four months, the team shrank, rebuilt, shrank again, and is rebuilding now. The product ecosystem grew from a fragmented five-platform estate into a single design system serving 100,000+ traders across 40+ regulated jurisdictions. This is the story I can tell without breaching anything confidential — the rest lives in the case studies.

Technical terms ahead. Trading, broking, and regulation have their own vocabulary. Where a term would slow a non-specialist reader, I've added a short parenthetical explanation the first time it appears — so you can read this end-to-end without a glossary.

Navigate this page

Why I'm Writing This

Four years is either coasting or compounding. I want you to see which one this was.

A four-year engagement at one company, in this industry, reads two ways to a recruiter. Either you're comfortable and the role stopped teaching you, or the work kept growing and you kept growing with it. I can't prove which one I am in a résumé bullet. I can only walk you through the actual chapters and let you judge.

The short version: I was hired as a mid-level product designer on a four-person team. Within the first year, the other three designers left for larger companies. I stayed — not out of loyalty, but because the problem in front of me kept getting more interesting. Regulatory deadlines I'd never seen before. A product estate (five separate platforms) held together by tape. A design system that didn't exist yet. Executives who started asking me to design things I'd never designed — investor decks, financial data visualisations, fundraising materials.

The long version is below. Where I got something right, I've said what I got right. Where I got something wrong, I've said that too — because a case study that only shows the wins is a pitch, not a record.

Something Easy to Miss

The logos you see on the org chart — most of them are mine.

When people look at the ACYLogix Group organisation chart, they see the structure: parent company, subsidiaries, 100% ownership lines. What they don't see is that roughly 90% of the marks on that chart — ACY Group, ACY Securities, ACY Capital, ACY Wealth, ACY Advisory, ACY Connect, Zerologix, Zerologix Taiwan, Logixel, and ACYLogix itself — are logos I designed over these four years.

Brand identity work wasn't in the original job description. It happened because the group kept forming new entities — a new jurisdiction licence here, a new B2B product line there, a new technology subsidiary — and each one needed a mark that fit inside the family without looking derivative. After the first two, leadership stopped briefing external agencies and started briefing me directly. That's how a product designer quietly ended up owning the visual identity of an eight-entity financial services group.

Why this matters to a hiring manager

A product designer who can also hold the line on corporate identity is rare in fintech. It meant the design system, the product UIs, and the brand marks all evolved from a single visual sensibility — no "the brand team says one thing, the product team says another" drift. For a firm where the brand is the product (institutional finance, where trust is the core asset), this isn't a nice-to-have; it's the reason the whole ecosystem reads as one company instead of eight.

Chapter 1 · Q2 2022

The first regulatory deadline nearly broke the company. It's what built the design system.

Five months into the role, ASIC (the Australian financial regulator — the local equivalent of the SEC in the US or the FCA in the UK) issued a Product Intervention Order: every Australian broker had to implement new leverage restrictions across every product surface within 14 days.

Leverage, for anyone outside the industry: it's the ratio of position size to the cash a trader actually puts down. A broker offering 500:1 leverage lets a $1,000 deposit control a $500,000 position — which is how retail traders lose their savings in a morning. ASIC had decided the industry's leverage caps were too permissive, and they gave us two weeks to change everything that displayed or enforced those caps.

At that point we had five platforms — a marketing site, a trading terminal, an institutional-facing CRM (a tool that broker staff use to manage client accounts), a market-analysis product, and a social-trading product — each with its own UI, its own codebase, its own way of showing leverage. Forty-plus screens needed changing. Each platform was maintained by a different engineering pod. Nothing was shared.

The Decision the Team Made

The tactical brief was "add a warning modal and a leverage cap validator." Leadership reframed it: what if we used this deadline to build the foundation we should have built a year ago? Ten extra days of work now, but the next regulatory update doesn't take 14 days — it takes three.

That strategic call came from above me. My job was to translate it into something designable in 14 days: what should the shared architecture look like, how should compliance logic be encoded, and which screens ship on day 14.

What I did in those two weeks

I audited twelve touchpoints across the five platforms and mapped every inconsistency. Then I proposed a single compliance primitive — one Leverage Indicator component, one Risk Warning component — that every platform would render. The regulation wouldn't live inside a specific screen anymore. It would live inside one component, and every screen would inherit it.

This sounds obvious in hindsight. In the moment, it was an argument I had to win with six different stakeholders in 48 hours: engineering was worried about migration cost, legal wanted a one-off fix they could sign off on quickly, product was worried about a two-week roadmap slip, and the CEO wanted to know why we were spending extra time when ASIC just wanted the warnings up.

The argument that landed with the CEO wasn't a UX argument. It was a risk-adjusted ROI argument: ten extra days now buys roughly five years of compliance stability. Every future regulatory update — ESMA, FCA, FINRA — would drop into this architecture instead of triggering another cross-platform rebuild.

What Shipped

We made the deadline. Twelve days, not fourteen. Zero design-related regulatory violations in the two-plus years since. Eight subsequent regulatory updates — ASIC leverage caps, ESMA inducement bans (EU rules against broker incentives that influence retail behaviour), FCA risk warning updates — each slotted in through the compliance primitives in three to five days, not three to four weeks.

What I learned from Chapter 1

Two things, and they've shaped how I work ever since.

First, regulatory requirements are design specifications, not legal hurdles. The instinct of most teams is to treat compliance as a gate at the end of the process — get the design done, show it to legal, wait for markup, revise. That model breaks under a 14-day deadline. The only way to ship was to treat ASIC's rules as design inputs from day one, the same way typography rules or grid constraints are inputs. Once compliance is a design input, the question stops being "can we ship this?" and becomes "what's the most elegant way to encode the rule?"

Second, bring legal in on day one, not day four. My first ASIC deadline, I brought legal in on day four of the 14-day window. We burnt two days debating warning placement that I could have avoided by showing them wireframes on day one. I've never made that mistake since. I now run a weekly design-legal sync wherever I work, and compliance-related revision rounds on my projects dropped from three or four per feature to one.

Chapter 2 · Mid-2022 through 2024

The team left. I was 30 years old and running design at a 150-person broker.

Over the course of 2022, the other three designers I'd been hired alongside moved on. One went to a bigger consumer-fintech company, one to a Tier 1 bank, one to a Silicon Valley SaaS firm. All three were good moves for them — I've stayed in touch with all of them, and I take their moves as a quiet signal that the work here trains people up.

I didn't become head of design by design. I became it because there was no one else left. And the work didn't get smaller; it got bigger. By late 2022, I was the single point of failure for design across five production platforms, with three engineering teams implementing in parallel, in two timezones (Sydney design, Taipei engineering, with a three-hour overlap window).

What changed in how I worked

When you're the only designer for five products, you can't be a designer who does screens. You have to be a designer who does systems. I shifted almost all of my time into:

  • Component governance. I ran a monthly audit of the Figma library — which components were being used, which were decaying, which were being misused by engineers. I rewrote the component documentation from "how to implement" to "when to use and when not to use," because the misuse rate dropped from around 30% to under 8% once the docs focused on intent rather than code.
  • Handoff infrastructure. With a three-hour overlap window between Sydney and Taipei, I couldn't rely on real-time conversations. Every Figma spec got dual-language annotations (English design rationale, Mandarin implementation notes), and engineering misreads — the moments when something shipped wrong because the intent wasn't clear — dropped from roughly weekly to roughly monthly.
  • Self-service enablement. When I did hire designers again (three of them, at different points over these years), I needed them to ramp to their first independent contribution in two weeks, not two months. That forced me to document the system the way I'd document an API — with examples, constraints, and failure modes, not just pretty Figma files.

The design I got wrong

In 2022, I redesigned Finlogix — our market-analysis product — on the assumption that traders were overwhelmed by data density and would benefit from a cleaner, more minimal layout. I removed secondary panels, simplified the chart toolbar, reduced the default data columns. It looked much better by every visual-design metric I knew.

Usability sessions (n=8, active traders with six-plus months on the platform) told a different story. Users felt less confident in the new version, not more. The panels I'd removed weren't clutter — they were peripheral vision. Experienced traders scan them continuously without consciously reading them. Taking them away didn't reduce cognitive load; it increased it, because now users had to actively seek information they used to absorb passively.

The kicker: my "task completion time" metric went down in the redesign. Users finished tasks faster. But task confidence — "how certain are you about this trade?" — dropped 31%. A faster, less confident trading decision is a worse outcome, not a better one. I'd picked the wrong proxy metric and let it confirm a wrong hypothesis.

The redesign was pulled. We rebuilt the improvement case around a different question: not "how do we show less?" but "how do we make the existing density faster to parse?" That reframe is what eventually produced the 40% analysis-time reduction in the Finlogix we shipped. The lesson I've carried into every financial product since: density isn't the problem; unstructured density is.

Chapter 3 · 2024

Mid-2024 the team was cut again. The scope wasn't.

In the middle of 2024, the design team was reduced to me. Five product lines, retail and institutional, with live compliance obligations across forty-plus jurisdictions. Concurrent deliverables that quarter included the consumer mobile app (iOS and Android, already live with a 5.0★ App Store rating), institutional API documentation (for hedge funds connecting via the FIX protocol — a standardised messaging format that most institutional trading systems speak), multilingual campaign pages (Arabic, English, Vietnamese), rebate-and-ambassador pages, and compliance updates across all five platforms.

The honest reaction most designers would have is: ask for more headcount. I did ask — and headcount wasn't available in that window. So the constraint became a workflow-architecture problem instead of a staffing problem.

How I restructured the workflow

I leaned heavily on AI as a generation-and-iteration layer, while keeping every judgment call human. The division of labour that emerged, and still holds today:

What stays with me

  • Regulatory context — what ASIC/FCA/ESMA actually require, and how it applies to this specific screen
  • Business intent — what outcome this product is supposed to produce for the company
  • Design constraints — the system boundaries, the hierarchy, the patterns that already exist
  • The judgment filter — validating every output against the reality of the market and the user

What AI accelerates

  • Generation — first drafts of copy, layout variations, component options
  • Structuring — turning raw notes into organised specs and documentation
  • Iteration speed — testing five variations of an approach in the time one used to take
  • Pattern work — catching inconsistencies across large files I can't hold in my head at once

The key principle, which I repeat to anyone asking about my process: domain judgment stays human. I decide what to build and why. AI helps with how fast I can explore and iterate. If I let AI make judgment calls in a regulated financial product, a user gets hurt. If I refuse to use AI at all, I don't ship on time. Neither is acceptable, so the workflow has to be structured around that division clearly.

The same approach is demonstrated interactively in the AI Direction tab of this portfolio — it's not theory, it's how I actually work.

What the solo year taught me that the team years didn't

Two things.

First, a design system's value is most visible when there's nobody else to lean on. When you're the only designer, every hour spent hand-crafting a component that should have been systematised is an hour the product doesn't get. The components I'd built in 2022–2023 — the compliance primitives, the modular widget system, the typography scale — paid back hundreds of hours in 2024 that I simply didn't have otherwise. I designed the system for a team; it saved the product when the team wasn't there.

Second, the constraint changes what "good" looks like. In a team, good design is thorough design. In a solo year with five platforms, good design is triaged design — the deliberate, documented decision that a flow is "good enough for now, revisit in Q2." I got better at writing down why I hadn't done something, so that future-me (or a future hire) wouldn't waste time rediscovering the same trade-off.

Chapter 4 · Oct 2024 – Present

The work now is part design, part capital markets. I didn't see that coming.

Starting in late 2024, the CEO began assigning me work I didn't expect: investor presentations, SPAC materials (documents used when a private company goes public through a merger with a Special Purpose Acquisition Company), financial data visualisations for the CFO, regulatory communications for the CRO (Chief Risk Officer). There was no product manager layer for this work. The CEO would send me the brief directly. The CFO would annotate the Figma files for same-day sign-off.

I didn't have a background in capital markets materials. I did have a background in making complex information legible, which turned out to be the same skill applied to a different audience. The discipline of "information hierarchy, audience awareness, progressive disclosure" doesn't care whether the audience is a first-time trader or an institutional investor — the mechanics are the same; the vocabulary changes.

Work from this chapter

  • CEO investor deck. The draft led with growth (200% YoY) but treated the regulatory-compliance track as a footnote. I argued for structuring the narrative as "growth plus governance" — how we scaled compliance alongside user acquisition, not despite it. That reframe made it into the final pitch and is the structure the company now uses for its investor story.
  • CFO financial projections. FY27–FY28 projection tables were organised as a single consolidated view. I restructured them to separate "core platform revenue" from "expansion-market revenue," making the risk/reward trade-offs immediately scannable to an investor audience. The CFO adopted the format for subsequent investor communications and asked me for enough Figma training to edit the files himself.
  • CRO regulatory communications. I suggested visualising our eight-regulatory-update track record as a "compliance maturity curve" rather than eight isolated incidents — reframing the same underlying evidence as a systematic capability rather than reactive firefighting.

Specifics of these deliverables are NDA-protected; detail available in interview.

What this chapter is teaching me

Senior design isn't just about the interface anymore — it's about being the person in the room who can translate between audiences. A trader, a CEO, a CFO, an auditor, an institutional investor all want the same underlying truth, but they each need it presented in their own vocabulary and at their own level of abstraction. Four years ago I could only speak "trader." Now I can move between these audiences, and the same design discipline — hierarchy, clarity, honest framing — travels with me.

Currently

As of April 2026, I'm still at ACY. The design team is rebuilding — one designer hired, a second being interviewed. Current work spans the mobile app's next major release, ongoing compliance maintenance across all five platforms, and the investor-communications track with leadership. Project-level detail is in the ACY case study; this page is the surrounding narrative.

What Four Years Taught Me

Six beliefs I didn't hold when I arrived.

01 · Compliance

Regulatory rules are design specifications, not legal paperwork.

The designers who treat compliance as a gate at the end of the process ship late and argue with legal. The designers who treat it as a design input from day one ship on time and have legal as an ally. In regulated finance, compliance UX is UX.

02 · Density

Density is not the problem. Unstructured density is the problem.

A trader's screen is dense by necessity, not by accident. The job isn't to remove information; the job is to make the existing information faster to parse. I learned this the hard way by pulling a redesign in 2022 (Chapter 2) and I've never forgotten it.

03 · Metrics

Task completion time is the wrong proxy for trading products.

A faster but less confident trading decision is a worse outcome. I now ask "how certain are you about this?" alongside completion time, and treat a confidence drop as a failure even if the speed number improved.

04 · Briefs

A brief is a hypothesis, not a specification.

In 2022 I was briefed to redesign the Finlogix homepage. Three days in the data told me the drop-off wasn't on the homepage — it was three screens deep, in the analysis workflow. I pushed back with evidence, the PM changed the brief, and the work that followed is what actually moved the metric. The brief is the starting question, not the answer.

05 · Teams

Design systems are what save you when the team isn't there.

I built the ACY system for a team of four. It saved the product when I was a team of one. A good design system is load-bearing infrastructure, not decoration.

06 · Audience

The discipline travels; the vocabulary changes.

Designing a compliance flow for a first-time trader and designing a pitch deck for an institutional investor are — underneath — the same problem. Both audiences want the truth, clearly presented, at their level of abstraction. Learning to move between these audiences is what moved me from "product designer" to "senior" in my own head, long before the title caught up.

The Five Platforms

Each of these has its own case study.

This page is the personal narrative. The project pages are where the design work lives — problem framing, artefacts, outcomes, trade-offs. If a specific platform is what you're here for, the five case studies are below.

Flagship Case Study

ACY Securities →

The parent case study: design-system architecture across the full ecosystem. 150+ components, 5 platforms, 8+ regulatory updates absorbed without structural rework. This is the overview everything else branches from.

Market Analysis Terminal

Finlogix →

Real-time market data terminal. Density redesign, modular widget system, 40% analysis-time reduction in production telemetry. The product where I learned the "unstructured density" lesson the hard way.

Broker CRM

LogixPanel →

Internal tool for compliance officers. Forty-jurisdiction audit preparation that used to take two weeks, reworked to take hours. The CRM that taught me to design for the person doing the unglamorous work.

Proprietary Trading Terminal

LogixTrader →

The web trading terminal retail traders use daily. A white-label (infrastructure borrowed from a third party, branded as ours) architecture decision that got us to market in eight months instead of two years.

Social / Gamification

ACYverse →

The gamification research project. Where I mapped the line between "educational" engagement mechanics and "inducement" mechanics that would trigger ASIC scrutiny. Includes a live compliance simulator.

Institutional B2B

ACY Connect →

The institutional side of the business: FIX-protocol API platform and documentation for hedge funds and prop desks. The work that taught me to design for developers reading specs at 2am, not just traders clicking screens.

Reading order suggestion. If you're short on time, read the ACY parent case study first. If you're evaluating a specific capability — retail UX, institutional infrastructure, compliance design, consumer mobile — the platform that fits is probably the one linked above.

Why I'm still here

Four years is a long time in tech, and the question a recruiter is probably asking by now is: why haven't you left? The honest answer has three parts.

The problem kept getting more interesting. I joined as a mid-level designer on a fragmented product. I'm leaving — whenever I leave — having shipped a compliance design system that absorbs regulatory updates the way a shock absorber absorbs a bump. That's not a project I could have moved into from outside.

The work widened in ways I didn't expect. A designer who's only shipped consumer apps is a consumer designer. A designer who's shipped retail, institutional, mobile, API docs, and investor materials in four years is a different kind of professional — one who's had to reason about the same underlying trade-offs from very different seats.

And the industry is specific. Regulated retail finance is a small world with a long memory. The reputations I've built with regulators, with compliance officers, with institutional counterparties — those aren't portable résumé bullets. They're context I now bring to everything I design.

What comes next, I'm open about: the problems I want to work on are institutional-grade portfolio risk, execution infrastructure, and compliance-first design at firms where these problems are the core of the business. If that's your firm, the case studies tell you what I can do; this page tells you why I'd take it seriously.