The Truth About CMS Form Builders

Episerver recently re-did their form building tool. It’s really quite good now. The old one was a mess (they’d be the first to admit that), but the latest incarnation is as well-built as anything I’ve seen. It works as well as some dedicated form building apps.

But it’s still not magic. And when it comes to form builders in general, I don’t think a lot of people realize this. The best CMS form builders in the world still have shortcomings, and we generally expect too much from them.

• We expect we’ll use them more than we actually do

• We expect they’ll be easier to use than they actually are

• We expect they’ll give us more power than they actually do

Form building in CMS is like personalization: it’s a thing people say they want, but also a thing for which they vastly overestimate their need.

Whenever we do pitches and form building comes up, I always feel like I need to make a few points. However, it never fails to seem like a third-rail – “don’t you dare call into question our need for a form-building tool!” And, invariably, it fades away into other concerns, so I never get to mount a significant case around it.

So, here then, is a (too) long sermon on all the things I want to say about form building whenever a client states a need for it or begins to evaluate it alongside other features.

You will not use a form builder nearly as much as you think

One major reason editors want form builders because, at some level, forms embody their dependence on developers. On a day-to-day basis, CMSs have liberated editors from having to call a developer for almost everything. Almost. Form building promises to resolve that Last Mile .

Some editors have horror stories about the last time they had to get a form built, and they’re seeking to avoid that. They have memories of bottlenecks, delayed projects, and the feeling that “I can do everything I need except that one, single thing…” This might be true, but when you really press someone on how often they think they’ll need to build a form – or how often they’ve built them in the past – the truth usually comes out: not often.

I was just sitting with a prospect the other day who made the traditional case that they need to be able to build forms whenever they wanted with no help from their IT staff. I pressed her on how often she thought she would do this. There was a long pause, then:

Maybe once a year. If even that.

It sounds harsh, but there’s a collective delusion among editors that they’ll be slinging new web forms around all the time. Going back to my earlier point, I think this is because the lack of this capability has stuck in their heads – it’s a much more prominent memory than anything else because the problem was so glaring. What they lose here is the context of how often the problem comes up. Yes, the lack of form building might have been a Big Problem, but if it was only a Big Problem once in the last three years, is it really a Big Problem?

After your website launched, how many forms did you need built in the following year? For most of my clients, the answer is “not many.” How many forms will you need built in the next year? It’s usually the same answer.

Some content management environments exist where the need to create and edit new forms comes up all the time – intranets, in particular, are an outlier. And, yes, some companies are releasing multiple marketing campaigns every quarter with individual landing pages and conversion forms. But are you one of them?

Most websites have a handful of forms, they change rarely, and new form requests are not common.

Building a usable form is harder than you think

Content consumption falls into patterns. We mostly read a passage of text in pretty much the same way, or watch a video the same way. There is room for design and interpretation, but not many editors can screw up a series of paragraphs running down a page. There just aren’t a huge amount of variables, and most of them can be controlled.

But it’s really easy to make a crappy form.

Let’s think about all the things you have to account for when making a form:

• Does the idea of the form make sense? Does the user even know what it’s for?

• Is there adequate introductory text?

• Is each form field labeled correctly?

• Are the form fields grouped logically, so that related information is together? Are these sections labeled correctly?

• Does the form “flow” well? When the user scans it, is it going to make sense? Will they have some global concept of the data you’re looking for?

• Does the form make people want to fill it out? There’s undoubtedly an inverse correlation between the number of fields and response rates. Are you asking for things you don’t really need?

• Are the individual form elements correct? Are you using a date picker for dates? Should you be? (In many cases, this is absolutely the wrong choice.) Are you using free-form text when you should be using a dropdown?

• Do individual fields have help text where necessary?

• Is the form validated correctly?

• Does the validation text make sense? Do the field-level errors tell the user how to fix the problem?

• Is there a global error notice, so that if the field error is below the fold, the user knows there was a problem that needs to be fixed?

