Yesterday morning in the LocalGovDigital Slack, somebody asked the question:
'What's the process at your council for building a form? What systems are you using? Do you have any best practice for forms design?'
This enabled me to go off on one on two of my favourite things to go off on one about, that it's long past time I wrote a blog post about!
Form design and Figma
Now to be fair, when it comes to the process of designing forms there isn't actually anything that I really rant about; there's nothing to see here, move along.
Which isn't to say I don't have opinions borne of observation.
The classic modern User Centred Design 'best practice' process would be to mock up a low-fidelity version of the initial design of the form in Figma (other UX design tools are available), test it with users, and iterate, refining the design until you reach a point all agree it's as good as it's going to get, and then sending it off to the person to build the real working version of the form.
Whilst there's nothing inherently wrong with that way of working, especially if it's an agency or consultancy doing the design, and/or the form is then going to be lovingly handcrafted in pure html, php, css, and javascript, when we look at local government and the tools and context we have at our disposal, I find it hard not to just think 'what is point, Figma, what is point?'.
Part of the point of using a tool such as Figma to test and iterate the designs in is because it's a tool for what is often described as non-technical users who can use their design skills to design without being hampered by their programming skills - a designer needs to know which form elements work best how, they need to know the best subtle changes of position, language, font, and font size to instil the least cognitive overload in the user to get the best answers from the user; they don't need to know the difference between an id and a class, and they certainly don't need to know how to create a javascript event handler to programmatically show and hide questions according to the answers to the previous question.
So if the actual form is going to be built by hand in code, it absolutely makes sense for it to be designed and the UX tested in Figma.
But in local government, we're not coding forms, we're building them in a low code form builder, whether that's as part of our main CMS platform such as Jadu or LocalGovDrupal, or a separate forms package such as IEG4 or Granicus. I've not used the latter but I've used the former enough to know that it's easier for a non-technical user to build a form in them than it is to design one in Figma - that's after all point low code CMS, that is point.
The value of creating low-fidelity wireframes of a UX design is, of course, to design and test an overall design and layout, headers, footers, sidebars for secondary content, menu positioning, etc without the subjects getting distracted by non-functional components such as colours, logos, pictures of floofy cats interacting with the product, etc. Notwithstanding, of course, the typical reaction to such wireframes as 'well it's a bit boring, isn't it?' and the circumstances where the colour is the function.
But when all that overarching design work has been done, and is fixed, and is an unchangeable reality, and your form design guidelines are already established in your UX Strategy there's no advantage to be gained by testing out the specific design of your specific new form divorced from the reality of the page chrome. Further, and worse, whilst it's not something I've personally experienced on a requirement passed to me, I've seen cases where a UX designer has presented a developer with a form design in Figma which has aspects of it which were not implementable in the CMS it was expected to be built in, and tension has arisen because of the designer insisting those aspects are included 'because this is the form design which has been tested'; aspects which may or may not have been actually critical for the success of the design. Had the designer iterated the design in the form builder itself and left the developer to do the additional developery bits, everybody would have been happy.
So to sum up just in case there's some ambiguity in my position there - if you're working on designing a completely new design pattern or UX for your client, or the platform the form is going to be built in is as yet undecided or it's going to be hand coded, and you're clear about what parts of what you're testing you're considering optional for implementation and what parts you're expecting to be implemented, then absolutely do your iterative design and test process in Figma before going on to implement the build of the form itself.
But if you're working under the constraint that ultimately the form is going to be built in an easy to use, non-technical, low code form builder CMS platform, then you'll be much better off the iterative designing and test process in the form builder itself.
Best Practice
Now this is the bit that proper triggers me and no mistake.
I've a cookery book in which Antonio Carluccio enigmatically says in the intro
There is no such thing as 'Italian food', there is only good food
Innit, fam.
I'm not going to deconstruct that like the exceptionally good deconstructed lemon meringue pie I once had in a restaurant in Nice many years ago, but the point is, whenever I see or hear the phrase 'best practice', it immediately raises flags for me.
Which isn't to say there aren't clear practices which can be objectively good practices or bad practices, or indeed practices which are so good they can be agreed as best practices - it is clearly agreed that it's best practice in building a form that field labels should be text in close proximity to the field itself marked up with the <label> tag linked to the field by means of the id; it's agreed that it's poor practice to use placeholder text instead of proper labels, and personally I think it's catastrophically bad practice to put captchas on login forms. I mean, why? WHY??!!
But for the most part in areas where somebody is asking 'what is best practice on this?', well, there isn't really an objectively agreed status of best practice, and even where there's user research which shows something as popular, rarely does it show a given direction as being overwhelmingly popular. On the question of whether it is best practice in form design to have the contact details captured at the beginning of the form (to enable the user to get the boring bit out of the way first) or the end of the form (so they can tell us what they've actually come to the form for first), I strongly suspect that user research would show 33% of people preferring beginning, 33% of people preferring end, and 33% of people as never having really given the matter any thought before now actually thanks.
So it's on that basis that I confidently assert that the best practice - both for your form design itself and indeed for the process of designing forms - is consistent practice. Establish through the advice of peers and user research what constitutes good and bad practices. Establish from the design patterns for which no overwhelming evidence for or against them can be found which ones amongst you and your team have a preference for. Document all that in your own form design guidelines - and whatever those guidelines actually say, the best practice is to apply them consistently.