Punsara WijetungaCV
← Back to work
FintechTradingWeb + MobileEnterprise

Stock Brokerage Platform

One of the oldest and most established licensed stock brokerages in Sri Lanka relied, like every brokerage in the country, on a single provider with a near-monopoly on trading and back-office software. Despite a large monthly maintenance fee, the platform had seen little investment in years: a Windows-only desktop install downloadable through one specific browser, one device logged in at a time, slow and cluttered Windows XP-era screens, a steep learning curve, and no way to open a CDS account from the mobile app. The brokerage chose to back a new platform that would cut costs, respond to its needs, and give the industry a credible competitor.

Role
Lead Product Designer: requirements, end-to-end design, and financial-domain translation for the development team
Project type
Client Project
Timeline
December 2025 to present
Outcome
Estimated 10–15% workflow efficiency gain so far; mobile CDS account opening approved by the CSE
Four products together: the back-office account position inquiry, admin panel global parameters, the OMS buy order window and the mobile app's market overview
10–15%Estimated workflow efficiency gain so far
4Connected products designed end to end
13Configurable role types across the platform

01 — Discovery

Learning a regulated industry well enough to question it

Nobody on the team, including me, had a finance background; my own academic training is in food science. So the first real challenge wasn't design: it was learning the domain well enough to question it, and becoming the bridge between the client's financial and regulatory knowledge and the development team.

I interviewed admins, advisors and back-office operators to surface pain points, then sat with advisors and back-office teams to watch how they actually worked rather than relying only on what they said. For a period I had direct access to the client's back-office system, which let me learn its workflows first-hand, until that access was withdrawn under compliance rules. To understand the investor side, I opened a CDS account myself. And because unclear requirements in a domain this regulated can't be guessed, I logged open questions directly beside the designs and took them back to the client.

Four insights shaped the platform. Advisors didn't want a new system; they wanted their old system to feel better, after a decade of muscle memory. A signal can change form if it keeps its meaning: buy and sell had to stay instantly recognisable, but the colour didn't have to fill the whole window. Desktop power users judge a web app by what it can't do, so right-click menus, snap-to-grid layouts and saved table settings weren't extras. And access control turned out to be a product in itself.

Back-office application entry screen being designed in Figma, with its supporting pop-ups alongside
Working in Figma: the back-office application entry form and its pop-ups.

02 — Users & Roles

Four groups, four products, thirteen roles

The platform serves four groups across four products. Behind them sit 13 configurable role types covering trading, view-only access, operations, help desk support and administration. The full role structure only surfaced in the final month of the project, together with the admin panel itself, which no one on our side knew existed until then. It became one of the last and most critical products I designed.

  • Investors and clientsTrade, and open a CDS account to get startedAccess: Mobile app (trading plus CDS account opening) and the OMS
  • AdvisorsTrade on behalf of clients all dayAccess: Mainly the OMS; some back-office functions, depending on their role
  • Back-office staffRun the brokerage's daily operationsAccess: Back-office web app: 13 sections, each department sees only its own, tiered into employees, managers and admins
  • AdminsCreate roles and control access across the platformAccess: Everything, including the admin panel; used by help desk staff, admins and super admins

Roles created in the admin panel decide what each user can see and do in the OMS, the back office and the mobile app.

Diagram linking four user groups (investors and clients, advisors, back-office staff, admins) to the four products they use: mobile app, OMS, back office and admin panel
Who uses what: four user groups across four products, with role-dependent access shown dashed.

03 — Architecture & Iteration

Four connected products, one control centre

The admin panel sits at the centre, controlling who can do what in the other three. It covers users, CDS account settings, security and risk settings, announcements, reports, operations and approvals. The back office is organised into 13 sections, from Client and Portfolio to Approvals and Internet Trading, and sensitive actions go through a maker-checker approval step. The OMS is built around a home screen that combines market watch, order entry, the order blotter and the order basket, with market tools such as alerts, heat maps, quotes and trade summaries. The mobile app covers Home, Stocks, Transactions, Reports and Menu, plus CDS account opening.

