Check out your users’ division of labour
When creating a form for an organization or group of users, take a look at how they divide labour and knowledge. You might find you have to separate forms, or let them ‘transfer’ between different users.
If you’re designing an application for a client that has more than one user – for example, a business or social group – then it pays to research how that group is organized, and whether all knowledge and duties relevant to your app are shared amongst the group. It might turn out that your form asks for data that actually belongs to more than one person, or that the duty of completing your form is actually shared by two people.
Let’s imagine the fictional Waterford Council wants to collect information on local businesses. It does this with a self-assessment form that asks for a variety of information – both key financial data like turnover and VAT payment, that only busy senior employees can provide, and trivial information like location and number of workers, that a more junior employee could provide fairly easily. By thinking about our users’ division of labour, we can see it’d help if the busy senior employees could provide only what they absolutely had to, then referring the form on to a free assistant or secretary. That means either creating a form that can be saved and opened in another session, or creating two forms directed at different users.
Alternatively, let’s imagine the council has another form that asks local charities for information both on their donors and their volunteers. In many charities, that information will be held by several people. A user might have to consult colleagues to complete the form. But if the form has a habit of timing out, or can’t be completed across multiple sessions, a user may end up completing part of the form only to realize they can go no further. That’s immensely frustrating, and makes for poor form design.
A little thinking about our users’ division of labour can be remarkably useful. Try it in your next project.
Assuming a solution of a single form that can be completed across multiple sessions it would be nice to avoid having the users decide whether a question is something he or she should answer. For example, a question could be labeled as Financial, so the junior employee with no access to financial data can skip it with very little cognitive effort.