Dense business rules become clear flows before the screen
Dense business rules only become a clear flow when product, design, and engineering write them down together, before any screen.
Dense business rules only turn into clear flows when product, design, and engineering write them down together before any screen. Before that, it's guessing.
I reached this idea in two places. At a large bank, between 2023 and 2024, I designed credit and loan journeys for rural producers.
Later, on SaaS platforms, with an international team, I documented business rules and supported the development team during delivery.
In both cases, the hard work was not on the screen. It was in understanding the rule well enough to explain it in a few words.
This piece explains how I get to that understanding and why it has to come before the first screen sketch.
You don't need to be a designer to read it. You just need a product where customers get lost in conditions, exceptions, and deadlines only the team knows.
It isn't about tools, either. It's about the order of the work: first the rule, then the screen.
Where dense rules block the flow
At the bank, my job was to turn dense business rules into clear flows for the people who farm the land.
A dense rule is one with exceptions, conditions, and dependencies. Whoever knows it by heart tends to forget that the customer doesn't.
When it reaches design only halfway understood, the screen inherits the confusion. You get unexplained fields, vague errors, and steps out of order.
A rural producer has no duty to know how the bank decides. They need to know what to do now and what comes next.
For the screen to say that, someone has to understand the whole rule first. That someone can't be the designer alone.
That is why I worked close to product and engineering, to ensure technical feasibility and consistent design decisions in delivery.
Feasibility and consistency depend on the same thing: everyone reading the same rule, the same way, before anyone starts designing or coding.
Writing rules with product and engineering
On the SaaS platforms, documenting business rules was part of my job, along with flows, wireframes, and high-fidelity screens.
On projects for large financial institutions, I also documented rules and flows to align product, design, and technology.
Documenting, here, does not mean writing a manual. It means putting each rule in plain language, with the common case and the exceptions side by side.
Product says why the rule exists. Engineering says what the system already does and what it costs to change. Design says how it shows up for the user.
When all three read the same document, the discussion moves off the screen and onto the rule. That is where it belongs.
On the SaaS work, I also facilitated co-creation and alignment sessions between the Product, Design, and Technology teams.
Those sessions work better with the rule already written on the table. Nobody has to remember how the system decides.
From document to clear flow
With the rule written down, the flow almost draws itself. Each condition becomes a question, and each exception becomes a named path.
Wireframes then test the order of the steps, not the rule. High fidelity takes care of the copy, the hierarchy, and the design system.
On the SaaS platforms, I created flows, wireframes, and high-fidelity interfaces in line with the design system.
I supported the development team during delivery, with the documented rule at hand.
Delivery changes too: with the rule written down, the developer's questions have a place to be answered, without relying on anyone's memory.
After launch, I analyzed metrics and feedback for continuous improvement.
The written rule helps with that reading: it becomes easier to tell whether the problem is in the rule or on the screen.
If your product has dense rules, start with the document, not the screen. Get product and engineering together and write each rule down to one plain sentence.