2022

Automations

Visual rules engine for Streampoint's B2B event platform. Cut developer configuration requests by 85% in beta by letting customer success teams build complex conditional logic themselves.

Automations

Case highlights

85% ↓

Dev config requests

during beta vs pre-launch baseline

Days saved

Event setup time

complex international events, eng off the critical path

Visual rule builder

Surface

nested conditions through hierarchy, no tree diagrams

Role
Senior Product Designer · Lead
Team
1 eng lead · 5 full stack devs
Timeframe
2022
Stakeholders
Engineering Leadership · Product Leadership · Customer Success Lead
01
  1. Developer bottleneck. Every customer configuration request required engineering.
  2. Content personalization limits. Static event pages couldn’t adapt to attendee characteristics.
  3. Enterprise sales friction. Lack of advanced automation was a specific barrier in evaluations.
02
01

Launch

Self-serve adoption

  • 01 Developer ticket reduction for configuration requests.
  • 02 Customer success teams handling configuration end-to-end.
  • 03 Rules engine adoption rate among existing customers.
  • 04 Configuration resolution time.
02

Strategy

Platform compounding

  • 01 Eng capacity returned to platform work.
  • 02 Enterprise deal velocity.
  • 03 Customer time-to-live on complex events.
  • 04 Differentiation against Cvent and Bizzabo.
03
  • Two distinct automation needs: compliance-driven rules for regulated industries, engagement-optimization rules for marketing teams. One builder had to serve both.
  • Competitive analysis on Cvent and Bizzabo: both offered basic conditional logic; neither had a visual builder occasional users could learn without training.
  • Power users from CS were in the prototype loop early. Their multi-region compliance scenarios drove the depth features.
04

Wireframes-first to validate the interaction model with engineering before investing in high-fidelity. Real-time rule evaluation surfaced as a backend blocker at this stage and got reworked before high-fi started.

FIG Initial wireframe. Used to walk eng through the interaction model and surface BE feasibility questions before high-fi.
FIG Editing-state wireframe. Confirmed the in-place editing model and the trigger-condition-action scaffolding.

High-fidelity builder states. Same surface scales from a flat condition + action (occasional users) to multi-depth nested rules (power users).

FIG Empty state explains the mental model without requiring training. New users land here and start adding rules without setup.
FIG Simple-case builder: one condition, one action, flat. Covers the majority of use, lowest friction.
FIG Multi-depth nested conditions. Hierarchy expressed through indentation and grouping, scales to depth power users actually need.
FIG Fully configured rule for testing. Readable top-down by occasional users, editable top-to-bottom by power users.

REEL Final builder

Production rules engine in motion. Visual builder, real-time evaluation, accessible to CS teams without engineering involvement.

05
01

Visual builder, not code-like editor

Target users are customers and CS. A visual builder was the only form that could serve them. Accepted UI complexity in exchange for a fully self-serve experience.

02

Depth through hierarchy, not tree diagrams

Tree views are accurate but intimidating. Indentation, grouping, and visual hierarchy let occasional users read top-down without confronting a diagrammatic structure.

03

Power-user-informed iteration

Power users from CS were in the prototype loop from day one. Their multi-region compliance and regulated-industry scenarios drove the depth features.

06
  • 85% ↓

    Developer config requests

    During beta. Customers and CS handled the vast majority of logic themselves.

  • Days saved

    Event setup time

    Complex international events. Developer involvement removed from the critical path.

  • Closed

    Enterprise-evaluation blocker

    Advanced automation gap was a specific barrier during enterprise evaluations for global organizations. Resolved.

  • Unblocked

    Platform scalability

    Engineering capacity was the growth ceiling. Self-serve config compounds: eng time returns to platform work, customer time-to-live drops.

  • Two user types

    One builder

    Occasional users (basic show/hide) and power users (multi-region compliance) both served by the same surface.

Deep dive

Curious about the specifics?

Adoption cohorts, revenue pivot data, prototype walkthrough videos, and the internal PRD are available on request during a portfolio review.