In this series I tackle the topic of electronic forms: why we need them, best practices and comparisons on creating, managing, and automating them.

In my last post I reviewed why forms are so important in our day to day activities and hinted at some of the elements of forms that make them more or less valuable to us. As we create such forms we come up with a very common question: how much do I need to stuff into that form to make it the most useful I can for the organization?

As with everything it comes down to balance: you can gain the majority of benefits without having to create a very difficult form, especially if you are coming from un-validated Word forms or e-mail as a way to communicate (e-mail also being a free-form with no validations).

So when thinking about forms, a useful model to consider is what I call the “Form Functionality Value Curve” (FFVC).  The principle is that as complexity of a form increases, its added value to the business also increases, but then peaksand fades – having reached a diminishing rate of value for the creation effort.

A form is any screen that contains data relevant to any process. The data content and its on-screen manipulations (“Form Functionality”) ranges from very simple (free-form text field with no validations, like an e-mail) to complex (data-bound, event-driven, multi-level, validated, and integrated structures – ouch! – like a complex online multi-level Bill of Material creation).

These features have an inherent value. Clearly, a free-form text is less valuable than a field that has some validation in most cases. However , is that database drop-down field with a complex set of validations truly more valuable than one with simplified rules – could you gain 80% of the value while keeping the interface simpler?

A classic example in workflow is user assignments. When a given task is completed the workflow can automatically determine who is next in line for the next task. How this assignment is calculated can be as simple as asking the user who’s next (a simple form control), or as difficult as looking up a cross-functional org chart (advanced integration).

But guess what, if you go with the fully automated method, you are left with dealing with all the exceptions. What if there’s a good reason why a manager should be performing an approval given a special set of circumstances that are not coded in the workflow and you need an override? How do you deal with wrong assignments? This is a case where the full automation isn’t necessarily the best added value in all cases – but it certainly is significantly more complex to build in to the forms and workflow.

So the FFVC is a useful way to remind yourself of where to draw the line to gain value, in particular when you are starting from very little value. The peak of value occurs at simple integrations. This is where for relatively little effort you are able to gain huge security and validation improvements. Value decreases but is still high through more complex integrations and “events” (things that happen when you select certain check-boxes or pick certain options) but it diminishes as you reach truly complex user interface concepts like implementing AJAX.

Before I get torn apart, don’t get me wrong: implementing AJAX is clearly a good thing, it adds value. However relatively speaking, it is usually an incremental value that adds no exponential return on investment for the additional difficulty most people would have to get this concept in place in a form. This is the essence of the FFV Curve.

In my next post I will delve deeper into the elements that make up the form functionality and then start tying them to the “who” and “how” aspects: who can, and should, be involved in creating such forms to gain the optimal benefits – and the best tools to achieve this.