Back

Rethinking Required Fields for a Frictionless App Customization Experience

Editor Workflow

UX

Interaction Design

Back

Rethinking Required Fields for a Frictionless App Customization Experience

Editor Workflow

UX

Interaction Design

Back

Rethinking Required Fields for a Frictionless App Customization Experience

Editor Workflow

UX

Interaction Design

The Problem

In our no-code mobile app builder, users customize app sections ("tiles") through a right-hand properties panel. 

But a system of "Mandatory Properties"—meant to ensure apps met publishing standards—was causing severe friction:

  • Blocking Mandatory Properties: Any required field left empty triggered a panel takeover, forcing users to complete it before any further action.

  • Disruption Mid-Customization: Even minor actions, like clearing a title input and defocusing, triggered the block.

This wasn’t just a bad UX. It delayed app builds, led to confused users, and generated significant support load—directly impacting monetization, since publishing was gated behind completing these required fields.

Two Parallel Approaches

When I started investigating why Mandatory Properties were disrupting the build flow, I didn’t assume we could remove them. So I took two different approaches simultaneously:

Approach 1: Improving Guidance for Completion

The first track assumed Mandatory Properties were here to stay. The goal was to reduce user confusion and make the setup process clearer.

I explored:

  • Indicating how many required fields remained for each tile or screen

  • Visual cues on the tile or in the right panel to point users toward what needed to be filled

  • Triggering a prompt when users attempted to publish without completing required inputs

This path aimed to make the interruptions feel purposeful, not frustrating.

Approach 2: Eliminating Triggers at the Source

The second track questioned whether we could avoid triggering Mandatory Properties.

Redesigning the List View Experience

The biggest culprit for triggering Mandatory Properties was the List View control, used in tiles like product carousels. 

The old flow:

  1. Click "Add Item"

  2. Get a blank placeholder

  3. Manually assign a product or collection

This blank state always triggered Mandatory Properties.
We explored ways to reduce clicks and improve selection.

The breakthrough.

Introducing -> theme autofill logic. 

It automatically pulled live Shopify data into templates.

I proposed reusing this logic at the moment a tile is dropped:

  • Prefill the list with actual products/collections

  • Eliminate the need for users to add items manually.

This removed the most common Mandatory Properties trigger entirely.

Rethinking Mandatory Field Behavior

I analyzed what caused the right panel to become blocked. 

Besides list views, the other key source was text inputs getting emptied.

My solution: if a text input is cleared, retain the last valid value (e.g., revert to "Title") or treat an empty string as intentional. 

This required a logic change at the engineering level, but with support from the CTO, it was approved and implemented.

Eventually, because the autofill logic covered nearly all tiles and the fallback on text fields handled the rest, we were able to phase out Mandatory Properties completely.

The Result

  • Mandatory Properties logic was retired silently—users never noticed it was gone.

  • List View controls became prefilled, eliminating the need for Add Item in fixed-tile use cases.

  • No more panel takeovers—users could focus on editing, not debugging.

While this work was part of a larger redesign, these changes were:

  • Independently impactful

  • Rolled out instantly

  • Required no user education

Impact

  • Removed customization blockers for 50+ tiles

  • Dramatic drop in support tickets related to app setup and publish.

  • Reinforced system-level thinking: instead of nudging users, we changed defaults and logic to do the right thing

This case study is part of a broader redesign project. 

  • Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress

    Portfolio in Progress