Forms: Designing Clarity in Enterprise Configuration
Shipped enterprise UX. How I redesigned a complex form and configuration system using systematic thinking about validation, error states, and user confidence. This ensures users feel guided and in control through complex tasks.
Note: Due to NDA constraints, this case study focuses on problem framing, decision-making, and system design rather than UI artefacts.
TL;DR
What I did
- Redesigned the API Mapper through deep technical collaboration with engineers
- Simplified high-risk workflows where silent failures were common
- Challenged inherited patterns that no longer scaled with product usage
- Led UX improvements across a complex enterprise configuration system
- Owned design quality through implementation and post-MVP iteration
Key impact
- Replaced silent failures with clear validation and error feedback
- Reduced cognitive load across form and node configuration
- Made complex builders easier to reason about and test
- Improved trust and confidence for both users and internal teams
Core skills demonstrated
- Enterprise UX, Systems thinking, Technical collaboration, Design for failure, Prioritisation, End-to-end ownership
Role & Responsibilities
- Sole designer on the project
- Enterprise UX and systems thinking
- Technical collaboration
- End-to-end ownership
The original brief was limited to visual modernisation. I identified deeper UX failures during my audit and advocated to expand scope, turning a cosmetic refresh into a meaningful experience improvement.
Project Goal
Restore clarity, predictability, and trust across a complex configuration system, while working within real technical and delivery constraints.
Overview
Forms was one of our legacy products. Functional, but visually and experientially out of step with the rest of our platform. While newer products like Omni and AI Quality had evolved with our design system, Forms had not been touched in years. It looked like it belonged to a different company.
The brief was straightforward: modernise the UI to match our current design language. But as I audited the product, I found deeper problems. The UX was failing users in ways that went far beyond visual polish. Configuration workflows were confusing, validation was invisible, and even our own QA and engineering teams struggled to understand how the system behaved.
I advocated to expand the scope beyond a visual refresh and shift the roadmap. If we were going to touch Forms, we should fix the underlying experience problems that were causing support overhead, slowing down implementations, and undermining confidence in the product. Leadership agreed to prioritise these foundational issues over purely cosmetic updates.
Users could build advanced configurations, but small mistakes frequently led to silent failures that only surfaced much later when something downstream broke. My role was not to redesign individual screens in isolation. It was to restore clarity, predictability, and trust across a complex configuration system, while working within real technical and organisational constraints.
The problem: invisible rules and silent failure
Forms did not fail because users lacked skill. It failed because the system assumed too much implicit knowledge.
Across the platform, users were expected to mentally simulate backend behaviour. Validation often happened too late or not at all. UI elements sometimes looked editable when they weren't, or behaved inconsistently across builders. Success states visually implied correctness even when configurations were incomplete or invalid.
This created real risk. Users could unknowingly build broken configurations that silently failed and disrupted workflows downstream. Even internal teams struggled to debug issues without inspecting backend logs.
This wasn't a traditional usability issue. It was a system legibility problem.
My thinking lens: making the implicit explicit
As I dug deeper, a consistent pattern emerged. The most painful issues were not caused by missing features, but by invisible rules.
I began using a simple diagnostic lens across Forms:
- •Invisible validation: the system enforced rules but surfaced them too late, or not at all
- •Invisible affordances: elements looked interactive but weren't, or vice versa
- •Invisible state: the system was doing something, but users couldn't see what or why
My goal was not to add more UI. It was to externalise system behaviour so users could understand what was happening, when it was happening, and what to do next.
This lens shaped every design decision that followed.
The breaking point: API Mapper
The API Mapper was the most complex and fragile part of the platform, and where my UX skills were tested the most.
It supported POST, GET, and PATCH requests, dynamic variables, mapped paths, and response handling. From a technical standpoint, it was powerful. From a UX standpoint, it was opaque.
Failures often occurred silently. A configuration could be saved successfully, yet still be invalid. Users only discovered problems later, when the mapped API failed during form submission or testing.
Before redesigning anything, I partnered closely with engineers to understand:
- •How different request types actually behaved
- •Where validation happened, and where it didn't
- •Why some failures could not be surfaced automatically
- •Which constraints were caused by legacy backend architecture
Only after understanding the system end-to-end did I begin redesigning the experience.
Micro-decision: separating "Saved" from "Valid"
One small but critical issue exposed a deeper UX problem.
Before
The API Mapper displayed a single green success indicator after saving a configuration. Users interpreted this as "this will work," even when the endpoint URL was invalid or incomplete. In reality, "saved" only meant the configuration was stored, not that it was usable.
The problem
Green success states created false confidence. Users believed the system had validated their setup when it hadn't.
The constraint
True validation would have required making live API calls, which wasn't always feasible due to authentication complexity, rate limiting, and environment differences.
The solution
I split the state into two distinct concepts:
- •Saved (neutral): your configuration is stored
- •Validated (positive): your configuration meets known structural and formatting requirements
Where full validation wasn't possible, the UI made that limitation explicit, with inline explanations of what "validated" did and did not guarantee.
This prevented false confidence and shifted discovery of issues from late-stage testing to the point of configuration.
This pattern, making system guarantees explicit, became foundational across Forms.
Previous approach
After redesign
Applying the lens across Forms
Form Builder: scaling page management
As forms grew larger, inherited horizontal page tabs broke down:
- •Only a few pages were visible at a time
- •Renaming, reordering, or deleting pages was hard to reason about
- •Users had to remember structure that wasn't visible
I challenged carrying this pattern forward during the redesign, even though it existed in the previous UI.
The invisible rule was clear: "page structure exists, but you must hold it in your head."
I redesigned page management to prioritise visibility and manipulation over continuity with legacy patterns. Page structure became visible as a vertical sidebar where users could see all pages at once, drag-and-drop to reorder, and edit pages. This is especially useful for multi-page enterprise forms.
Previous approach: Horizontal tabs in top bar
Pages become increasingly hidden as the list grows
Improved approach: Page list in sidebar
All pages visible and directly manipulable
Configuration panels: form nodes
I also redesigned configuration panels for form nodes such as text inputs, dropdowns, date/time fields, multi-selects, media, navigation, and links.
Previously, settings were dense, inconsistently grouped, and often mismatched user intent. I restructured these panels to:
- •Reflect how users think about configuration, not how the system stores it
- •Use progressive disclosure to reduce cognitive load
- •Make dependencies and constraints visible at the point of interaction
This significantly improved testability and reduced misconfiguration, especially for complex forms.
PDF Builder: affordances and predictability
In the PDF Builder, several elements looked interactive but weren't. Page reordering felt unpredictable, and actions lacked clear feedback.
Here again, the issue wasn't missing functionality. It was mismatched affordances.
I clarified what was actionable, what wasn't, and when changes took effect. Interactions became more predictable, and users no longer had to "try things" to understand behaviour.
Collaboration and constraints
This work required deep collaboration across disciplines:
- •Engineering: to understand backend behaviour and feasibility
- •Product owners: to prioritise risk and user impact
- •QA: to ensure failures were observable and testable
Design work was paced ahead of implementation so flows were reviewed, validated, and ready for development and testing when the sprint began.
For complex interactions and edge cases, I created interactive prototypes to demonstrate behaviour, state changes, and transitions where static specs weren't sufficient.
Not everything could be redesigned perfectly. Some improvements would have required major backend rewrites, and we made conscious trade-offs where the cost outweighed the benefit.
- •Making limitations explicit
- •Preventing user harm
- •Reducing confusion and downstream breakage
Designing within constraints wasn't a compromise. It was part of the responsibility.
Outcomes and impact
The redesign shipped and remains in production today. While I do not have access to formal metrics, the impact was evident in measurable shifts in team behaviour and product reliability:
- •Reduced configuration friction. Problems that had been recurring through every release cycle disappeared once validation became visible and inline. QA stopped flagging the same issues, freeing them to focus on higher-value testing.
- •Faster implementation velocity. With clearer affordances and real-time feedback, implementation teams completed client setups faster. Configuration no longer required tribal knowledge or guesswork, reducing onboarding time for new team members.
- •Eliminated post-launch support burden. I received no subsequent requests to fix issues with the redesigned workflows. Support escalations dropped, signaling that the changes were holding under real-world use.
- •Increased internal confidence and adoption. Developers, QA, and stakeholders all responded positively. The product finally felt like it belonged in the same ecosystem as our flagship tools, improving perception internally and with clients.
Forms has since been deprioritised as a product, but the design work remains in use. Solid UX decisions outlast shifting business priorities.
Key takeaways
- •Enterprise UX is about designing for failure, not just happy paths
- •In complex systems, the biggest UX risk is invisible rules
- •Systems scale better when they explain themselves
- •Strong design requires interrogating technical decisions, not accepting them blindly
- •Less UI, used deliberately, often creates more clarity than more UI
This isn't just about better UI. It's about better systems, judgment, and collaboration, not just screens.