// Case study 01 · Design systems · Enterprise banking
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.
One empty value. Five different answers.
Across the CRM, an empty field was rendered however each screen's author felt that day. Same underlying state — no data — read five different ways by the advisor looking at it. In wealth management that ambiguity isn't cosmetic: a field reading 0.00 where it should read no data misrepresents a client's position.
Inconsistent null-handling, sampled from real screens (localised recreation, NDA-safe).
"Empty" isn't one state. It's four — so one blanket rule, and three exceptions.
The rule set is : a developer never makes a judgment call, an advisor never wonders.
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.
The address row is the one people miss: a concatenated field punctuating gaps that were never there.
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 org builds against, instead of a dozen judgment calls made at render time. Specifics are under NDA, but the win is simpler than a number: the guesswork left the screen.
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.
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 judgment call.
"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.
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.
Any datatype with no value displays an emdash. Simplify string and number before anything else.
A financial field that exists and is expected to hold an amount — the zero is intent, not absence.
A financial field where no value can be resolved — you can't show 0.00, because no value was ever expected.
When an output field composes multiple inputs, skip optional empties — never punctuate a gap.
The logic was the easy part. Alignment was the work.
A display rule only becomes a standard when the whole delivery org 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.
Seven roles, one rule. This is what "systems thinking" looks like as a team sport.
Written as logic, not as guidance.
Guidance gets interpreted. Logic gets built. The rule set shipped as an implementation spec with no judgment calls left in it — which is the only reason it survived contact with seven teams.
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