Igors worked on

Guiding people in making forms

A tool that lets non-designers build well-structured forms — so employees get the help they came for.

Year
Role
Research
Stakeholder interviews, front-line collaboration, information architecture study.
Synthesis
Sensemaking workshops, conceptual model, journey mapping, scenarios
Prototyping
UI design, integration prototype.
Evaluation & validation
Product analytics, usability testing.
Follow-through
Product & design strategy, product roadmap, development cycle coupling.

Problem

Good forms are notoriously tricky to get right — and in a large organisation, the people making them are not designers.

Form quality decides two things at once: whether employees find the right form and get the help they came for, and how much work each request creates for the agents behind it. At global scale, support can be one of the largest budget items — and a form that can't be found or understood becomes emails, calls and rounds of clarification, the slow and expensive kind of support.

Who we designed for

Woman working
Photo by Brooke Cagle

Support1 agent, form creator

Are responsible for creating, sustaining and improving a particular process, as well as, being responsible for the outcomes of the process. They need a way to manage incoming requests.

People working
Photo by Amy Hirschi

Employee, end‑user of the form

Has a task and needs support in achieving it. Can be a person or a group's representative. In order to get support, they need to find the right way to get it.

Approach

Strategic reframe: from data collection to user assistance

The application the builder is part of is only a phase in the more general journey people in the company embark on when they need support with something. Acknowledgement of this by the team was important for a better understanding of where our users come from and what happens after they fill out their forms.

Form builder within the broader context
Overview of the end-user journey and form builder's place within it.

The journey mapping also gave us clarity and alignment on goals, expectations, and dependencies. Stakeholder interviews broadened that picture and surfaced concerns we hadn't anticipated.

Seeing the builder as one step in the journey changed what we expected of it. A tool that only collected fields would leave form quality to people who are not designers, and the journey showed where that cost them: in forms nobody could find and questions nobody could answer. So the builder had to carry the craft itself, and we did that by dividing the work between the creator and the tool. The creator is asked only what they know best: what people will search for, and what answer a question expects. The tool takes care of what can be standardised, such as picking the right input, and brings in explanations, examples and defaults only when a question calls for them. And where a choice, such as setting a default, comes with a risk, the tool says so.

What the creator is asked

Creators are prompted with "What will users search for?" instead of "Name your form", so they describe the form in the words of the people who will look for it. Finding the right form was one of the biggest pain points of the previous incarnation of the app, and it is the creator who decides whether a form can be found.

The job of defining the topic of the form is divided between its title and the combination of tags. There are two parts to the form's definition: the immediate "topic" at hand and the broader "subject" space within which the process takes place. E.g. in "new user in HR system" the "new user" will be a topic and the "HR system" – its context that distinguishes it from other forms dedicated to the creation of users. It was important to build our search to understand different combinations between the two.2

The taxonomy also had to hold up across a large enterprise organisation spanning countries and business units: the same process named differently by region, the same word carrying different meanings between departments. Search had to absorb that variance rather than impose one canonical vocabulary on everyone.

Form setup: a topic field, then tags for the form's broader context
Question configuration UI

What the tool decides

Inputs are named after the answer they collect, not the widget that collects it: Input field becomes Text, Checkbox becomes Yes/No, Date picker becomes Date. Whether choices render as radio buttons, checkboxes or a dropdown is the system's call, based on the number of options and other context.

The rest of a question's setup is disclosed progressively. Explanations, examples and defaults are offered as further steps, not up front, so the creator sees them only when a question needs them. Simple questions stay simple to set up, and harder ones get their extra settings without burying the basics.

Where the tool warns

Pre-selecting the most frequent answer speeds a form up — but people tend to stick with whatever's already selected, which can nudge them down a certain path. The builder lets creators set defaults and cautions them about the risk at the same time. This is how most of the guidance in the builder works: creators can still make the riskier choice, and the tool counsels.

Question configuration UI
Selecting the block type.
Question configuration UI
Form element names follow the expected input, not the widget they render with.
Question configuration UI
When one answer is known to be the most frequently selected, it can be made the default.
Question configuration UI
Adding an explanation.
Question configuration UI
Questions differ in complexity. Some answer themselves. Others benefit from examples, descriptions and nudges.

Impact

for support agents

The new interface improved the overall experience: usability testing and product analytics both confirmed better usability and higher satisfaction than the previous version.

for the rest of the employees

Most users found the appropriate form on their first try. Faster completion and fewer mistakes showed the resulting forms were easier to understand and fill out.