The core flows run across them: placing an order from the market watch and tracking it in the blotter; building a basket of clients and placing the same order for all of them at once; opening a CDS account on mobile; submitting an action such as a payment or penalty waiver for an authorised approver to accept or reject with a reason; and creating a user in the admin panel, which sets their access everywhere.

Three areas went through the most rounds. The OMS home screen changed repeatedly with advisor feedback, especially the grid settings and right-click options, until every requirement advisors raised was delivered. The CDS account-opening flow was revised with the client's documentation department to meet regulatory needs, then presented to the CSE and approved. And the buy and sell windows and order basket were compared old against new; on my most recent visit, advisors were happy with the new windows and preferred the light theme, which now guides which theme we prioritise.

The constraints were real throughout: strict secrecy, with requirements withheld until NDAs were signed and almost no visuals of the existing system; every process passing regulatory checks with the CDS, SEC and CSE; a six-month timeline extended by another six, still short for four products; and developers and QA engineers leaving mid-project. With days or weeks to design entire flows, I used AI-assisted exploration to generate alternative patterns quickly, then refined them myself.

Diagram: the admin panel at the top controls access to the OMS, the back office and the mobile app, each listed with its main areas
The information architecture: the admin panel decides access across the other three products.

04 — Key Design Decisions

Three decisions that shaped the platform

Advisors had a decade of muscle memory, the regulator had the final word, and the platform's real structure only became clear near the end. Each decision balanced what people relied on against what the client needed to compete.

Decision 1

Fresh but familiar: redesigning the OMS for advisors who didn't want change

The problem

Advisors had used the old OMS for years and wanted the new one to behave exactly the same, while the client wanted a modern platform that could compete. Copying the old system would fail the client; ignoring advisors' habits would mean they rejected the new one.

The solution

I weighed three options: copy the old system closely, which was safe but would carry over the clutter that made it worth replacing; build a completely new experience, which was clean but would break habits advisors relied on all day; or keep familiar behaviour with fresh visuals. I chose the third.

Desktop power came across to the web: right-click menus, snap-to-grid layouts and built-in table settings, even though developers had to research how to build them. Because advisors spend their whole day in data tables, and the old system made them resize columns every time they logged in, I designed one central grid settings control, available on every screen, to sort, filter, reorder and resize columns, with each layout saved to the user's account. For buy and sell, rather than colouring whole windows as the old system did, I kept the order window background neutral (white in light mode, black in dark mode) and used green and red only where users enter order details, with the intensity tuned for each theme. The mobile app doesn't need that treatment, so it uses one unified design.

Why it works

Advisors judge a new tool by whether it slows them down. Keeping their working patterns removed that risk and gave me room to change the visual design. On my most recent visit, advisors were happy with the new buy and sell windows and showed a clear preference for the light theme.

OMS grid settings dialog: filter conditions, sort levels, and a column list to reorder, hide or set widths, over the dimmed home screen
One central grid settings control on every screen: filter, sort, reorder, show or hide, and set column widths, saved to the user's account.
A recreation of the legacy buy window, with the entire window filled in solid blue
Before: the legacy buy window, coloured edge to edge.
New OMS buy order window in light theme, neutral background with colour only in the order area
After: a neutral window, with green only where order details are entered.
Earlier dark-theme sell window with the whole window filled in deep red
An earlier iteration: full-colour dark windows.
Current dark-theme sell window: black window with deep red only in the order area
Current dark theme: a black window, with colour kept to the order area.
Earlier order basket design with annotations: a basket window and a basket order list
Order basket, before: one dense window with annotations from review.
New order basket cart listing staged orders for multiple clients, with Save Basket and Place Orders actions
Order basket, after: staged orders in one cart, saved or placed in one go.
Early design of the OMS home screen with market watch and ticker
OMS home, early design.
Current OMS home screen as built by the development team
OMS home, current build after advisor feedback.
Decision 2

Designing CDS account opening on mobile from scratch

The problem

