Overview

At Inncircles, changing a form meant waiting on a developer. I rebuilt the Form Builder so construction teams could do it themselves.

WhatRedesigned the Form Builder for Inncircles — so construction teams can build and change their own forms, no developer required.
WhyEvery form change meant waiting on a developer. That dependency slowed teams in the field and kept support load high.
My roleDesign lead — research, heuristic audit, interaction design, prototyping.
Team2 Product Designers (me + 1 senior) · 1 PM · 1 Business Analyst
DurationAug 2024 – May 2025

Anticipated Impact

0%
0%

Reduced support dependency

Reduced support dependency

0%
0%

Increased Completion Rate

Increased Completion Rate

0%
0%

Anticipated Lower UI Bug Rate

Anticipated Lower UI Bug Rate

The platform was feature-rich but experience-poor — and forms were the clearest example.

The Inncircles platform was powerful but hard to use — and forms were the sharpest example of the gap. Every team relies on them, yet the builder gave first-timers no hierarchy, no guidance, and no feedback.

What the platform could do
What a first-timer could actually reach
Capable platform, blocked users — and forms were where that gap hurt most.

Goals

Goals

For the people using it
Usable for both first-timers and power users
Handle edge cases without cluttering the base flow
For the business
Self-serve flows — less dependency on support
Rebuilt on a systems-thinking, logic-first foundation

Forms were static, and every change needed a developer.

Every team wants forms tailored to their process — RFIs, inspections, safety checklists. But the legacy builder was static: even a small change needed a developer, stalling teams in the field.

Every team wants forms tailored to their process — RFIs, inspections, safety checklists. But the legacy builder was static: even a small change needed a developer, stalling teams in the field.

Static
Every change went through a developer and a code release.
Dynamic
The team builds and edits it directly — no code, no waiting.

I built a form myself first, and immediately saw why clients were frustrated.

My first step was experiencing the system as a user would. So I tried setting up forms myself using the existing system. It quickly became clear why clients were frustrated:

My first step was experiencing the system as a user would. So I tried setting up forms myself using the existing system. It quickly became clear why clients were frustrated:

Usability Issues

Usability Issues

No hierarchy — one crowded screen
Dev-only toggles up top
Unlabeled toggle wall
Cramped, ungrouped properties
Silent breaks on type change
No mobile preview

The old builder crammed everything onto one screen with zero hierarchy.

What users said

What users said

Usability session
“I have to open multiple dropdowns for options I use daily. It's tiring and repetitive.”
Usability session
“To add one sub-entity I go through so many steps and confirmations — I lose context, and it's exhausting.”
Support ticket
“I tried it on my tablet at the site, but it's not responsive — I have to scroll endlessly.”

First, I studied how the best form tools actually work — and where they break for construction.

I benchmarked leading form tools like Jotform and Typeform and construction-focused platforms like Procore to understand what patterns users had already internalised and where those patterns broke down for construction-specific needs.

Jotform showed me how powerful a drag-and-drop canvas could be when paired with a persistent field library, users never had to hunt for what they needed; everything was visible and accessible in one place.
Typeform, on the other hand, taught me what not to do for this context: its one-question-at-a-time flow works beautifully for consumer surveys, but construction forms are reviewed, referenced, and filled in non-linear ways on-site. A linear wizard would have been the wrong model entirely for our users.
Procore was the most instructive, it showed me that construction professionals are comfortable with complex, data-dense interfaces, but only when the hierarchy is predictable and the labels match their domain language.
Where Procore fell short was in configurability: admins couldn't change field behaviour without engineering support, which was exactly the problem we were solving

BORROWEDJotformThe drag-and-drop canvas + persistent field library — the pattern users already knew. I rebuilt it around construction's field types, not its.
REJECTEDTypeformOne-question-at-a-time wizard — the wrong model for non-linear, on-site work.
ADAPTEDProcoreKept its dense, predictable hierarchy; dropped the rigidity that needed an engineer for every change.

Four patterns kept surfacing, and none of them were about missing features.

Four patterns kept surfacing, and none of them were about missing features.

Built for developers, not construction teams
No safety net — one wrong click could break a field
Ten steps for what should've been a two-minute task
Never tested on the devices people carry on-site

The builder didn't need more features — it needed to be usable by the people in the field.

The real constraints
Non-technical users — construction managers, not developersConstruction's own field types — RFIs, inspections, quantities, signaturesBuilt and used on-site, often on mobileLive edits on real project data — nothing could break existing forms
The pushback

“We can't support unbounded conditional logic with a live preview — at construction scale, re-validating every field on every change is a performance and data-integrity risk.”

— Engineering, in our first build review
How I approached it

So I traded open-ended power for typed guardrails: conditional rules became a fixed set — show / hide, require, set value — scoped to each field type. The preview stayed cheap to compute, the data model stayed predictable, and non-technical users still got real flexibility. The problem was never visual — it was structural.

Solution

Solution

A WYSIWYG builder, not a config form.

My core idea was to shift from a static, developer-focused form definition page to a dynamic, visual, WYSIWYG (what you see is what you get) builder one that gave users full control while guiding them with a clear structure. That landed me on a three-panel layout:

This let users focus on one task at a time without overwhelming them.

My core idea was to shift from a static, developer-focused form definition page to a dynamic, visual, WYSIWYG (what you see is what you get) builder one that gave users full control while guiding them with a clear structure. That landed me on a three-panel layout:

This let users focus on one task at a time without overwhelming them.

Every field type ships with its own rules, not a generic text box.

Form elements contain all the fields library segregated by
Basic, Advanced, Section and Arena Field, which is specific to fields specially used by Inncircles and will grow in future releases.

Form elements contain all the fields library segregated by
Basic, Advanced, Section and Arena Field, which is specific to fields specially used by Inncircles and will grow in future releases.

Alphanumeric, paragraph, or email — with domain rules and character limits.

Settings

Settings

Configuring the form approval workflows, ID settings, themes and the thank you pages

Configuring the form approval workflows, ID settings, themes and the thank you pages

Preview

Preview

Shows how the form will appear in different devices

Shows how the form will appear in different devices

Drag & drop

Dragging fields next to each other in a row

Dragging fields next to each other in a row

Edge Cases Handling

Dragging fields next to each other in a row

Dragging fields next to each other in a row

My learnings & Reflections

01Designing a builder means designing for outputs you'll never see — the job was shaping the space of forms people would make, not one screen.
02Guardrails are what make freedom usable — giving each field type its own rules let non-technical users move fast without breaking things.
03Real-time preview beat any tutorial — seeing the result as you build is what removes the fear that stops non-experts from trying.
My biggest learning

Give people a tool they can trust, and they stop needing you.

Postscript · 2025I built this before AI was part of the workflow. Today it would change the how not the what.
Explore wider, faster
Generate a starting form from a plain-language prompt
Draft conditional logic without hand-speccing each rule
Auto-draft field configs, microcopy, and validation messages
What wouldn't change: the domain research, the systems thinking, and the judgment on what to leave out. AI speeds the making — it doesn't replace the deciding.

Curious to know more?

This is one part of a larger platform revamp — happy to walk through the Construction Setup redesign or the research behind it if you're interested. See more of my work below.

Construction Setup →