FormsIE style guide and question protocol

Before you begin building a form, you should consult with the business unit or form administrator on the team concerned and create a question protocol. It should make note of the following:

• every question you intend to ask on the form
• who in your organisation will use the answer to each question
• what they will use them for
• whether the answer is required or optional - if it is optional, the information is not required. So why ask?

Only information that you really need to know should be collected by a form. Pay particular attention to sensitive information or personal data when building a form. Unless you really need the information, leave it out.

Question order [for personal details sections]

First name

Last name

Address [use the full address Eircode lookup component)

Email address

Phone number

Section headers/sub-headers

• For the best user experience, give your form sub-headers to denote what type of information is being sought in each section. The first one would usually be: “Your personal details” - in sentence case.
• An optional explanatory strap/sub-head [optional description field] can be populated to expand on what the section is for.

General form functions

• All required questions need to indicate they cannot be skipped.
• All optional questions should be marked optional
• The “submit” button is in place of a signature or declaration, except for forms requiring a declaration agreement with a separate, specific legal basis.
• Ensure there is a well composed post-submission message page after the submit button to tell the user their form has been sent and what will happen next.
• If you are using the email confirmation feature, compose the message as a general, polite and short message in plain English telling them their form has been sent and what the next steps will be.

All questions should be written in sentence case (cap only the first word).

• Please adhere to the gov.ie style guide regarding capitalisation and spelling. Note that the words form, applicant, teacher, doctor, carer, leave, department, circular, minister, government, and so on are all lower case when they appear alone.
• Do not use colons [:] or full stops [.] at the end of questions.

The format for the name fields should be (in this order):

First name

Middle name [rarely, and only for forms where middle name is deliberately required]

Last name

OR

Full name

Reasoning

• ‘What is your name?’ and subsequent questions in question-marked format are unnecessary. Single word and short phrases are preferable to sentences in question-marked format, especially for people whose first language is not English.
• We also avoid the term 'Surname' where 'Last name' is clearer to people whose first language is not English.
• First name should always be asked before last name
• Offering the field 'Full name' is a good option on any forms where you know that a potential applicant's name does not fit the western standard of 'first, last'. This includes natives of some Asian and African countries. In Latin America and Spain, for example, many people use two surnames. The option 'Full name' can allow for these exceptions. It is better to allow a person to identify themselves in their own way than to make their name fit a standard structure.

Exceptions

On forms that could be filled out by a particular job type or by a third-party, it is clearer to write “Teacher’s name” or “Parent/guardian’s name”. Proceed on a case-by-case basis. However, using sub-headers for form sections can remove the need to qualify the name type. See sub-headers below.

• For date of birth/start of leave/end of leave etc, date-pickers should be standard.
• If manual date fields are ever used, we should instruct the user to enter the date in dd/mm/yyyy. This applies only to separate periods of weeks until such time as the date-picker allows for multiple date entries.
• Wording of questions that require entering of start and end dates needs to be carefully done. Use the word “inclusive” to denote periods in which the start and end dates are included, e.g. absence, paid leave etc.

• This should always state “Email address”
• In cases of forms involving leave, the personal email should be requested. Note: only request the email if it will in reality be used. If being used, the GDPR notice will outline the terms of collection and usage of email addresses.

• The wording should be "Address"
• For non-applicant address, say "School address" "GP address" and so on.
• For forms with an Irish audience, use the Eircode picker component.

• Should be worded as "Phone number” and not "Mobile number" as the field should allow for landlines as well as mobiles. Delete the 'home or mobile' text line that pops up when you select this option.
• Field should allow for overseas mobiles in all cases.

• Terms such as “Give details of” and “Enter any additional information” should be clarified to the maximum. If asking for dates of previous hospitalisations, illnesses, absences, career breaks, for example, state “enter the dates of...” instead of “give details of”. Encourage form-builders to rephrase these open-ended questions as more specific questions for information they actually need to provide their service.
• The term ‘in chronological order’ is not advisable when instructing users to enter dates or blocks of information. Plain English this to “Starting with the most recent, …”
• Avoid the use of quote marks – single or double – around words.
  An example is: “If ‘yes’, please state the previous dates of your career break.”
  This should read: “If yes, please state the previous dates of your career break.”

Gender

This field should be worded as 'Gender'.

Gender options should appear as radio buttons or a dropdown menu, and allow the selection of just one option.

Please use specifically the options listed below.

• Man (including trans man)
• Woman (including trans woman)
• Non-binary or gender non-conforming
• My gender is not listed here (use the box to tell us)
  
  For forms being completed on behalf of children, please use:
  
• Boy
• Girl
• Non-binary or gender non-conforming
• Their gender is not listed here (use the box to tell us)
  
  Reasoning
• The above options are best practice as agreed in conjunction with the HSE.
• The terms 'male' and 'female' are sex terms, not gender terms, and should be reserved for medical forms or forms where a person's biological sex is important. This is for inclusivity, as it acknowledges that there are people for whom gender identity and biological sex are not the same.
• As a general rule, your form should only ask about gender if you have a strong reason for asking. Will your organisation be using this information to improve the lives of trans or gender non-conforming individuals? Is your form a survey that should specifically include data attributable to or contributed by the trans community?
• Never ask for gender out of interest, because it 'seems' like something you'd ask on a form, or just to tick a box to keep such information on file.

Ethnicity

Our question protocol for race mirrors that of the CSO/census.

Ask: 'What is your ethnic group/ background?' and use a logic sequence thereafter. The correct options are outlined below:

A White

1 Irish

2 Irish Traveller

3 Roma

4 Any other White background

B Black or Black Irish

5 African

6 Any other Black background

C Asian or Asian Irish

7 Chinese

8 Indian/Pakistani/Bangladeshi

9 Any other Asian background

D Other, including mixed group/background

10 Arabic

11 Mixed, write in description

12 Other, write in description

Religion

Our question protocol for religion mirrors that of the CSO/census.

Ask: 'What is your religion, if any?' and give the following options, with a box for other.

No religion

Roman Catholic

Church of Ireland

Islam

Orthodox Christian

Presbyterian

Other (type in your religion).

Online forms will be novel for many users so trust won’t be automatic. A clear and easily accessed GDPR policy covering reason for collection and use of data, storage method and duration must be in place. Users of forms should be able to access and read your organisation's privacy policy via a hyperlink located BEFORE the submit button, not after.

Avoid entering lengthy data and consent wordings inside the form - hyperlink to something long that needs to be read.

Remember, forms are for asking questions, not for providing background, policy, or answers to common questions - use your web pages for this.