Atlas Wealth · Web & mobile

Atlas is a private personal wealth application for keeping investments, cash, property and their supporting documents together. The product centres on a practical question: what do I own, and what supports the value I am looking at?

I owned the work across product strategy, research, UX/UI and development. The work connected the product model to the interface: how information enters Atlas, how it changes, and how the owner checks it later.

A total becomes difficult to trust when its currency, date or source is unclear. A manually updated property value is different from a current market price. An opening balance is different from a complete purchase history. Putting them on one dashboard does not resolve those differences.

The design challenge was to make a combined view useful while keeping its limitations visible. Atlas needed a readable overview, a traceable history and a way back to the evidence behind a record.

Every summary needs a path back to the record that explains it.

01 / Give the overview a job

The documented iteration moved from spacious summary cards to a compact analytical grid. One portfolio-value signal leads, supported by saved history, allocation, account contribution and items needing attention. Aligned panels and restrained borders establish hierarchy without making every metric compete for attention.

The tradeoff is density. The overview stays selective and links to fuller records. Where history is insufficient, an explanation takes the place of an invented chart.

02 / Use the owner’s language

“Assets” replaces “security master”; “update a value” replaces internal accounting terminology. The owner creates an investment once and selects it in later records. This reduces conceptual duplication while preserving the distinction between an asset, the account holding it and an event that changes it.

03 / Make uncertainty actionable

Missing evidence, older values and differences between records and calculated totals have written states. Data Checks keeps both values visible and points to the affected account or asset. Colour supports the message; it does not carry the meaning alone.

04 / Review before committing

The web import flow supports CSVs, manual entry and statement or screenshot extraction. Extracted information is reviewed before it becomes a saved holding. Account connection is explicitly marked as a future option. The key boundary is user control: assistance prepares the record; the owner confirms it.

1. 1. Establish what you own. Choose an investment type and entry method, connect it to an account, and review the values before saving. Native currency and the GBP conversion remain distinct.
2. 2. Record what changed. Capture a purchase, income payment, cash movement or updated valuation. Corrections retain history through reversal and replacement, rather than silently rewriting a past event.
3. 3. Return to the evidence. Review the portfolio, investigate a data check and follow the account or asset context. Supporting documents sit in a private vault with links to the records they explain.

These journeys are described from the implemented flows and design records. The screens were captured from the signed-in web app, and the forms were opened without creating financial records.

The list supports retrieval through search, account type and currency. Adding an account opens a side flyout, keeping the existing workspace visible while grouping legal owner, provider and account details into one task. The action footer stays separate from the scrolling form.

The asset list puts name, currency, pricing status and account context together. Its companion flyout separates the familiar details from optional identifiers and valuation settings, so creating an asset does not require starting with a ticker or an ISIN.

Atlas extends into an Expo / React Native app with five destinations: Overview, Portfolio, Record, Documents and More. Desktop tables become structured rows. Longer financial tasks use full-screen forms, and a review step separates entry from confirmation.

The shared foundation is the meaning of the data and the design tokens. Components remain platform-specific. Mobile preserves system text scaling and generous touch targets; account and asset details sit in native navigation stacks.

Connectivity is also part of the experience. Last-known data carries an offline or stale label. Financial changes require a connection and confirmed success. Retrying a failed request retains the same operation identity, protecting the owner from duplicate records.

The mobile extension remains a release candidate. Signed builds and physical-device validation are the next gates before distribution.

The implemented outcome is a web application and a mobile release candidate organised around the same private wealth record. The repository documents automated preflight checks, but signed native builds, device testing and release gates remain outstanding. This is not a claim of a public mobile launch.

The design lesson is that financial clarity depends on relationships: a value and its date, a change and its history, a record and its proof. A calmer interface is useful only if those connections survive the simplification.

The next evaluation should test whether an owner can explain a total, identify an outdated value and correct a record without losing confidence. Task completion, interpretation errors and recovery from interrupted mobile flows would provide stronger evidence than screen counts. No measured adoption or usability improvement is claimed yet.