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.
So the builder had to do more than collect fields. It had to bake form-design craft into the tool itself, keep creators thinking in their users' terms, and give the organisation shared means of categorisation — a company-wide vocabulary for all the things and concepts it contains, which is what makes forms findable in the first place.
Who we designed for
Support1 agent, formcreator
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.
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 of which the builder is a 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.
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.
Ensuring discoverability
Finding the right form was one of the biggest pain points for the previous reincarnation of the app and our goal was to make it easier to do. To achieve this we needed to make sure our users name and organize their forms in a way that their respective users can relate to.
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.
Making forms automatically well-designed
When non-designers create forms, there's an opportunity to guide them towards clearer labels, better help text, and more useful error messages through progressive disclosure with embedded best practices.
Simple forms stay simple. Complex forms reveal options progressively. Every component automatically includes proper labels, clear help text, and user-friendly validation.
Roadmap planning
I participated in the product roadmap planning cycle by highlighting user needs and the state of the team’s current response to those needs: gaps, opportunities, and blindspots. Helped team members frame their work around the problems that need to be solved rather than the specific features they want to build.
Kano modelling was used for prioritisation of new features. Being limited in resources, our focus was on serving our users' basic expectations, to make sure there’s nothing they’re missing.
Key decisions
Ask what users will search for
Creators are prompted with "What will users search for?" instead of "Name your form". The ambition was to change how the person building the form thinks — designing the conditions for good forms one level up from the form itself.
Name inputs by the answer, not the widget
Not what the user will see, but what you expect from them in return: 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.
Defaults, with a warning
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 in the same breath.
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.