Niss BerrySenior Product Designer
← Back to work

Product systems · Builder UX · Mobile preview

Template Builder

Making template setup easier to structure, preview, and use in the field.

Design completed and handed over for development.

The Template Builder supported powerful field workflows, but the experience had started to feel heavy, inconsistent, and harder to shape with confidence. I explored how the builder could become clearer and more structured — simplifying page setup, question patterns, and section logic, while keeping the mobile preview closer to the editing flow.

This work focused on improving the experience of creating and managing scoreable field templates across desktop and mobile. The aim was not to reduce capability, but to make the structure easier to understand, the editing flow easier to follow, and the final mobile form easier for field teams to complete.

These scenarios reflect the product thinking, UX/UI direction, and handover work completed before implementation.

Product area
Template Builder / form configuration
Focus
Information hierarchy, builder UX, mobile alignment
Role
Product design, UX direction
Scope
Desktop builder, mobile form flow, interaction cleanup
Status
Design completed — handed over for development
Hero scenario
A cleaner builder direction that keeps page structure, question editing, and mobile preview closer together.

01 / Context

Context

The builder was powerful, but the structure was doing too much work in one place.

The Template Builder needed to support a lot: pages, sections, questions, scoring, field types, logic, settings, and a live sense of how the final form would behave on mobile.

Each part had a purpose, but together the experience could feel dense. Users needed to understand the setup model, the page structure, the question rows, and the mobile output at the same time.

The product had flexibility. The experience needed more rhythm.

02 / The friction

The friction

The problem was not a lack of capability. It was the amount of structure users had to decode.

As the builder grew, settings and content started competing for attention. The editing experience asked users to make configuration decisions while also managing page structure, question patterns, scoring, and preview behavior.

The mobile preview helped, but it needed to feel more connected to the editing flow instead of sitting as a separate outcome.

Dense setup

Settings, structure, and question editing competed in the same space.

Weak hierarchy

Users had to scan hard to understand what mattered first.

Preview disconnect

Desktop setup and mobile completion needed a clearer relationship.

Repeated patterns

Sections, question rows, and actions needed stronger consistency.

Field pressure

The mobile experience needed to stay lightweight for real field use.

Before
The earlier builder exposed a lot of control upfront, but the hierarchy made the work feel heavier than it needed to be.

03 / Design intent

Design intent

Bring more structure to the builder without stripping away flexibility.

The goal was to make the experience feel calmer and more intentional. That meant improving hierarchy, making repeated patterns more predictable, and helping users understand what they were configuring at a glance.

Rather than treating this as a brand-new product, the direction focused on clarifying the existing system: separating setup from content, tightening repeated controls, and making the mobile preview feel more like a live companion to the builder.

Powerful tools do not need to feel heavy. They need to make the next decision easier.

04 / What changed

What changed

The redesign direction focused on the structure around the work, not just the surface of the screens.

Clearer builder structure

Template settings, page structure, and question content were given clearer separation so users could better understand where each task belonged.

Better desktop-to-mobile alignment

The mobile preview stayed close to the editing flow, making the final field experience easier to validate while building.

More consistent question patterns

Question rows, response types, scoring, logic, and section behavior were treated as repeatable patterns instead of one-off controls.

Simpler field completion

The mobile flow focused on clear page movement, lightweight actions, and field-level support through notes, media, actions, and location capture.

05 / Before / after

From heavier setup to a cleaner working rhythm

The earlier experience exposed a lot of capability at once. The updated direction moved toward a more focused builder, where page structure, question editing, and previewing work together more naturally.

Before
Broader configuration with heavier visual load.
After
Cleaner structure with stronger editing focus.

06 / Process notes

Working through the structure on paper first

Because this problem involved structure more than surface polish, sketching helped clarify the system before pushing further into polished UI.

The notes explored page flow, question patterns, response types, section behavior, mobile actions, and how recurring elements should behave more consistently.

Thinking artefact
Mapping the builder structure, question rows, response types, and dependencies before tightening the UI.
Thinking artefact
Exploring the mobile flow, field patterns, modals, bottom actions, and the decisions needed to keep the experience predictable.

07 / Mobile flow

Keeping the field experience focused

The mobile flow needed to support real-world completion, not just mirror the builder.

The updated direction kept the interface minimal and task-oriented: move through pages, complete required fields, attach supporting inputs where needed, and keep primary actions obvious.

Mobile flow
A simplified mobile flow showing page movement, field completion, site selection, location support, and a submission-ready state.

The stronger story isn’t every old mobile state — it’s the improved flow: fewer distractions, clearer actions, and a more predictable path through the form.

08 / Outcome

A more usable template-building foundation

The value was not just a cleaner screen. It was a clearer relationship between setup and use.

This exploration moved the Template Builder toward a more structured experience — one that better supports both the person configuring the template and the person completing it in the field.

Even without changing the product’s core purpose, improving hierarchy and flow helped reveal a more coherent path between setup and execution.

Clearer editing hierarchy

Setup, structure, and content sit in their own lanes so the next decision is easier to find.

Stronger mobile preview alignment

The preview stays close to the editing flow, so building and validating happen together.

More predictable field completion

The mobile form keeps actions obvious and movement through pages calm.

09 / Reflection

What I’d keep pushing next

Given more time, I would continue refining how advanced settings are progressively revealed, and how logic and dependencies are explained in-context.

I’d also explore how preview and editing stay connected without crowding the layout, and look at reusable template patterns that could help teams move faster without rebuilding the same structure from scratch.

This is the kind of product work I enjoy most: keeping the power, reducing the noise, and making the path feel easier to trust.