Role: Client-Facing Enterprise Designer | Duration: 7 months | Status: Shipped | Employer: Altimetrik | Client: Envision
Six user types shared one financial platform, but each needed a different kind of certainty. I designed account registration and tax info around clearer choices, visible changes, and a review before moving on, then carried that thinking across the wider platform.
MY ROLE
I DESIGNED
ACROSS THE PLATFORM
TEAM OWNED
THE PROBLEM
Same platform, six very different questions
Investors, advisors, customer-contact representatives, supervisors, administrators, and compliance teams all touched the same platform, but their questions and measures of success didn't overlap. An investor asking “can I complete my request?” has nothing in common with compliance asking “who did what, when, and under what authorization?”
"Users weren't short on data — they were short on certainty about which account they were in, what a status color meant, or who owned a task."
01 · GUIDED TAX EDITS
From desktop tax fields to a guided edit
The legacy PowerAgent screen put tax fields, notes, and save actions into one dense, tabbed desktop workspace. I replaced it with a guided wizard that shows the current values first and the editable fields right below, with a two-step header and a running count of changes. The decision behind it was to separate what is on file from what is being edited. It mattered because a tax change should be something a user can see and confirm before it saves. I personally owned the tax info work, and it shipped to production.
02 · EDIT THEN CHECK
Pick it. Edit it. Check it.
SELECT SECTIONS TO EDIT
Editing starts with a choice. Instead of dropping users into one long form, the wizard first asks which sections they want to change. Each part of the registration has a checkbox, and here Tax Information is selected. The footer shows how many sections are selected, with Cancel and Continue in a fixed place. The decision was to scope the edit up front so the next screens only show what the user picked. It mattered because MAR holds many sections and most edits touch only one.
EDIT WITHHOLDING DETAILS
Step two shows only the section that was selected. Current Data sits at the top, read-only, with a control to hide it. The editable fields below let users change the withholding information. A two-step header shows where the user is, and the footer counts edits as they happen. The decision was to keep what is on file next to what is being changed, so users never lose their reference point while editing.
REVIEW BEFORE CONTINUING
The final screen brings Current Data and New Data side by side. The new values carry a Modified tag, and the header marks the edit step done and the confirm step active. Continue moves the flow forward, and Back stays available. The decision was to give users a clear comparison before they move on. It mattered because these are edits to a client's registration data, where an accidental change should be easy to catch.
03 · FIVE DESIGN DECISIONS
Knowing where to look first was the problem
Registration details, holdings, tax information, and workflow state competed for attention. Five decisions shaped the experience: keep the account visible, make actions distinct, separate current values from edits, give status a consistent meaning, and make completion clear.
04 · ACCOUNT IN VIEW
Account context, without the guessing
I kept the active account, contribution information, and next action in one view. The idea was to let representatives see which account they were working in and what they could do next, without piecing that context together across screens.
05 · VERIFIED TWICE
Verified twice, posted once
Some financial updates can't rely on one person entering information correctly. In the dual-entry workflow, an agent creates a record and a second reviewer independently re-enters it without seeing the original values. The system compares both: matches post, while mismatches go to a supervisor with context. Separation of duties is built into the workflow rather than left as a manual process layered on top.
06 · CONTEXT ON CALL
A new representative, not a new conversation
The handoff needed to carry the conversation forward, not just transfer the call. IVA passes the caller's intent and verification status to the representative, so the context is there when they take over. The incoming-call view shows who is calling, whether verification is unfinished, and the choice to accept or return the call to the queue.
Once the call is live, Copilot keeps a running timeline and connects the investor's request to a next action, like pulling up their IRA contribution limits. Context was kept beside the conversation so the representative could use it without losing their place. Copilot suggests; the representative decides.
07 · FIND, REVIEW, SEND
From "where's that doc?" to sent
Representatives needed to find approved documents, check whether they applied to a specific client, and respond without leaving their workflow. I brought search, contextual filters, secure preview, and a Quick Answer Email with prefilled client details into one flow. The decision was to keep finding, reviewing, and sending together, so representatives could check the document before it reached the client.
OUTCOME
What went live
The platform shipped to production, including Maintain Account Registration, tax info, the investor dashboard, dual-entry review, contact-center IVA/Copilot, and knowledge search. The work connected investor, advisor, contact-center, and compliance workflows through a shared model of account context, roles, permissions, and status.
I owned MAR, onboarding, registration, and tax info design end to end, covering 100+ screens. Across the wider platform, the same questions guided the work: which account am I in, what changed, and what happens next? Those questions became part of the shipped experience, from reviewing a tax edit to handing a call to a representative with its context intact.
REFLECTION
What this changed about my design philosophy
Before this project, I believed enterprise products became difficult because they held too much information. The real problem was rarely the amount of information. It was whether people could tell what deserved their attention first, what they were allowed to do, and whether the system would preserve evidence of what happened. That shift changed how I approach enterprise design: start by designing confidence, context, status, permissions, and recovery, before designing the interface around it.