Inncircles - Manjusha | Portfolio 2026

Designed a self-serve form builder that reduced engineering dependency by 45%

Overview

Every construction team relies on forms, from inspections and RFIs to safety checklists. Yet creating or updating one meant filing a request to engineering. As the sole product designer on the initiative, I redesigned Inncircles' Form Builder into a self-serve workspace where teams could build, configure and publish forms independently.

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 roleAs the sole product designer on the initiative, I led product discovery, interaction design, prototyping, usability testing, and engineering collaboration.

Team1 Product Designer • Product Manager • Business Analyst • 4 Developers

DurationAug 2024 – May 2025

Impact

reduction in support dependency

increase in successful form completion

fewer publishing inconsistency tickets

The legacy Form Builder reflected how the system was engineered rather than how construction teams worked. It exposed every configuration upfront, mixed advanced settings with everyday tasks, and offered little feedback while building. The result was a capable product that felt intimidating for first-time users and inefficient for experienced ones.

What the platform could do

What a first-timer could actually reach

Capable platform, blocked users — and forms were where that gap hurt most.

The Problem

No clear hierarchy between editing, configuring and publishing

Generic field configuration didn't reflect construction-specific workflows.

Customers couldn't adapt workflows independently.

Engineering spent time on configuration instead of platform capabilities

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.”

The Reframe

This shifted the problem from:
How do we make configuration easier?

How might we let teams build the form directly, while exposing complex configuration only when it becomes relevant?

This shifted the problem from:
How do we make configuration easier?

How might we let teams build the form directly, while exposing complex configuration only when it becomes relevant?

Defining Success

For users

Build common forms without technical support

Keep frequent actions immediately accessible

Reveal advanced configuration only when needed

Understand the published result before committing changes

For the business/product

Move routine configuration out of engineering

Reduce configuration and publishing-related support requests

Maintain predictable field behaviour as new field types are added

Preserve advanced construction-specific workflows

Exploring the right interaction model

I explored three interaction models, each prioritising a different part of the form-building workflow. I compared them against three constraints:
- learnability for occasional users
- efficiency for repeat users,
- implementation complexity within the existing platform.

Direction 1Stepped workflow

Strength Clear sequence for first-time users. Trade-off Too rigid for iterative form building

Direction 2structure-first workspace

Strength Fast to assemble and reorganise fields. Trade-off Detailed configuration had no natural home.

Direction 3contextual editing

Strength Kept the form visible while editing its behaviour. Trade-off Required careful control of what entered the properties panel.

IReviews with product and engineering narrowed the direction further:
the canvas needed to stay flexible for users, while the underlying behaviour had to remain predictable enough to validate and maintain.

The interaction model: build, see and configure in context

The explorations converged on a three-part workspace: a field library for adding structure, a persistent form canvas for direct manipulation, and contextual properties that appeared only for the selected field.

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.

Persistent library of available field types

Compose

WYSIWYG representation of the actual form

Configure

Contextual controls for the selected field

Cross-functional trade-off - flexibility without unpredictable logic

Early concepts allowed users to create conditional rules between almost any combination of fields. It gave customers significant control, but that flexibility quickly became difficult to reason about at scale.

The real constraints

Engineering flagged the complexity of validating deeply nested rules while maintaining compatibility with existing forms.

At the same time, product needed to support advanced workflows without turning everyday form creation into rule configuration.

How I approached it

I moved from unrestricted logic to field-aware behaviours. Each field exposed only the actions it could reliably support, including Show, Hide, Require and Set Value. This preserved useful workflow flexibility while giving users clearer boundaries and engineering a predictable model to validate and extend.

Getting buy-in

Solution

Make the output the workspace

Before: users configured abstract form definitions.
Decision: make the actual form the central editing surface.
Result: structure, hierarchy and changes remained visible throughout creation.

Reveal complexity only where it applies

Selecting a field surfaced only the properties relevant to that field type, keeping common actions simple without stripping away advanced configuration.

Text, paragraph and email inputs with format and character controls.

Keep advanced workflow configuration outside the base flow

Anything affecting an individual field stayed contextual to the canvas. Form-level behaviours affecting the entire workflow moved into Settings

Let users verify before committing

Preview gave users a direct way to verify layout and device behaviour before publishing, replacing the previous configure-and-check workflow.

Make structural changes directly

Fields could be added and rearranged directly on the canvas, making structural changes immediate rather than another configuration task. Rows were intentionally constrained to a maximum of two fields to preserve field readability across desktop and tablet layouts, rows were limited to two fields. Instead of disabling drag behaviour without explanation, the builder surfaced the constraint at the point of interaction.

Handling Edge Cases

Not every construction workflow fit the standard field pattern. Less common behaviours were handled contextually, so specialised cases remained possible without exposing their complexity to every use

Testing whether self-serve actually worked

The redesign only worked if customers who previously depended on support could complete core configuration tasks independently. I tested the prototype around the highest-risk interactions:

assembling a form,
configuring field-specific properties,
changing structure,
previewing the result
handling advanced rules.

The redesign only worked if customers who previously depended on support could complete core configuration tasks independently. I tested the prototype around the highest-risk interactions:

assembling a form,
configuring field-specific properties,
changing structure,
previewing the result
handling advanced rules.

My learnings & Reflections

01Designing the builder wasn't about making forms easier to create. It was about deciding where flexibility created value and where constraints made the product stronger. The most impactful decisions weren't interaction patterns—they were product decisions that balanced customer autonomy with platform reliability

02Guardrails are what make freedom usable — giving each field type its own rules let non-technical users move fast without breaking things.

03Preview was more effective than adding instructional copy because users could verify the consequence of a configuration change directly

02Guardrails are what make freedom usable — giving each field type its own rules let non-technical users move fast without breaking things.

03Preview was more effective than adding instructional copy because users could verify the consequence of a configuration change directly

How I'd extend the system today

Explore wider, faster

Generate a starting form from a plain-language prompt

Draft conditional logic without hand-speccing each rule

AI could accelerate initial form assembly, but it shouldn't replace the typed rule architecture. A generated form would still need to resolve into the same explicit fields, dependencies and guardrails so users could inspect and control what was created.

Curious to know more?

This is one part of a larger platform revamp. Happy to walk through the details behind it if you're interested. See more of my work below.

NEXT PROJECT

Designed a self-serve form builder that reduced engineering dependency by 45%

Designed a self-serve form builder that reduced engineering dependency by 45%

Overview

Overview

Impact

The Reframe

The Reframe

The Reframe

Defining Success

Defining Success

Defining Success

Exploring the right interaction model

Exploring the right interaction model

The interaction model: build, see and configure in context

The interaction model: build, see and configure in context

Add

Compose

Configure

Cross-functional trade-off - flexibility without unpredictable logic

Solution

Solution

Make the output the workspace

Make the output the workspace

Reveal complexity only where it applies

Reveal complexity only where it applies

Keep advanced workflow configuration outside the base flow

Keep advanced workflow configuration outside the base flow

Keep advanced workflow configuration outside the base flow

Let users verify before committing

Let users verify before committing

Make structural changes directly

Make structural changes directly

Handling Edge Cases

Handling Edge Cases

Testing whether self-serve actually worked

Testing whether self-serve actually worked

My learnings & Reflections

My learnings & Reflections

Curious to know more?

Curious to know more?