Aurora Securities
Aurora is SmartStream’s reconciliations and payments product. Its securities launch needed a register that banks and hedge funds could trust for securities data, so I redesigned how a security is created, found and read.
- Role
- Owned Aurora’s product design for over 12 months
- Scope
- Core workflows, information architecture, UI patterns. Securities module from zero.
- Team
- Product, development, QA, documentation
- Status
- Designed for the Aurora securities launch. Handed off with user flows and logic documentation.
Problem
One security can list on several markets, in several currencies, under several identifiers. The legacy screens scattered those across rows and screens, so people moved back and forth between records to understand a single asset. That slowed routine work and raised the risk of errors, and it got worse as the securities module grew.
Workshop
I ran a two-day workshop in Vienna with development, QA, product and documentation. We mapped how different users work with securities data day to day, then turned those workflows into system structures. It showed the system was organised around how data was stored, not how people think about an asset.
Three decisions
1 One record per asset, with its listings nested
Rejected: a separate row for every listing, as the legacy screens had it.
People look for the asset first and the market second. ISIN and CUSIP belong to the asset; market, currency, SEDOL, Bloomberg ID and internal code belong to each listing. The screen now follows that model.
2 Active assets by default
Rejected: opening on the whole register and leaving people to filter it.
Daily work happens on active assets, so that’s where the screen opens. Inactive ones are one tab away, and nothing is hidden.
3 Identifiers people can extend
Rejected: the fixed set of identifier fields the requirements described.
An unscripted client walkthrough during a design review surfaced a need nobody had documented: custom identifiers, especially internal codes and SWIFT. I added an inline add, and updated the create flow for primary and secondary listings. Try it below.
Constraints
Strict compliance requirements, a launch date, and no tolerance for breaking existing workflows or terminology. The interface had to get simpler for operational users without simplifying the data underneath, for technical users too.