Case Study: SaaS Form Builder for Website Creation & Maintenance

Role: Senior UX / Product Designer

Product Type: SaaS website management platform

Timeline: ~3 months

Platforms: Web (desktop-first, responsive)

Team: Product Manager, Engineers, QA, Content Strategist

Objective:

Design a scalable form-builder system that empowers non-technical users to create, edit, and maintain forms within their website without developer involvement, while remaining flexible enough for advanced configurations.

The Problem

As the platform evolved, users needed to manage increasingly complex forms within their website. Existing solutions were:

  • Rigid – hardcoded forms that required engineering changes

  • Inconsistent – different content types followed different patterns

  • Error-prone – users struggled with validation, formatting, and dependencies

  • Slow to scale – every new content type increased maintenance cost

This created friction for users and bottlenecks for internal teams.

Goals & Success Criteria

User Goals

  • Create and update form content confidently

  • Understand what fields are required and why

  • Avoid breaking live pages through errors

Business & System Goals

  • Reduce engineering involvement in content changes

  • Support new content types without redesigning the UI

  • Establish a reusable, extensible foundation for future features

Success Metrics

  • Reduced support tickets related to form editing

  • Faster time-to-publish for new form

  • Decreased engineering effort per new field type

Discovery & Research

I partnered closely with Product and Engineering to align on constraints and opportunities.

Inputs

  • Stakeholder interviews (Product, Support, Engineering)

  • Review of existing CMS and form-builder patterns

  • Audit of current content types and edge cases

  • Support ticket analysis to identify user pain points

Key Insights

  • Validation errors were often discovered too late

  • Field logic (required, conditional, reusable) was inconsistent

  • Engineers needed a schema-driven system, not one-off UIs

Design Strategy

Rather than designing individual forms, I focused on designing the system.

Core Principles

  1. Schema-first, UI-second

  2. Progressive disclosure over complexity

  3. Clear mental models for non-technical users

  4. Scalable patterns over custom solutions

How the Form Builder Fits Into the Product

To ensure the form builder integrated cleanly into the existing product, I mapped a user flow that outlined how users access, build, configure, and reuse forms within the platform. The flow helped align product, design, and engineering on entry points, ownership, and dependencies, while ensuring the experience felt cohesive rather than bolted on. This approach clarified where configuration lived, how forms were previewed and saved, and how they ultimately rendered across pages and sections.

Solution: Modular Form Builder System

1. Schema-Driven Architecture

I collaborated with engineering to define a flexible schema that could drive:

  • Field types (text, rich text, media, toggles)

  • Validation rules

  • Conditional logic

  • Default values and helper content

This allowed the UI to adapt dynamically without redesign.

2. Modular Field Components

Each field was treated as a reusable component with:

  • Label + helper text

  • Inline validation

  • Optional advanced settings

  • Consistent spacing and hierarchy

This ensured visual and behavioral consistency across the product.

3. Conditional Logic & Dependencies

To reduce cognitive load:

  • Advanced fields appeared only when relevant

  • Dependencies were explained with tooltips

  • Warnings surfaced before publish, not after

This prevented common user errors while maintaining flexibility.

4. Content Safety & Confidence

To protect live sites, I introduced:

  • Required field indicators with context

  • Inline validation and previews

  • Clear save vs publish states

  • Destructive action confirmations

Users felt more confident making changes independently.

Collaboration & Execution

I worked closely with:

  • Product to prioritize flexibility vs usability

  • Engineering to align UI patterns with technical constraints

  • Content/Support to ensure language was clear and user-friendly

Deliverables included:

  • System diagrams

  • Component specs

  • Interaction states

  • Edge-case documentation

Outcomes & Impact

  • Enabled rapid creation of new content forms without redesign

  • Reduced engineering time spent on form-related changes

  • Improved user confidence and reduced content-related errors

  • Established a foundation used across multiple features

Most importantly, the form builder became a core platform capability, not just a feature.

Reflection

This project reinforced the importance of:

  • Designing systems, not screens

  • Partnering deeply with engineering early

  • Balancing power and simplicity in SaaS tools

If iterated further, I would:

  • Add versioning and rollback for content changes

  • Introduce form analytics to identify drop-off points

  • Expand accessibility testing for complex field types

Note: Visuals shown are simplified recreations due to NDA and do not reflect the final production UI.

Next

View More