In previous posts we have discussed data modelling and the data dictionary. This post is to discuss the input forms used to enable a system user to interact with our application.
There are many types of forms as these can be anything from a web page or an app page to a green screen for a legacy application or a Windows form. All of these have several things in common though:
- They are designed to enable a user to interact with an application
- They may allow for the entry and validation of data
- They provide information to the user
- They allow the user to choose the next action.
Behind the scenes there are two different types of behaviour that need to be defined for the form:
- Wireframe – Visual representation of the look and feel of the completed form.
- In page functionality – Typically this will relate to the content of the form that will consist of content, fields, links and buttons.
- Post functionality – This is the functionality that is performed as a result of the user completing the form and choosing a next action.
Each of these must be specified when defining behaviours in a form and are discussed in further detail in the subsequent sections of this BLOG.
Wireframe
The wireframe is often the first artefact generated when specifying a form and is used to help the business users and developers visualise what the finished product will look like. It is worth mentioning the style guide here as this is the overarching document that should describe the look and feel for the application. This is produced by the project’s UX specialists and will contain details of how each field type used by the application is displayed. Consequently a wireframe can be much lighter weight instead concentrating on the positioning of particular fields and other form content rather than being an exact representation of what the form needs to look like.
In Page Functionality
These requirements will relate to the behaviour of the individual fields and content within the form. The acceptance criteria that are specified will depend on the field/content type. Some typical acceptance criteria are described together with the rules that determine if the acceptance criteria is required in the following table.
| Title | Question | Explanation | Condition |
| Name | What is the name of this content? | Give a descriptive name for the content that is to be included in the form. | Required |
| Description | Please describe the content? | A description of the content. | Required |
| Content type | What type of content is this? | Copy – Copy that needs to be displayed to the user on the page. This may be text, images, charts, video etc. Field – For display of data or data entry. Link – Link to another page. Action Buttons – Button to perform a specific action when clicked by the user. Tables – For organisation of other content types in the form. Inserts – Inserts from other systems such as an Iframe for a Payment system. Other – There are always new widgets being developed for interaction between users and computers. | Required |
| Order | Where does this content appear on the page? | Used to specify the order that content is displayed in a form. | Required |
| Show/Hide rule | What rule determines if the content is to be shown or hidden? | Business rule that determines if the content is to be shown or hidden e.g. to show certain content based on the role of the user. | Optional |
| Caption | What caption is to be displayed for this field? | This is where the copy text for the caption is specified together with any business rule where alternate values might be used. | Optional for all content types. |
| Copy Detail | What is to be displayed in the copy? | Describe the copy type and content. This may include a link for an image etc.. | Required for content of type copy. |
| URL | What is the URL for the link? | This is where you can add the URL for the link that takes the user directly to another location either within the application or to another location on the web. | Required for content of type link. |
| Other A/C | Any other acceptance criteria? | You can add any additional acceptance criteria here. | Optional for all content types. Mandatory for type of other. |
| I/O Type | Is this field an input field, an output field or both? | Valid values are: Input – The field only accepts input values.Output – The field only displays information and cannot be edited.I/O – The field displays data but is also editable. | Required for content of type field. |
| .Field Type | What type of field is this? | Valid values are: Text box – where the user types in the data directly.Radio button – where the user selects a single option by ticking a box.Tick box – Where the user will tick a box to select a value.Single select Drop down – Drop down where the user can only select a single value.Multi-Select Drop Down – Drop down where the user can select more than one option.Select box – Button to select a value. Date picker – Field showing a calendar for customers to select a date.Other – A field type not identified above. | Required for content of type field and I/O type of either input or I/O. |
| Default Value | What default values should the field take? | Define the rules here for the default value entered in the field. | Required for content of type field and I/O type of either input or I/O. |
| Help Text | What help text should be available for this field? | This is to specify the help text provided to the customer in the event that they request help with data entry. This field is optional as it is not always required. | Optional for content of type field and I/O type of either input or I/O. |
| Population Rules | How is this field populated? | This is to specify how the field needs to be populated. This will typically reference the underlying data model that is used to derive the values displayed in the field. | Required for fields of type I/O or Output |
| Format | How should the output field be formatted for the user? | This is to specify the formatting of the field when the data is displayed to the user. This might include how numbers are displayed and if amounts are displayed with a preceding ‘£’ sign for UK currency etc.. | Required for fields of type I/O text boxes or Output fields |
| Validation Rules | What are the validation rules for this field? | These rules may include: Mandatory/OptionalPermissible character types/Regular expressionsNumeric rangesMaximum string lengthsBusiness rules to apply against values entered. | Required for Field types of Text box. |
| Error Message | What is the error message to be displayed in event of this validation rule being triggered? | Where a validation rule is triggered it is typical to display a validation error message. | Required for each validation rule. |
| Table Type | What type of table is this | Structural – Used to organise the form contents. Dynamic – Used to hold data. | Required for content of type table |
| Table Headers | What are the columns of the table? | Define the columns of the table that is to be displayed to the customer including the header if there is one and what is to be displayed in the column. | Required for content of Type dynamic Table. |
| Table Row Selection | What are the selection criteria for each of the rows that are added to the table? | Where there is a table displaying dynamic data then this is the selection criteria that determines which data is displayed. | Optional for content of Type dynamic Table. |
| Table Row Order | What order are the selected rows to be displayed in? | Where the content of the table is dynamic then this acceptance criteria is how the system should determine the order that the fields are displayed in. | Required where table row selection acceptance criteria has been added. |
| Structural Table Contents | What is to be included in each of the columns and rows for the table? | Where the table is static these acceptance criteria describe the number of columns and number of rows and what is held in each of them. | Required for structural tables. |
| Inserts | What are the acceptance criteria for the inserts included in the form? | These are freeform acceptance criteria so that you can explain the content that is included in the page from a third party. | Required for content of Type Insert. |
| Any Other Acceptance Criteria | Are there any other acceptance criteria for this content? | This provides the product owner with the opportunity to define any other acceptance criteria to describe the content for the form. | Optional for all content type. |
POST Functionality
Post functionality defines what occurs after the user selects an action on the page. Typically this will consist of performing specific actions that interact with the static model prior to getting the next form based on the results returned by the action. These functions are usually related to buttons or function keys in older systems. Links traditionally result in the execution of a get function without any post function. The table below defines how these acceptance criteria should be defined. This area of system behaviour definition is often not specified in enough definition while a large amount of effort is spent on the ‘in form’ behaviour.
| Title | Question | Explanation | Condition |
| Action Name | What is the name of the action? | This is the name of the action that connects the form with the static model and other actions that the application can perform in response to a user request. | Required |
| Action Description | Describe the details of the action to be performed? | Description of the action. | Required |
| Form Trigger | Which form content causes the action to be triggered? | The user action on the form that triggers the action. E.G. pressing a button or clicking on a link. | Required |
| Additional Conditions | Are there any other business rules that determine if this particular action should be performed based on the form trigger? | You may wish to add further business rules to determine which action occurs when a particular form trigger is hit. E.G. you may wish to specify different actions for a next button based on a user role or some other context. | Optional |