The legacy mobile app couldn't open a CDS account at all, so new investors had to go elsewhere before they could trade. When I opened a real CDS account myself, the process was long, and that length is regulatory: every section of the KYC form is mandatory. It deters casual sign-ups, which protects brokers, but makes genuine investors give up partway through. I couldn't remove steps, so the job was to make a long process feel manageable.

The solution

The existing process was one long form with documents at the end: familiar, but it puts the hardest part last, after people are already tired, and they lose track of which document relates to what. Instead, I designed a guided flow broken into clear stages (verification, identity, personal details, residence, employment and investment, banking, tax and declarations) with progress shown throughout, and documents requested in context: your NIC with your identity details, your billing proof with your address.

When I uploaded my own documents there was no guidance on what a good photo looked like, so I added visual examples of acceptable and unacceptable images to reduce rejected uploads. Terms and declarations are available in English, Sinhala and Tamil. And where the CSE's own process ends at submission, with every update after that arriving by email, my flow ends with a confirmation screen and an in-app timeline to track the application's status. Next, the plan is to let users open a dedicated trading bank account directly in the app through a partner bank; it's marked "coming soon" while the regulatory and legal steps are worked through.

Why it works

Steps make a long form feel shorter and give people natural places to pause, documents in context remove the end-of-form scramble, and visual examples catch problems before submission rather than after review. The final flow was approved by the CSE, and in April–May 2026 the CSE released its own new account-opening experience with similar visual photo guidance: the same problem, solved the same way, independently.

The CSE's own CDS registration flow on mobile: requirements, residential details, documents uploaded together at step 6 of 7, and photo examples
For comparison: the CSE's registration flow, which gathers every document together at step 6 of 7 (example photos blurred).
All twelve stages of the mobile CDS account-opening flow: requirements, mobile and email verification, personal details, residence, employment, banking, tax and PEP, documents, declarations, advisor selection and confirmation
My flow, end to end: twelve focused stages, with documents requested in the step they belong to.
The document upload step with its Example Images help, and the guides it opens: acceptable and unacceptable NIC photos, selfies and bank proof (example images blurred)
Visual examples of acceptable and unacceptable photos for the NIC, selfie and bank proof (example images blurred).
Decision 3

Restructuring the platform around the admin panel

The problem

For most of the project, nobody on our side knew the client used a separate admin application, so every control feature had to live in the products we knew about. Risk engine settings, credit and margin approvals, custodian limits and loan-granting flows went into the back office, and a credit request flow into the OMS. They worked, but they never fit: the back office grew heavier, with daily operations sitting alongside system-wide controls.

The solution

In a meeting set up to resolve open concerns, the client mentioned their admin panel, and that one conversation changed the platform's structure. Keeping the controls in place behind role permissions would have meant less redesign, but left the back office overloaded and mixed staff's daily tasks with settings most of them should never touch. So I moved role-based access, risk engine settings, CDS account settings, user account creation and login control for advisors and office staff into a dedicated admin panel, using the client's existing split of responsibilities as the guide, because familiarity mattered here as much as anywhere. I discarded the credit request and loan-granting flows entirely.

Why it works

About 20 screens left the back office and the admin panel gained roughly the same number, but the back office became about a third less complex, on the backend as well as in the interface. Risk engine features that had been awkward to design became straightforward once they had the right home.

Before and after diagram: controls squeezed into the back office and OMS, versus a dedicated admin panel controlling the back office, OMS and mobile app, with the credit request and loan-granting flows discarded
Before and after the admin panel came to light.
Admin panel global parameters for exchange, security, SMS, sell-short, debtor restriction and broker credit settings
Admin panel: global parameters for security and risk settings.
Admin panel edit security dialog with exchange, company, instrument type, lot size and trading flags
Admin panel: editing a security's trading settings.
Admin panel create user dialog with mandatory fields, profile, linked CDS accounts and order limits
Admin panel: creating a user, assigning a role and linking CDS accounts.

05 — Handoff & Outcome

Teaching as much as handing over

