All work

// Case study 01 · Design systems · Avaloq

Null-state display rule · platform-wide

The Art
of Nothing

In private wealth software, a blank field isn't nothing — it's a . I wrote the rule that ended the guesswork.

Live The rule is running on this page. Six representative null cases, four rules, one switch — throw it and every field names the rule that fired. Throw the switch
My role
Rule ownerAuthored the rule set and drove sign-off
Employer
AvaloqSwiss private-wealth platform
Scope
Platform-wideNull display, every datatype, every screen
Shown here
RecreationsLocalised, NDA-safe — no client data
01 · The situation

One empty value. Five different answers.

Across the CRM, each screen handled the same underlying state — no data — according to its own local convention. The advisor looking at it saw five different renderings. In wealth management, that ambiguity isn't cosmetic: a field reading 0.00 where it should read no data misrepresents a client's position.

CRM · Investment Proposal · as-found
DescriptionNone
LocationN/A
Channel(blank)
Expected Volume0
Related Objectsnull
Product—hidden—

Inconsistent null-handling, sampled from real screens (localised recreation, NDA-safe).

02 · The move

"Empty" isn't one state. It's four — so one blanket rule, and three exceptions.

The rule set is : a developer never makes a judgement call, an advisor never wonders.

Blanket rule Any datatype with no value displays an emdash.
Exc. 1 · financial, expected The field is expected to hold an amount, so the zero is intent, not absence. 0.00
Exc. 2 · financial, invalid No value can be resolved — showing 0.00 would assert a position the system doesn't know.
Exc. 3 · concatenated An output composing several inputs skips optional empties. Never punctuate a gap. skip
03 · The payoff Live · try it

The same screen, before and after the rule.

Each field shows which rule fired once the standard is applied. It resolves on its own as you reach it — toggle back and forth as much as you like.

Live Throw the switch. Every field names the rule that fired. Six fields · four rules
CRM · Investment Proposal
DescriptionNone
Expected Volumenull
LocationN/A
Expected Profit(blank)
Related Objects0
Domicile AddressWall St, , , NY
Ambiguous — reader must guess Correctly absent — emdash Resolved to a real value

The address row is the one people miss: a concatenated field punctuating gaps that were never there.

04 · The result

One everywhere-problem became one rule.

The rule set became the single source of truth for null-value display — written as deterministic logic the delivery teams build against, instead of a dozen judgement calls made at render time. Specifics are under NDA, but the result is simpler than a number: the guesswork left the screen.

7
Roles aligned
4
States of "empty"
Brief · completeEvidence follows · optional

Everything above is the argument.

Below: why the ambiguity cost real money, the four states you can pull apart yourself, the reasoning behind each exception, and the seven roles it took to make a rule into a standard. Nothing under this line is load-bearing — you already have the case.

01 · Why it cost

A blank is a question the advisor can't afford to guess.

Is this data missing, or is the value actually zero?

A field that reads "0.00" when it should read "no data" misrepresents a client's position — and a field that reads "None" where a number is expected makes an second-guess the whole record. Inconsistent empties quietly erode trust in every screen they touch, and trust is the entire product.

Blank meant three different things depending on who read it.
Relationship Manager · discovery session

So the goal was never a prettier placeholder. It was to make "empty" legible and predictable — so a never has to make a judgement call.

02 · The four states Live · try it

"Empty" isn't one state. It's four.

The breakthrough was refusing to treat emptiness as a single case. Each of these means something different to the person reading it — so each earns a different treatment. Select one to see what it renders as.

03 · The rule set in full

One blanket rule. Three exceptions.

The same rule set as the brief, with the reasoning that earned each exception a place. It starts with a single default, then handles the three cases where that default would lie.

Blanket rule

Any datatype with no value displays an emdash. Simplify string and number before anything else.

Exception 1 · Financial, expected

A financial field that exists and is expected to hold an amount — the zero is intent, not absence.

0.00
Exception 2 · Financial, invalid

A financial field where a value was expected but could not be resolved — you can't show 0.00, because that would assert a position the system doesn't know.

Exception 3 · Concatenated

When an output field composes multiple inputs, skip optional empties — never punctuate a gap.

skip
04 · Who shaped the rule Live · try it

The logic was the easy part. Alignment was the work.

A display rule only becomes a standard when the whole delivery team agrees to build against it. Turning "just show a dash" and "just show 0.00" into one deterministic rule meant winning — and being sharpened by — seven roles. Hover or tab through each one.

Null-state rule
EvidenceBusiness Analyst · Acceptance criteria

Translated the display rules into acceptance criteria and pressure-tested every edge case against real data scenarios.

Seven roles, one rule. Each role changed what shipped.

05 · The shipped spec

Written as logic, not as guidance.

Guidance gets interpreted. Logic gets built. The rule set shipped as an implementation spec with no judgement calls left in it — which is the only reason it survived contact with seven roles.

01 Rule set as shipped spec · redacted
06 · Reflection
The work I'm proudest of is invisible. Nobody notices null-handling done right — they just trust the screen. That's the job.
Djoaniel Hernandez · System note № 04