• Do the buttons make sense? You didn’t include a “Reset” button, did you? And should your submit button say “Submit,” “Send,” “Purchase,”, etc?

• Does the confirmation page make sense? Does it tell the user what they need to know about the data they just submitted?

Clearly, that’s a lot of stuff. Every form is a massive decision tree – every decision leads to multiple other decisions, and the number of results is exponentially large. Give two editors the same data profile, and there’s a chance the two resulting forms will be hardly recognizable from each other.

Forms are acute usability and design problems. There are entire books written on how to design forms well. Tiny changes in design can have huge effects on the number and quality of submissions.

Giving editors the power to build forms whenever they want might just result in a lot of really bad forms. Some extra time spent having a form designed, prototyped, and tested might be exactly the thing you need.

Form builders only give you “freedom” in a narrow range of use cases

There’s often confusion between simple form building and application development. Editors claim they want the former, but they’re often dreaming of the latter.

The core use case for a form building is this: a visitor submits a form, and that data is emailed to someone, or stored in the CMS for later retrieval. Full stop. For many CMS form builders, this is the only use case that gives editors the freedom to do what they want, and even then it has to be qualified in numerous ways.

There are three potential integration points for a form:

1. When the form is rendered.

2. When the form is validated.

3. When the form is submitted.

Each of these points might need interaction with the server. And in each case, those interactions often need to be developed and cannot be done by an editor.

Let’s consider a completely realistic use case:

• When your form is rendered, one of the dropdowns needs to pull a list of products from your database.

• A submitted date needs to be compared to a list of valid dates for a particular event.

• Assuming the data is valid, the submitted result needs to be entered in your CRM system, an email sent with data drawn from outside the CMS (e.g. – extra information for this visitor from your customer database), and the result needs to be archived in your records management system for compliance.

Any one of these requirements is going to need development. Some form building engines have options to handle these situations, but I give long odds that a single system is going to give you all the options you need. Integrating with external data and systems is especially difficult because data is so naturally variant that there’s just no way to account for everything.

Even form layout can require programming or at least something like it. Many editors want some fields to be conditional – Field Z appears only if the visitor picked Option Y on Field X. Other editors want the ability to create multi-part forms, which is extremely rare (Episerver’s new engine does it, which is commendable). The combination is even worse – some editors think it should be simple to have a multi-part form in which entire sections are conditional and there’s branching and looping logic (so the same section can be filled out multiple times).

That is not a web form. That is a web application. There are so many logical avenues to go down that it’s just not reasonable to be able to roll these all up into a simple interface than an editor can use.

Assuming you did get it rendered how you like, form submission actions can be deceptively vexing. Form engines generally offer three options:

1. Email the results

2. Store the result in the CMS

3. Post the result to a URL, or trigger a webhook, or something similar

You can usually do any combination of the three.

In many cases, emailing the result is fine, but it some cases it’s absolutely not. There might be security concerns (secure email is rare), and there’s the persistent problem that just throwing another email at someone’s inbox is rarely an efficient way to get something done.

Storing the result in the CMS is handy, but again, there can be security concerns because you might have private data on a server which is often publicly available. Additionally, in many cases, the person who has to deal with the data is not an editor – they occupy some other role in the organization. To access the data, they have to have access to the CMS and have to be aware that something was submitted (there’s the email thing again).

Often, you need a record created in some other system. The last option accounts for this, but it’s a rabbit hole of integration. Vendors will say, “with webhook/POST, you can effectively do anything!” Yes, but you have to have a developer code the second half of it for you.

Sure, you can post that form to any URL endpoint that you like, but what’s waiting on the other side? Someone probably has to code that.

And if you suddenly don’t like the way the form works and want to add or change a field…did you just break the endpoint? Whatever gets developed is expecting data in a certain format. If you adjust the form (using the “freedom” a form builder grants you), you might have invalidated all the development.