I led design across all four products, supported by a design intern on back-office screens: I set the layout and structure for each screen, and the intern filled in table details such as column headers and sample data. Around us were two members of senior management, three frontend developers, two backend developers plus one brought in for complex work, two QA engineers and a DevOps engineer, with several developers and QA engineers leaving and new hires joining along the way.

No one on the team had a finance background, so every feature needed a detailed walkthrough. I annotated designs in Figma for the frontend developers, walked them through the concepts behind each screen, and troubleshot with them during build. I worked constantly from CSE documentation, using AI tools to summarise and translate dense regulatory material and explain complex financial concepts in plain terms before passing them on, and I manage the project in Jira alongside the QA lead, using Claude Code to help create tickets.

The project is still in progress, with each product at its own stage: the mobile app (iOS and Android) is fully designed and developed and in client pre-launch testing; the OMS is about 80% developed with client testing underway; the back office is about 80% designed and 10% developed; and the admin panel is about 90% designed with its backend in development. Early results include an estimated 10–15% improvement in workflow efficiency, with early signs it could approach 25% once the platform is fully in use, though a reliable figure will only come from running both systems side by side. Users can now stay signed in on mobile, web and desktop at the same time, CDS account opening on mobile is approved by the CSE, and every advisor requirement for the OMS home screen has been delivered. Because the client is one of the most established brokerages in the country, its move could encourage others to consider an alternative to the incumbent.

The OMS home screen as built by the development team, with a full market watch table and a live index ticker
The OMS home screen, as built by the development team.

06 — Colour & Theming

Choosing colour for how long people stay

Every colour decision on this project started with one question: how many hours a day will someone spend looking at this screen? Because each product was introduced to us separately, each was designed separately, and the themes reflect that.

Back office & admin panel

Calm light theme

Operations and admin staff live in these tools for the entire working day, keying in applications, reconciling accounts, and managing users. I chose a calm, light theme: soft off-white surfaces to reduce glare and eye strain, a quiet navy for structure, and a single clear blue reserved for actions, so dense forms and tables stay readable hour after hour.

  • Navy#1a2942Navigation and structure
  • Action blue#2563ebPrimary actions
  • Soft white#fafcffLow-glare work surfaces
  • Emerald#21bd66Active, verified, done

OMS web app & mobile app

Dark trading theme

The OMS and mobile app share the modern trading-platform style the client asked for, using Inter for interface text and a monospaced font for numbers, so figures line up in dense tables. Colour carries meaning rather than decoration: amber marks the primary action, green always means buy or gain, and red always means sell or loss.

  • Rich black#0a0e10Background
  • Amber#f1b90aPrimary actions and focus
  • Emerald#21bd66Buy, gains, success
  • Vermillion#dc2627Sell, losses, errors
  • Info blue#00c2ffInformation

OMS web app & mobile app

In progress

Light trading theme

Advisors showed a clear preference for the light theme, so it's now the one we prioritise and polish first, matched to the back office and admin panel so the whole platform feels like one product. Order windows stay neutral, with green and red only where order details are entered.

  • Brand blue#185fa5Shared accent across all four products
  • Confirm buy#008236Buy action and order area
  • Confirm sell#d14045Sell action and order area

The light theme across products

Light-theme OMS order windows next to the back office and admin panel they're being aligned with.

Light-theme OMS buy order window
OMS order entry: buy (light theme)
Light-theme OMS sell order window
OMS order entry: sell (light theme)
Back-office receipts entry form in the calm light theme
Back office: receipts entry
Admin panel global parameters in the calm light theme
Admin panel: global parameters

Towards one design system

In progress

Designing four products separately left them out of harmony: the OMS and mobile app share one style, built on an existing plugin-generated design system with tokens for dark and light modes, while the back office and admin panel don't follow it yet.

I'm now building one token-based design system to bring all four products together, with light and dark themes. Its 72 primitive colours feed semantic tokens such as Background, Text, Border, Accent and Status, each with a Light and a Dark mode, alongside a type scale, spacing and radius scales, mobile touch-target tokens, text and elevation styles, and the first shared components. Because every component reads from semantic tokens, moving a product to the light theme becomes a change of mode, not a redesign.

