Anonymised project

Designing business banking around the business, not a private account

The business banking web app’s main account view on a laptop, resting on a rust-coloured sofa.
Client
Client withheld (NDA) · via Stereogram Studio
Role
Web app design · Design system
Year
2025–2026
Team
Lóránt Valaczka (web app, design system) · Miklós Kádas (mobile app) · a product owner
Duration
March 2025 – March 2026
Platform / scope
Web app + mobile app

Licensed payment institution · SME banking · Web and mobile app · Client name withheld under NDA

Client project as part of Stereogram Studio

My role

Product designer at Stereogram Studio. I owned the web app and the multi-brand design system, then carried the product on as its only designer.

Problem

A payment institution wanted a business account as easy as a consumer app. But a business means several companies, accounts and roles.

Approach

Designed the app around the business: one login for several companies, a role in each, and every limit shown instead of hidden.

Key insight

A business account is shared by a team, so the app has to start from the business and its roles, not from one person’s account.

Impact
  • Web and mobile designs handed over to development; the product is not live yet
  • One login for several companies; the client’s 4 roles and 33 permissions work the same on web and mobile
  • A design system for at least 3 brands, with 400+ tokens exported as JSON to development
  • A transaction flow designed end to end, every status from a transfer in progress to a collected fee
Timeline

March 2025 – March 2026

Skills

Design systems · Web app design · Role-based UX · Multi-brand tokens · Developer handoff

Three phones left to right: the business switcher, then the same home screen for two roles, the second with its transfer actions disabled.
One login, several companies, and a home screen showing each person what their role allows.

The images are mockups: colours changed and data invented, so the client stays anonymous.

Inputs

Benchmarks of competing business bank apps, mainly Revolut and Wise · patterns from Mobbin and tests of other bank apps · consulted: Stereogram’s founder and the client team

AI in this project

AI helped with interface copy and research; in 2025 it was not ready for more, so the system and the screens were designed by hand.

Product

Built around the business

Company accounts, roles and signing sit in the core

A business is several companies, each with several accounts, and a team with different rights. So company accounts, roles and signing sit in the core, not as an add-on to a private account.

I carried the product forward as its only designer

Two of us designed it with the product owner: Miklós Kádas the mobile app, I the web app and a design system for at least three brands. When Miklós moved on later in 2025, I carried the product as its only designer.

Transaction list and detail: one module on web and mobile, covering every status.
Many businesses

One login, several companies

Separate logins or one long list slow them down

Business owners often run more than one company, each with several accounts. Separate logins or one long list slow them down and invite mistakes.

The app has two levels

So the app has two levels: a business switcher changes the company, an account selector changes the account. Balance, cards, transactions, to-dos and the person’s role all follow.

One login: the balance, the transactions and the role change with the company.
Roles

A role per person, per company

A role belongs to a person in one company

The same person can be an owner in one company and a card holder in another. Switching company switches the role too.

The 33 permissions were given

The client defined the four roles and their 33 permissions, and the specification was precise. That part was given. What the app does with each limit was ours to design.

The company sets the role; the role sets what the app allows.

Schematic: the segments count the permissions; they are not the specification's list.

Hidden or disabled?

We showed the limit

I argued for disabled

Every feature a role cannot use meant a choice: show it disabled, or hide it. Someone with fewer permissions should still know a feature exists, or the company ends up with a communication gap.

The price is noise, but not needless noise

The product owner saw the same risk and agreed. Only what would sit behind “Other” anyway stays hidden.

A limit you can see is information. For anything a team shares, disabled beats hidden.

Try it out ↓
A card holder’s transfers stay visible but disabled; a tap explains who grants access.
Role views

Same app, four roles

Pick a role and a platform: the same app shows what that role can use.
Handoff

From Figma to developers

Figma was the source of truth

The tokens went to development as a JSON export. Change requests during development support were mostly real development; we fed those back into Figma.

One system, several brands

Three token layers: primitives, semantic, component. Each brand is a Figma mode on the primitives, so a component never knows which brand it wears.

Tokens leave Figma as JSON; a new brand is a new column.

Schematic: brand names and colours are invented; collection and token names are the system's own.

Closing

How it went

My part, and what comes next

Role

The web app, the multi-brand design system and the developer handoff, and later the whole product as its only designer.

Team

Lóránt Valaczka, web app and design system · Miklós Kádas, mobile app · a product owner · consulted: Stereogram’s founder

Next

The MVP was cut to ship sooner: the EUR account, some filters and the chart overview follow, designs ready. Disabled-over-hidden is untested in real use.

The full storyPortfolio deckThe complete case, slide by slide.Open →

Next case

MagNet’s New UI home screen on a phone, tilted on green velvet.

MagNet Bank · via Stereogram Studio

Bringing a bold brand into the app

A home screen coded with AI, in two versions the bank can ship in steps.

UI design · Design system audit · Accessibility · Prototyping