You effectively now have a web application in two parts – the form is controlled by the editor, and the endpoint is controlled by the developer. If I was that developer, the first thing I’d do is change the permissions on the form so that no one could modify it. Ironically, now you’re worse off – you’re depending on a developer who has to “code” half of their application inside a CMS.

For most purposes, form builders are closed systems. If they’re built into a CMS, they can freely interact only with that CMS without usually requiring additional development. They can refer to content, they can store results in the CMS, and they can usually send an email. That’s about it. When a form needs to reach outside the CMS to do anything, then you’re right back to needing the development work that you sought to avoid in the first place.

The most usable form builders generate very generic, derivative forms

I’ve enjoyed working with the Drupal Webform module. I deployed it for my church and I’ve developed several forms with it over the years. It works well, and here’s why: the forms it generates are extremely similar, boring, and predictable.

Remember when I said that designing a form is harder than you think? The best way to reduce this complexity is to drastically limit a form designer’s options. The form builders that editors seem to get the most use out of, it seems, are the ones that force them into very narrow channels of UI design.

Sadly, these are also the form builders editors don’t want. Editors often crave complete freedom when building forms. It’s almost like they want every form to be a masterpiece of interpretive art, and they resent any attempt to limit their options.

But boring forms work. The Principle of Least Astonishment tells us that users prefer to be able to predict what is going to happen in an interface. Forms that lack visual complexity are inviting, and a series of form fields that work pretty much the same way gives users a sense of comfort. If a user fills out more than one field on your site, having those fields look and work similarly provides cohesion. These are good things.

Forms are complicated enough. The way to make them worse is to allow every editor to run wild with all the possible variables they can use. Forms can be styled through CSS to be clear, concise, and usable, but only if the core markup is predictable and, yes, boring. More options mean more complication in the interface, more chances for something to go wrong, and less consistency between forms.

When it comes to forms, you need to be willing to stay boring. Your users will thank you and your form builder has a better chance of keeping you happy.

A truly integrated form builder will balloon your design budget

If you have a single form on your website, that form can be specifically designed. Your stylesheet can have rules to style the elements on that form so it looks good. However, if editors can design any form using any number of elements in any combination, that opens up a black hole of design problems that need to be preemptively solved in the abstract so the site can be ready for anything.

Refer above to the complexity of designing a form, and know that all that stuff has to be styled too. As a designer, if I know you can drop any type of form anywhere, I need to examine each form element in isolation and come up with styles for it. I have to design and style field elements, field labels, section labels, field validation text, global error text, help text, submit buttons, etc. I have to make sure that any design puzzle you drop on a page looks cohesive and well put together.

Of course, you don’t actually have to do this, and most implementations don’t. In most cases, they have a representative form or two on the wireframes, and these are specifically styled. Other forms just kind of make do. But then you get two cascading problems:

1. Some forms look terrible. If an editor uses odd elements or some off configuration that no one planned for, you get an awkward-looking form, in among an otherwise nicely designed site, which means…

2. …credibility suffers, along with response rates. Awkward forms make people uneasy, and if something sticks out like a sore thumb, you lose any goodwill and implied credibility from your design.

What usually happens is that the form builder gets used sometime after launch, and the result is unique or uses some construct that other forms haven’t used (remember all the variables at play). It comes out looking…wrong. So the dream of an editor being able to create a form with no help comes tumbling down when everything has to stop so a designer can debug what’s missing, a front-end developer can code the correct CSS, and dev ops can deploy the changes.

Designing an all-encompassing, flexible “palette” of form elements is a lot of work. It requires thought, talent, testing, and some speculation of what you might want to do with it. This is expensive. And given my prior point about how much less you’ll use a form builder than you think, the payoff here is low.

Consider this: if all permutations of a form builder were accounted and designed for so that there was no way an editor could build an ugly, awkward form, that portion of the design budget would likely dwarf everything else.

Relatively speaking, vendors don’t put a huge amount of effort into form builders

