Best Practices on Form Design

Overview

Good form design helps customers submit complete, accurate requests quickly, which leads to higher submission rates, faster fulfillment, and better customer satisfaction. In Enterprise Service Management (ESM) system, that means forms that are short, clearly worded, logically ordered, and accessible to everyone.

Digital forms reduce overhead and improve efficiency, but only when customers can understand and complete them. There is no one-size-fits-all design, yet several practices hold true for nearly every service form. This article covers those practices for ticketing forms in the ESM system, focusing on three principles:

• Keep the customer-facing form simple. Ask only what is needed, in an order that makes sense to the customer.
• Provide clear guidance. Use plain-language labels and help text that appears when and where it is relevant.
• Make it accessible. Design so that every customer, including those using assistive technology or a phone, can complete the form.

In this article:

• Who Designs Forms
• Accessibility
  • Labels and Instructions
  • Static Content
  • Field Choices
  • Check It
• Attributes
• Relevance
• Form Design
  • Fundamentals
  • Customer-Friendly Layout
  • Labels and Help Text
  • Required Fields
  • Conditional Logic
• Tips & Tricks
  • Dynamically Display Contextually Relevant Helper Text
  • When to Use "Number" vs "Text" Field Types
  • When to Use System Attributes vs Custom Attributes
  • When to Use or Not Use Default Values for Fields
  • Impacts of Workflows on Classification
  • Field Types Recommended to Not Use
• Testing the Form Design
• Form Design Checklist

Who Designs Forms

Form design is a partnership. Service Owners and Service Managers know what the service needs and what customers find confusing, so they identify the questions, wording, and improvements a form needs. They do not edit forms directly. Ticketing Application Administrators and Enterprise Administrators build and change forms and custom attributes, applying the practices in this article and the sandbox-first process described in Best Practices for Creating and Updating Forms in Enterprise Service Management.

Service Owners can use this article to describe what they want, and administrators can use it to shape requests into well-designed forms.

Accessibility

Every form should be usable by everyone, including people who use screen readers, keyboard-only navigation, screen magnification, or a phone. Design to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, which is the standard most institutions, and public entities under the ADA, are expected to meet.

Labels and Instructions

• Give every field a clear, visible label. Use the Custom Field Name to write a label that makes sense on its own, such as "Date you need access by" rather than "Date".
• Do not rely on placeholder text as the label. Placeholder text disappears once a customer starts typing and is often low contrast.
• State format requirements in the label or help text, for example "Phone number (907-555-0100)".
• Keep instructions near the fields they describe. Put general instructions at the top of the form, and field-specific guidance in that field's help text.

Static Content

• Use real headings. In static content, use the Heading element type for section titles instead of bold text in a Text Block, so screen reader users can navigate by heading. Use heading levels in order.
• Write descriptive links. Link text such as "Software request policy" tells the customer where it goes; "click here" does not.
• Add alternative text to images in HTML Blocks, or leave decorative images with empty alt text.
• Do not use tables for layout in HTML Blocks.
• Do not rely on color alone to convey meaning, such as red text for required items or warnings. Pair color with words or symbols.
• Check color contrast. Text should have a contrast ratio of at least 4.5:1 against its background.

Field Choices

• Prefer vertical radio buttons and checkbox lists for short sets of choices. They are easy to scan, tap, and use with a keyboard.
• Use dropdowns for longer lists (roughly seven or more choices).
• Order choices logically, such as alphabetically, by frequency, or in a natural sequence, and include "Other" or "Not sure" where customers may need it.
• Avoid time limits and surprises. Do not make fields appear or disappear in ways that move the customer's place on the page without a clear cause.

Check It

Preview every form in the Client Portal, then try completing it using only the keyboard, on a phone, and, where possible, with a screen reader. Ask your accessibility office for help with forms that serve large or diverse audiences.

Attributes

Custom attributes are the building blocks of a form, so good attribute design makes every form that uses them easier to build, complete, and report on. As covered in About Enterprise Service Management Ticket Custom Attributes, keep four principles in mind:

• Make structures transparent. Avoid shortcuts, abbreviations, and plurals. Use consistent, descriptive attribute names, such as "Person (All Users)", "Person (Employee)", "Person (Non-Employee)", "Fund Source", and "Fund Destination", so you and future administrators can maintain the system. Set Header Text to values that read well in reports and graphs.
• Don't reinvent the wheel (data normalization). Create attributes based on the type of data they store, not the form they will first appear on. Reusing attributes keeps data and reports simple. Customize the label on each form with the Custom Field Name so it reads naturally for customers in the Client Portal and for technicians in Work Management.
• Add a description. However trivial it seems, give every attribute a brief Description/Help. It helps future administrators, and report writers see it when they open the Help button in the report builder.
• Plan for the future. Create attributes that can grow with business needs. Planning ahead avoids storing similar data, such as person information, in several different attributes.

Relevance

It is tempting to include fields for every possible situation, but every extra question costs the customer time and lowers the chance they finish. Keep forms concise and include only what is relevant to the request.

For each field, ask:

