Arresting and visualizing complex conditional logic using best practice boxes-and-arrows

Foundations

Before subjecting and evaluating popular SaaS platforms and emerging AI agents for their value-add potential, we should first agree on the principles and best practices to use for those evaluations.

The principles I use to determine the standards I choose for my flow artifacts are described below:

Information processing – Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts.

These standards, established by the International Organization for Standardization (ISO) and previously by the American National Standards Institute (ANSI), are detailed in ISO 5807:1985 and provide conventions for documenting data, programs, and systems. These standards inspire the symbology contained in FigJam, LucidCharts and other popular flow diagramming tools. In this designer’s opinion, these ISO standards fall short of what is needed in order to design out proper sitemaps and, more importantly, for arresting and visualizing complex task flows from a user experience point of view. 

In 2000, Jesse James Garrett introduced a set of flow-diagramming best practices that reimagined electrical schematic conventions for interaction and information design. By assigning logic-based definitions to simple geometric shapes, he transformed them into a symbolic language specific for expressing the user experience layer of relational hierarchies and transactional funnels. These symbols, when combined correctly and consistently, allow information architects and interaction designers to articulate complex, condition-heavy funnels (from the user’s point of view) with clarity and precision.

After auditing two SaaS platforms, I found that each used symbology inconsistently—and none provided a clear, comprehensive definition of what each geometric shape represented or how it related to a logical operation. Simply labeling a trapezoid as a “trapezoid” offers little value to a designer (especially newbies) trying to use a trapezoid meaningfully in a diagram.

• Today’s SaaS platforms fail to provide definitions for each geometric shape contained in their libraries failing to encourage how each shape might be leveraged to solve conditional branching and logical operations
• Today’s SaaS platforms encourage designers to consider flow diagrams as a design artifact (versus an alignment artifact) encouraging creative autonomy which ultimately leads to diagrams saturated with unnecessary ornamentation and visual distraction
• Today’s SaaS platforms fail to establish their own internal best practices for use or embrace other established versions beyond the 5807 standard which is not optimized for expressing user experience

Producing flow diagrams by hand allows me to submerse myself into the problem space. For me, the reward isn’t the flow diagram itself (it’s an alignment artifact)… it’s the empathy and awareness gained from having spent the time putting one together. Here are some of the excuses I’ve heard in the past for not adopting best practices:

• “Best practices don’t matter…”
• You’re going to need to define some sort of system to model the flow after, so why not established best practices?
• If you’re planning to produce more than 1 flow in your lifetime, redefining flow symbology and just “winging it” each time doesn’t make sense… the hard work of defining a symbology and visual vocabulary has already been done for you.
• “Learning best practices takes too much time…”
• So does the churn involved with not clearly articulating important scenarios, way-finding and the logic involved that will drive the overall experience branching and interaction design.
• If you haven’t taken the time to learn and practice them a few times, you can’t really argue against them.