Case Study: Inline Authoring for Decision Tables

2024 – Staff Product Designer

Overview

Flow Designer users couldn’t create Decision Tables without leaving the tool. The system required switching to a separate application, defining logic there, then returning to wire it into the flow. I designed an inline creation path that lets users define the basic structure—inputs and outputs—without breaking focus. This allowed users to stay in Flow Designer long enough to complete their logic scaffold before handing off to the full table editor when ready.

The Problem

Creating a Decision Table involved multiple steps across disconnected systems. Users had to pause flow construction, launch Decision Builder, define inputs, outputs, and metadata, save the object, and return to Flow Designer to wire it back in. This added friction at the exact moment users were trying to move fast. Some gave up mid-way. Others deferred logic until someone else created the table. Context switching and tool fragmentation created delays that didn’t need to exist.

Planning the System

Before design work began, I participated in a pre-design planning process with PM and engineering. The purpose was to align on system behavior, technical constraints, and deliverable expectations. We focused on defining how users would initiate table creation, what data was required, how inputs would be mapped, and how the object would persist.

Two system flowcharts were created. The first draft mapped the basic flow structure: how the modal would be launched, how users would add inputs and outputs, and how the handoff to Decision Builder would occur. After review, we revised the diagram to reflect changes discussed in working sessions. This included input validation logic, column configuration behavior, permission handling, and modal-to-flow reentry.

These artifacts defined what needed to be built and in what order. They specified the fields required for a valid object, the sequencing of UI interactions, and how error states would be managed. This planning also established a shared understanding across teams and reduced ambiguity once the design phase began.

Design Goals

We needed to allow Decision Table setup directly inside Flow Designer. The feature needed to focus on inputs, outputs, and basic metadata—not full rule logic. The solution had to work inside the existing modal architecture without requiring large refactors. Visuals and interactions needed to match the rest of the flow builder environment.

What I Designed

Users can now define the table’s inputs and outputs as part of flow creation. This creates a connected, valid object without needing to launch another tool.

Inputs are added one at a time with inline validation. Each step is focused, fast, and follows a clear, repeatable pattern.

Empty states and real-time feedback guide the user through minimum required setup. There’s no guesswork about what needs to be completed before saving.

Although the interface still uses a modal, the layout avoids branching, scrolling, or breaking the user’s context. It works with the limitations of Flow Designer while still improving the experience.

Once the user completes the input and output structure, a valid but incomplete Decision Table is created. Users can finish rule configuration later in the full Decision Builder UI. This prevents duplicate effort and keeps ownership clear.

Constraints

The Flow Designer architecture is tightly coupled to modal interactions. Full embedded authoring was not possible due to the engineering cost. The new feature also had to be compatible with existing Decision Table logic and data models.

Outcomes

The inline authoring feature reduced friction for users who needed to define decision logic while building a flow. It allowed them to scaffold a valid Decision Table without stopping work or switching tools. Time to completion dropped, especially for simpler flows where full table logic could be added later.

Decision Tables became more visible and approachable within Flow Designer. The contract-first approach helped teams delegate rule authoring without blocking flow development. This reduced dependency bottlenecks and made automation more modular.

The authoring pattern introduced here has since been referenced in early planning for other logic tools. Its structure, field sequencing, and persistence model created a baseline for future work on inline configuration across the platform.

Conclusion

This work made logic creation faster, more accessible, and easier to maintain. It gave users the ability to define structure when they needed it, without leaving their current context. It also laid groundwork for a broader approach to logic reuse across the platform. The work shipped and shaped the way future logic tools were planned.