Three steps to awesome form design
By Clinton Jones on Dec 6, 2011
Two recent articles that I read, Jakob Nielsen’sand John Brinkman’s got me to thinking that it was probably time to revisit this very topical subject. In the world of SAP, it comes as no surprise that people want to retain the rich functionality of the ERP system but get away with doing less in terms of data entry or at very least spend less time entering data.
Technologists will conjure up an infinite number of ways for you to achieve your business objectives and the web, mobile or form enablement of some of the entry and extract methods people want to use to get to their SAP data seems to be a very obvious desire and choice. I’d assert that this isn’t s true situation. Web enabling a process is not necessarily a way to save time or effort in the entry of data in particular. In fact, sometimes, web enabling something actually hinders the process.
As Nielsen says: “Forms are rarely the best metaphor for complex interactions with computers”. In addition he goes on to say, that any online form that goes beyond two screens is often a sign that the underlying functionality is better supported by an application offering more interactivity. If you look at the suite of products offered by Winshuttle, that means going back to a Runner for Transaction or Query.
Brinkman describes how Adobe forms technology has facilitated the creation of behemoth applications in forms that have become uncontrollable monsters with tens of thousands of lines of java script, they are large, open slowly, perform poorly and have a big memory footprint with high maintenance costs and they break, regularly.
Admittedly, the creation of the monster forms is not something anyone sets out to deliberately do, however there is a degree of inevitability about why these monster forms become the end result and a lot of it has to do with understanding what the form’s objectives are.
Failure to think carefully about your candidates for forms and how they are designed can lead to a number of negative business outcomes including maintenance, efficiency, version control, quality assurance and the general integrity of the business process automation. Because Adobe forms support the creation of full blown applications in a form creating monsters is relatively easy, maintaining them though can be an ongoing headache. Brinkman is not against the use of Java code in Adobe forms, in fact I would say he rather promotes it but I wonder whether this is really what you should be doing if you want to simply automate your SAP transaction screens.
With any form, you want to do the following things:
- Distribution : Make sure as many relevant people as possible can use your form
- Rules: Be able to do some basic checking and validation of your data before you try to send it to SAP
- Usability : Provide the user with a great experience
A form works well when its objective is clearly defined and understood and the expectations for data entry are clear and unambiguous – essentially, it will work well as a solution when there is not much more to it than plain data entry. Always check that your form creation is meeting those basic requirements of usability, being distributable and adhering to business rules.
A selection of entry fields, a handful of drop down lists, perhaps some checkboxes and perhaps a table of data fields. You could build some basic logic into the form such as matching data or dependent choices but you really don’t want this thing to get too complicated. As Nielsen says, “Interactions that are more complicated suffer when you present them as straight forms. ”
Most of us would have filled out a federal or state or governmental form at some time and many of us might have been amused by the suggested times it would take to complete the form. You often see this on forms in the US, perhaps less so in other parts of the world. People generally hate filling out any kind of form but then they mostly hate SAP screens too, so we essentially start from a negative position.
From a design perspective, Richard Wootton and Chris Coyier provide some interesting ideas on form design artifacts in their articles on DNNCreative and CSS-Tricks.combut I want to continue exploring some of the criteria you need to consider before you set your heart on turning that SAP transaction recording into a web service and building a form on top of it.
The following criteria can help you decide whether a form is a good choice:
Variability in responses/entries & Linearity.
If most of the entries are always the same then a form is a great choice. Variability is an example of non-linearity, but there are more examples. If users usually enter data in a linear sequence and never need to revisit or revise previous steps then use of a form again, is a great choice. The same is true if the steps don’t depend on one another.
Number of steps.
If the steps are less than say four or five using a form may be a great choice. Too many list boxes with too many data choices and too many dependencies can be very tedious. For examples, on a web shopping cart, presenting me with a exploded bill of materials that I can then pick and choose from may be very nice if I am building something but it isn’t very useful if I want to simply order a standard package. The more selections I need to make, the more likely my end-to-end process is likely to fail. (this is often what happens on the SAP screen – do you really want to replicate that?) Another tip I always give folks is, we support the entry of repeating table data, it’s great for things like FB50 journal entry lines or VA01 sales order entry lines but be respectful of the data entry person, once they go beyond about ten lines of repeating table entry maybe it is time to go back to Excel data…
Data Entry Complexity.
If the data required is straight forward information that can be easily supplied then a form is a good choice. If users need to be careful about their choices or refer to additional supporting materials then a form may not be a good choice, you may want to rethink this as you will need to provide a lot of lookups, a lot of supplementary logic and reference materials. Consider linguistics here also. If you have to create twenty versions of this form in twenty different languages, can that be easily done with the same form or do you have to create complex derivations of the original.
About the author
Clinton Jones is a Director for Finance Solutions Management at Winshuttle where he has worked since 2009. He is internationally experienced having worked on finance technologies and business process with a particular focus on integrated business solutions in Europe, the Middle East, Africa and North America. Clinton serves as a technical consultant on technology and quality management as it relates to data and process management and governance for finance organizations globally. Prior to Winshuttle he served as a Technical Quality Manager at SAP and with Microsoft in their Global Foundation Services group.
Questions or comments about this article?
Tweet @Winshuttle to continue the conversation!