Overview of the current design system's component pages: typography, colours, buttons, inputs, alerts, navigation, and more
Current: the plugin-generated design system used by the OMS and mobile app
Figma global tokens for the OMS: primary, secondary, neutral and status colour scales with alpha variants, spacing and radius
Current: the OMS design tokens in Figma
Semantic colour tokens for background, text, border, accent, and status, each shown with a light and a dark swatch and hex values
New, in progress: semantic colour tokens with Light and Dark modes
First components of the new design system in light mode: inputs, status badges, a card, a selected table row, and a navigation item
New, in progress: the first token-driven components, light mode

07 — Reflection

What I'd do differently

Earn trust before asking for information

The hardest part of this project wasn't design. The client held back critical information because they feared their sensitive financial data could be misused. Next time I'd sign an NDA before anything else, so the client knows from day one that I'm legally bound to protect their data and can be completely open with me.

Experience the system before designing for it

I'd start by opening a CDS account and getting access to the existing system, then spend a week sitting with staff to learn which sections they use, what for, what they struggle with, and what they no longer need. Only then would I move to information architecture and wireframes.

Map every system early

The admin panel only came to light near the end and changed the platform's structure. Asking up front about every tool the client uses would have saved weeks of work.

Start with one design system

Designing four products separately left them out of harmony. A shared system from day one would have kept them consistent and made handoff easier.

Showcase

A closer look

01

OMS web app

The order management system advisors and dealers use to watch the market and place trades. About 80% developed, with client testing underway.

OMS home screen in development, showing a full market watch table and a live index ticker
Home screen, as built by the development team
Detail quote screen with trade summary, trade book, and price history chart
Detail quote
Buy order window in dark theme
Order entry: buy, dark theme
Grid settings dialog
Grid settings
Portfolio management window listing holdings with balances, costs, and market value
Portfolio management
New order basket with no staged orders yet, showing the add order form
Order basket: building a new basket
Flow diagram of the order basket window: viewing, saving a blank basket and adding orders
Order basket flow 1
Flow diagram from the buy and sell ticket: adding to a cart and saving as a new or existing basket
Order basket flow 2
02

Mobile app

Trading on iOS and Android, including the CDS account-opening flow the legacy app never had. Fully designed and developed, now in client pre-launch testing.

Market info screen with CSE overview, market contribution, and index chart
Market info
Buy order screen with account summary and market depth
Buy / sell
Watchlist with price, volume, and change for each security
Watchlist
Watchlist filter and sort sheet
Watchlist filters
Security details screen showing market depth
Market depth
Top gainers list of CSE market leaders
Top stocks
CDS account opening: uploading ID evidence, a selfie, and billing proof
CDS onboarding: ID evidence
CDS account opening personal information form
CDS onboarding: about you
CDS account opening employment information form
CDS onboarding: employment
CDS account opening banking information step
CDS onboarding: banking
CDS account opening tax information and PEP status step
CDS onboarding: tax and PEP
Open a bank account option marked coming soon
Open a bank account: coming soon
Select an advisor step (company name blurred)
CDS onboarding: select advisor
Confirmation screen: you are all set
CDS onboarding: all set
Create a new password screen with live password rules
Account recovery
03

Back-office web app

Where operations staff manage clients, portfolios, accounts, settlements, and regulatory file uploads across 13 sections. About 80% designed and 10% developed.

Client inquiry screen showing account position transactions and balances
Client inquiry: account position
Accounts receipts entry form
Receipts entry
CSE file upload screen with verification status for each file
CSE file upload
Portfolio quantity adjustment screen
Portfolio quantity adjustments
Maintenance undertaking details with pledged and unpledged records
Undertaking details
Full client application entry form
Client application entry
04

Admin panel

Controls for users, roles, CDS accounts, security and system-wide trading parameters. About 90% designed, with the backend in development.

Global parameters settings for exchange, security, SMS, and credit rules
Global parameters
Edit security dialog
Edit security
Create user dialog
Create user

Next up

More work on the home page

View all projects