Mind the gap! How UX Forms shrinks the distance between prototype and production
When building a new web form, you won’t find the perfect solution first time. That’s why we always urge our partners to test their ideas with users, so that feedback can be gathered quickly and easily, and any problems solved efficiently.
The best way to collect actionable feedback is to make your ideas real — but that doesn’t mean investing upfront in a fully Production-ready form. You start with a prototype.
However, some webform building tools have made it harder than it should be to move from prototype to production. Indeed, the process often involves two completely separate tools, and negotiating the jump between them means delays, and avoidable costs. In our opinion, you should not have to throw away all the work that goes into building a good prototype when moving to your final, user-facing webform.
Here’s how the team at UX Forms solved this problem.
As a rule during testing, the closer the prototype looks and behaves to the final outcome, the better. That means using a design system.
At the headline level, a design system includes three main elements:
- styles (typography and colours)
- components (question types, tables)
- patterns (common tasks, like entering contact details)
UX Forms understands that UK government departments need to base their services on the Government Digital Service (GDS) design system, and that’s why we implemented it from day one. This means that even at the prototyping stage, all the branding and thinking used to create the GDS design system is present and correct. Adhering to the design system from the start minimises the risk of wasted time and effort, as the system makes it much harder to introduce rogue elements that fail to conform to GDS standards, and would only have to be removed later.
Instead of getting bogged down in code, or trying to introduce styles, the prototype web form design stage becomes a question of creative problem-solving. With all the building blocks already defined, the challenge is how best to order them, to build your service. As with a pile of Lego, your team is free to assemble tried-and-tested pieces into interesting and effective combinations — whilst enabling you to try out bespoke elements and styles where needed.
Mind the gap
Prototyping tools are focused on being quick and cheap to change, whereas production platforms are about being robust. At UX Forms, we started by asking: why production systems couldn’t be every bit as quick and cheap to change as prototyping tools?
As we touched on above, if you’ve decided to use a prototyping framework that doesn’t support GDS’s template language, then you’ll have to start from scratch. That is expensive and time-consuming, and still ends up being thrown away when it comes to building the production-ready version. That’s why we urge our partners to build their prototypes in the same system as the one that will deliver the final outcome.
With UX Forms, whilst we started with GDS’s GOV.UK Elements, our aim was always to ensure that UX Forms remained design system-agnostic. If a design system can be implemented in html, then it can be implemented in UX Forms. That means that over the years we have built up a library of design systems that our customers can use to quickly create an illustrative first cut of a webform. They do so safe in the knowledge that the components have been rigorously tested, will work well and look good, and are compliant with Accessibility standards.
Our approach is perfect for Delivery teams who want to move quickly without having to write and test a lot of code. Instead, they simply pick and mix from a range of pre-existing components, which they can rapidly test with real users. Once they’re ready to convert to the production-ready webform, all they have ahead of them is a small step, not a giant leap.