• Will someone act on this answer? If no one uses it to route, fulfill, approve, or report on the request, remove it.
• Does ESM already know it? The requestor's name, email, department, and phone come from their profile. Do not ask customers to retype them.
• Can it be asked later? Details only needed during fulfillment can often be gathered by the technician, or by a workflow step, after the ticket is submitted.
• Does it apply to everyone? If a question applies only to some customers, use an attribute dependency so it appears only when relevant, or split very different requests into separate service offerings.

Form Design

Optimizing form design is an effective way to engage customers. The right fields in the right order create a positive customer experience and encourage continued use, while poorly designed forms get used less, or get used incorrectly.

Fundamentals

1. Minimize the number of fields. Generally, the more fields on a form, the less likely a customer is to complete it. Wherever completion matters, use as few fields as possible. Optional fields are the first to question: if they are optional, is the information needed at all?

2. Keep constraints in mind. Place fields based on two kinds of constraints:

• Technical needs. A form may need one answer before it can ask another, especially when attribute dependencies control which fields appear. Put parent fields before the fields that depend on them.
• Customer needs. People understand forms best when information is grouped logically and questions move from easiest to hardest. Easy questions first give customers early "wins" that encourage them to finish.

3. Group fields logically. Group fields by theme wherever possible. For example, keep all contact details together instead of scattering them through the form. Follow familiar conventions too, such as building before room or start date before end date, which reduces the customer's mental effort.

4. Group fields visually. Once fields are grouped logically, show those groups visually with static content headings, short section introductions, or a horizontal rule between sections.

Customer-Friendly Layout

The layout should help customers understand and complete the form from the first field to the Submit button.

• Start with a short introduction. Use a Text Block or HTML Block at the top to explain what the form is for, what the customer will need, and what happens after they submit, such as expected response time.
• Use one clear path down the page. TeamDynamix forms flow top to bottom in a single column; keep the order simple and avoid making customers jump back up.
• Put the most important questions first. Ask the questions that determine routing or eligibility near the top.
• Put attachments and optional comments last. Customers expect to add supporting files and extra details at the end.
• Match field size to the answer. Use a Text Box for short answers and a Text Area only when a longer explanation is expected.
• Keep the Title field simple. If the Title is visible to customers, give it a clear label and placeholder such as "Briefly describe your request". Otherwise, set a default Title and hide it.

Labels and Help Text

• Write labels as plain-language questions or prompts the customer can answer, such as "Which software do you need?"
• Avoid internal jargon and acronyms unless customers use them too.
• Keep help text short and specific. Explain why the information is needed or where the customer can find it.
• Be consistent. Use the same wording for the same thing across forms.

Required Fields

• Require only what is essential to route and fulfill the request. Too many required fields frustrate customers and invite guessed or placeholder answers.
• Set required status on the form, not on the attribute, so the same attribute can be optional elsewhere.
• Never require a field that is hidden or that a customer may not be able to answer; offer a "Not sure" choice where appropriate.

Conditional Logic

Use attribute dependencies to show follow-up questions only when they apply. For example, show "Which department will pay for this?" only when the customer selects a paid option. This keeps the form short for most customers while still collecting complete information when it is needed.

Tips & Tricks

Dynamically Display Contextually Relevant Helper Text

Help text remains the right tool for brief, field-level guidance. Use the attribute's Description/Help, or Custom Help Text on the form, to explain what a field means, why it is needed, or what format to use. Keep it to a sentence or two so customers can read it at a glance.

Some guidance is too long to fit comfortably in help text, such as detailed instructions, policy requirements, or next steps that apply only to certain choices. Help text appears as a tool tip that customers can overlook, and Initially Expand All Help shows every tip at once, which makes the form look longer than it is. Always-visible static content (a Text Block or HTML Block) is easy to add but stays on screen even when it does not apply to the customer's choices.

For these larger blocks of information, use conditionally visible static content: a Heading, Text Block, HTML Block, or Horizontal Rule that appears only when a specific value is selected in a multi-value field on the same form, such as a dropdown, radio button list, or checkbox list. The guidance appears where and when it applies, stays hidden otherwise, and keeps the form looking as short as it really is. Because it is static content, it is not stored on the ticket and does not add attributes to reports.

As a rule of thumb, use help text for a short explanation of a single field, and use conditionally visible static content when the information is longer than a couple of sentences or depends on the customer's choice.

Good uses include:

• Next steps for a specific choice, such as "You will receive a separate email to complete the purchase" when "New purchase" is selected.
• Eligibility notes or warnings, such as a reminder that a supervisor must approve requests for elevated access.
• Links to related information, such as a policy or a self-service knowledge article shown when a choice suggests the customer may not need to submit a request at all.
• Instructions for a follow-up section, shown together with the fields that appear for that choice.

To use conditionally visible static content on a form:

1. Confirm the guidance is too long for help text, or applies only to certain choices. If not, use help text instead.
2. Make sure the form has a multi-value field whose selected value determines when the content should appear, and place the static content directly below that field.
3. Choose the element type: a Text Block for plain notes, an HTML Block when you need links, lists, or emphasis, or a Heading to introduce a conditional section.
4. Set the static content's visibility condition to the controlling field and the value (or values) that should display it.
5. Keep the content focused on that choice; put guidance that applies to everyone in the form's introduction instead.
6. Follow the accessibility guidance above, including descriptive link text and not relying on color alone.
7. Preview the form and confirm that the content appears and disappears as expected for every value of the controlling field.