Truth: in most cases, CMS vendors don’t love form builders. They have to include them because other vendors have them, but they’re largely uninterested in doing them well. They do them only to the extent that they have to.

Expect form building demos to be very limited and very controlled. When a vendor shows you a form builder, understand that this is dressed up and staged like it’s a wedding day – the form builder is likely never going to work that well ever again.

The lack of emphasis here is not unfounded. A content-based website is going to push content out much more often than it takes content in, so a concentration on output functionality is appropriate. Additionally, form building is rarely ever the main selection criteria, it’s usually just somewhere down the list. And even the best form builder in the world can’t make up for terrible performance everywhere else unless form building was the only thing the website needed to do.

(And it’s not just the vendors. Integrators usually hate the result too. I had a terrible experience last year with Sitecore’s much-vaunted “Web Forms for Marketers.” It was a disaster. Several Sitecore integrators told me, “Yeah, it sucks, don’t use it.” Even better: there’s a YouTube video about WFFM called “Welcome to a World of Pain” with a slide which refers to the product as “Fucking Webforms for Fucking Marketers.” In the end, form builders basically make everyone unhappy.)

Another caveat: be careful that vendors aren’t letting development creep into discussions through the back door. You might ask, “Hey, can this form builder automatically create records in my custom CRM system?,” to which the vendor answers “Yes!” Left unsaid was “…because it can post the form contents to any URL, so you can have a developer build a custom integration on the other side of that.” Technically the form build can do that, but it’s probably not what you really want.

Closing Thoughts and Potential Solutions

Let’s a take a breath for a second…

This post sounds really negative, and I’m sorry for that. I don’t mean to condemn all CMS form builders. There are some very good ones. But I will say this, conclusively –

In my almost 20 years of doing this, no form builder has completely lived up to my client’s expectations. All of them have disappointed the users to some extent. The most valuable thing I can do as an integrator is to simply manage (read: lower) their expectations.

So, what are the solutions here? If you’re staring down a CMS purchase, what do you about form building?

Some ideas:

• Take an honest assessment of the frequency of your need. After initial launch, how often are you going to want to build a form? For most organizations, this is a big problem in isolation, made much smaller by the comparatively few times it comes up. You might be putting far too much emphasis on it.

• How often do you expect that your form’s functionality will be wholly contained in the narrow range of options I’ve outlined above? As I said before, you likely need to lower your expectations of what’s achievable. Assume that all you can do without development support is simple data capture.

• Understand that if your expectations are to integrate your forms with a wide variety of other systems, then you’re not going to get the freedom from development that you’re looking for, and having the form portion of these integration scenarios under editorial control will rarely ever be helpful.

• Accept that derivative, consistent, boring forms are a good thing. Understand that trading creativity for simplicity and usability is probably in your best interest when it comes to form builders.

• Take a vendor’s claims with a grain of salt. If you’re depending on a certain level of functionality, then pin them to the wall on the actual need for development. Demand an open demo sandbox where you can test whatever you like.

• Maybe just accept that form functionality will require development, and seek to find ways to make that easier and faster. Forge alliances and expectations with your IT department or your integrator about how often you’re going to need forms and how quickly you’ll need them deployed.

• Consider integrating with an external form vendor, like Wufoo. Several non-CMS vendors offer nice form builders that can be embedded. All the same above caveats apply, but at least form building is all the vendor does.

• Understand that a form doesn’t just have to be built, it has to work well and produce the results you want. This is a combination of the design, usability, and post-submission handling. Perhaps the right answer is to consider each form to be a small project worthy of deeper consideration and investment than a simple editorial task. Maybe more work and attention is exactly what your forms need.

Form building is a consistent source of problems and frustrations in every CMS implementation. These mostly seem to source from unrealistic expectations and an inability for prospective CMS customers to put the feature in the correct context and line it up accurately next to other features.

You need to step back and take a long view of your need, the feature, and what you actually might achieve with it in the real world. Some honest answers and reflection will likely lead you different conclusions than you first expected.