Turning a formula language into something you can see.
District administrators were writing nested formula syntax by hand to derive every username, email, and directory attribute for thousands of students and staff. A wrong character wasn't caught until the accounts already existed.
Work shown with enterprise-identifying details removed. Product name and interface are my own; original assets are not shown.
Every district names people differently.
When a district syncs its people into a directory, something has to decide what each person's username, email address, and display name will actually be. One district wants first initial plus last name. Another wants the employee ID. Another wants first name, a dot, last name, all lowercase, with a fallback when a field is missing.
That decision is expressed as a mapping: for each destination attribute, a rule that derives it from source data. The rules have to handle real names, and real names are messy.
A programming language, handed to people who don't program.
Administrators wrote these rules as raw formula strings. Source fields wrapped in one delimiter, destination fields in another, function calls in backticks, nested several levels deep, with positional arguments and no autocomplete.
Two problems compound each other. Getting the syntax right is hard, and there is no way to see what a formula produces until it has already run. By then the accounts exist. Someone's login is wrong, and fixing it means correcting the rule and reconciling every record it already touched.
- The output is an identity, so a mistake doesn't degrade an experience, it locks someone out
- Errors are silent. A malformed rule often produces a plausible-looking wrong value rather than a failure
- It runs at scale. One bad rule applies to every person in the district at once
- Discovery is delayed, usually until someone tries to log in and can't
The syntax was visible. The result was not.
It would be easy to read this as a syntax problem and solve it with better validation or an autocomplete. That helps, but it addresses the smaller half.
The rule an administrator types is not the thing they care about. They care about what comes out the other side for actual people. The old interface showed them the input and hid the output, which is exactly backwards for a task where the input is unfamiliar and the output is what matters.
Blocks to build it, records to check it.
- Rules are written as raw formula strings, by hand
- Nested function calls with positional arguments and delimiters to get exactly right
- A text field shows the rule, never the value it will produce
- A malformed rule often yields a plausible-looking wrong value rather than an error
- Typed blocks dropped into labelled slots
- Nesting expressed by placement rather than by counting parentheses
- Functions grouped by intent and searchable
- Every change re-evaluated live against sample records, before saving
Blocks on the canvas, sample records evaluating live beneath them.
The sample records are edge cases on purpose.
A preview is only as useful as the records it previews against. The obvious choice is a few clean, ordinary names, which would confirm that a rule works and teach an administrator nothing.
So the preview set is deliberately awkward. Someone with an apostrophe in their surname. Someone with accented characters and a hyphenated name. Someone with no middle name. Someone with an empty email field.
- Not confirming the rule works on an easy name
- Showing where it breaks, before it breaks on someone real
- Making the fix obvious in the same screen where the problem appeared
Build a simple first-initial-plus-surname rule and the preview immediately produces an apostrophe and an accented character inside what is supposed to be a login. Nobody has to explain that this will fail. The administrator sees it, reaches for the function that strips diacritics, and watches the value correct itself.
The builder, rebuilt and interactive.
I rebuilt this as a standalone prototype with fictional records, embedded below. Snap together a first-initial-plus-surname rule and watch the preview. Two of the four sample records produce a username that would not survive contact with a directory.
Keep the raw formula, or force everyone into blocks?
Removing the text view entirely would have made the product simpler and the design cleaner. It would also have stranded every administrator with formulas they had already written and habits they had already built, and taken away the fastest path for the few who genuinely prefer typing.
Shipped, and in daily use.
The block builder is in production. Administrators define attribute mappings without writing formula syntax, and see the resulting values for real records before anything is saved. The class of error where a rule looks right and produces the wrong identity is now visible at the moment it is created rather than after it has propagated.
Preventing bad input is half the job.
The blocks made the rule easy to write. The preview made it possible to know whether it was right.