When to Use "Number" vs "Text" Field Types

A Text Box attribute can store Text, Integer, or Decimal values. Choose based on what the customer types and how the data will be used, not on whether the value looks like a number.

When in doubt, use Text, and state the expected format in the label or help text.

When to Use System Attributes vs Custom Attributes

TeamDynamix includes standard (system) fields that are connected to other features, such as notifications, workflow roles, SLAs, assets, and reports. Use a standard field whenever one fits; create a custom attribute only when no standard field captures the data.

Custom attributes are the right choice for request-specific details, such as software title, access level, or funding source.

When to Use or Not Use Default Values for Fields

Default values save time and keep routing consistent, but a default on a question the customer should answer can produce inaccurate data, because people often accept whatever is already filled in.

Use default values for:

• Routing and classification fields customers do not see, such as Responsible, Service, Type, and Priority.
• Values that are almost always the same and that the customer can still change, such as a common quantity of 1.

Avoid default values for:

• Questions that need a deliberate answer, such as Yes/No questions, approvals, or eligibility. Leave them blank and required.
• Dropdowns where a pre-selected first choice would be accepted by mistake.

Keep in mind these TeamDynamix behaviors:

• Profile values win in the Client Portal. A customer's own Acct/Dept and Priority from their profile override the form's defaults.
• Requestor defaults to the person submitting the form when no other default is set.
• Apply Default Value for TDWorkManagement controls whether a default is also used when technicians create tickets in Work Management.
• Hidden and Read-Only fields enforce their defaults. In Work Management, a hidden or read-only field resets to its default every time the form is applied, which can overwrite existing values.

Impacts of Workflows on Classification

A form's classification determines the classification of tickets created from it. Ticket workflows can change that, so design forms and workflows together.

• Automatic workflow assignment sets the classification to Service Request. When a workflow is assigned at ticket creation, through the service or an Automation Rule, the ticket becomes a Service Request even if the form is an Incident or Change form.
• Use promotion classification to keep the intended classification. To keep a Change form's tickets as Changes, set the workflow's promotion classification to Change and have it apply before the first step.
• Promotion only moves upward. Workflows can promote a ticket up the classification hierarchy (for example, Service Request to Change) but never down.
• Changing classification later is harder. Technicians must unassign the workflow before editing a ticket's classification, and then select a form that matches the new classification.
• Classification affects reporting and SLAs. Confirm that reports, SLAs, and Automation Rules expect the classification the ticket will actually have after the workflow runs.

Field Types Recommended to Not Use

Testing the Form Design

Test every new or changed form in the sandbox before it reaches production, and include the Service Owner or Service Manager in the review.

• Preview both views. Use the form's Preview tab to check the Client Portal and Work Management versions.
• Complete it as a customer. Submit the form through the Client Portal service as a typical customer would, with realistic answers.
• Try every branch. Select each choice that triggers an attribute dependency and confirm that the right fields and conditional static content appear and disappear.
• Check on a phone and with a keyboard. Make sure fields, choices, and buttons are easy to read, tap, and reach without a mouse.
• Review the resulting ticket. Confirm the technician sees what they need, in a useful order, and that classification, routing, and workflow behave as expected.
• Ask real users. Have two or three people unfamiliar with the form complete it, and note where they hesitate or ask questions.
• Revisit after launch. Review incomplete or misrouted tickets and customer feedback after a few weeks, and refine the form.

Form Design Checklist

• Every field is needed to route, fulfill, approve, or report on the request
• No questions ask for information already in the requestor's profile
• Standard fields used wherever one fits; existing custom attributes reused
• New attributes have descriptive names, useful Header Text, and a description
• Fields grouped logically, ordered easiest to hardest, with headings between groups
• Short introduction at the top explains the form and what happens next
• Labels are plain-language prompts; help text is short and specific
• Only essential fields are required; required status set on the form
• Follow-up questions appear through attribute dependencies; choice-specific guidance uses conditionally visible static content
• Number fields used only for true numeric values; identifiers stored as Text
• Defaults used for routing fields, not for questions needing a deliberate answer
• Form classification and workflow promotion classification agree
• No discouraged field types (Multiselect, Color, wide horizontal radio lists)
• Headings, link text, contrast, and images meet accessibility guidelines
• Previewed in both views, tested on a phone and with a keyboard, and reviewed by the Service Owner

Is there any additional information I should know about?

• Best Practices for Creating and Updating Forms in Enterprise Service Management
• About Enterprise Service Management Ticket Custom Attributes
• Create ESM Ticket Form
• Web Content Accessibility Guidelines (WCAG) 2.1

Need additional help or have issues

For support, requests may be submitted anytime using the appropriate Enterprise Service Management form. Requests generate a Ticket which will be worked in order received and urgency by IT Employees with the knowledge and permissions to assist with the request.

For immediate assistance please review the Contact Us page for the appropriate support group.