At the center of user experience is a simple goal: make it easier for people to make decisions.
That principle does not stop at the customer. It applies just as much to the people building the experience. In many cases, the quality of the external experience is a direct reflection of how easy or difficult it is for internal teams to do their work.
The quality of the external experience is a direct reflection of how easy or difficult it is for internal teams to do their work.
I saw this clearly during the launch of the new pricing box architecture for event pages. The system itself worked. Pages could be created, structured, and published. But there was a layer underneath that introduced constant friction, and it showed up almost immediately.
Disclaimers were handled as a manual step.
Each page builder had to determine which disclaimer applied based on a set of variables. They had to think through the event type, whether it was member-only or open to all, whether it included an on-demand or virtual format, whether it was considered a visionary event, and it applied to a council audience or a broader group. Even within those categories, there were subtle differences that affected how many disclaimers appeared.
There were seven to eight possible disclaimers in total, with multiple permutations depending on how those factors combined. Nothing in the system guided that decision. It relied entirely on the person building the page to remember, interpret, and apply the correct logic every time.
Within a few months, the pattern was clear. Inconsistencies were happening constantly. Disclaimers were missing, incorrect, or applied in the wrong context. This was not a performance issue. It was a systems issue.
This was not a performance issue. It was a systems issue.
The work itself required too much thinking. Page builders would pause mid-task to figure out what applied. Questions would come up repeatedly. UX review became a safety net, but it was happening after pages were already live. That meant we were catching errors on published content, correcting misinformation, and spending time reviewing something that should have been handled earlier in the process.
At that point, the focus shifted. The question was no longer how to help people remember the rules. The question became how to remove the need to remember them at all.
When I looked at the disclaimers more closely, the logic was consistent. The combinations felt complex in practice, but they followed patterns. That meant the system could handle it.
I wrote an epic that mapped out the full disclaimer logic, including all edge cases. Then I translated that into individual tickets that defined how the system should behave. The goal was simple…
Move the responsibility from the person to the system.
Instead of selecting disclaimers manually, the connection to the CRM and certain taxonomy would define structured inputs. The system would then determine the correct disclaimer based on those inputs. The outcome would be consistent every time, without requiring additional thought.
The impact was straightforward.
Page builders would no longer need to hold multiple rules in their head. Each event setup would save time simply by removing the need to stop and decide. UX review would also become more efficient, since it would not need to validate disclaimers after the fact. That would reduce both time and rework.
More importantly, it would prevent errors from reaching the user.
Disclaimers are not the primary focus of a page, but they still matter. When information is inconsistent or incorrect, it introduces doubt.
Even small inconsistencies affect how much users trust what they are seeing. When the system produces consistent, predictable output, that trust increases.
When someone pauses, something is unclear.
This is what reducing cognitive load looks like in practice.
It is not only about simplifying what users see. It is about designing systems that reduce the need for interpretation at every step.
Clear structure, clear logic, and predictable behavior allow people to move forward without hesitation.
Reducing cognitive load means removing that hesitation before it has a chance to show up.
Work With Me
If your product depends on complex systems, content workflows, or structured data, I help teams define how those systems should work before development begins.
My focus is on reducing ambiguity, aligning teams, and ensuring what gets built behaves as intended in real use, without constant rework.