Overview
Grant and research application forms frequently serve as the initial phase in the grant-making process. These forms are generally utilized to gather information regarding the applicant, including the intended use of the received funds, the applicant's objectives, anticipated outcomes, and timelines. The responses to the questions within the form are instrumental in determining whether the applicant will be awarded funding.
While the application form may appear as a mere collection of questions, it possesses deeper significance akin to an iceberg. Therefore, how can you ensure that your application forms are effectively gathering the necessary data while providing an optimal user experience for your community?
This article outlines a framework consisting of seven critical considerations when designing and developing application forms within SmartSimple. These seven elements will assist you in creating forms that effectively collect the requisite data and deliver an exceptional user experience for your community.
Considerations Prior to Creating an Application Form
Form - Essentials
Determining the Appropriate Data for Your Needs
You may possess an existing form or a clear understanding of the questions you wish to pose. Prior to initiating the construction of your form in SmartSimple, reflect on the following: who, what, why, and how.
Who is the intended recipient of this data?
Identify the individuals or teams that require access to this data. Certain data may be utilized by internal teams; if so, specify which teams and individuals. Additionally, some data may be necessary for reporting to governmental bodies or third parties, or to demonstrate the outcomes of funding. Clearly delineate who necessitates access to this data.
What data must be collected?
Even if you are utilizing a template, a standard form, or an existing form, consider: what is the essential data I need to collect, and do I possess a question that will yield that data? If a question is not necessary, eliminate it. Each additional question complicates and lengthens the form-filling process. Unnecessary information detracts from what is truly important.
Why are we collecting this data?
Clarify the rationale behind each question. Some responses may be critical for making funding decisions, while others may be utilized for reporting outcomes. If an applicant's mission statement is not necessary for decision-making, consider omitting that question.
How will the collected data be utilized?
Identify the intended use of the data within your processes. If the information is for reporting purposes, will the responses be anonymized and aggregated for public access, or sent to governmental agencies or third parties? If the data informs decision-making, how will it be made accessible within the system and restricted to specific individuals? Additionally, how will you mitigate bias based on demographic or personal information provided? Will self-identification be permitted, and will that information be optional?
Determining the Appropriate Data Structures for Your Needs
Having established the questions you wish to ask to obtain the necessary data, consider the suitable data structure within the context of SmartSimple.
What custom fields are suitable for your needs?
The following custom fields may be appropriate based on the corresponding answer styles:
Answer Style | Custom Field |
---|---|
Text-based answers including dates and numbers | Text Box (Text Single Line, Text Multiple Lines, Date, Date and Time, Email, Number, Phone Number) |
Selecting a predefined answer option | Select One/Many (Radio Buttons, Checkboxes, Dropdown List with Predefined Options or Dynamic Content) |
Selecting a predefined answer option when numerous options are available | Lookup (Autocomplete) |
Reference documents, files, media | Upload (Multiple File storage with or without Media Library enabled, Image) |
Tabular information | Upload (Multiple File storage with or without utilizing a parser) Advanced/Basic Data table |
How will you ensure the data reaches those who require it?
Different stakeholders may necessitate access to data in various formats. For instance, you may need to aggregate responses or present them in a report export, PDF, JSON file, web-based portal, public search, map plot, or through a custom API integration. Your intended output method will influence how the data should be stored (and where) as well as which features and fields will be most effective for you within SmartSimple.
Where will the data be stored within your system?
Consider the optimal storage location for the data you collect. For example, information regarding a grantee may be best housed within that grantee's profile or their organization's profile. This approach minimizes the need for users to input the same information across multiple forms. If information must be displayed in various locations or systems, identify the single source of truth and the features required to update other locations, such as system variables, data exchange, or the SmartConnect API. If data originates from an external source, determine which integration will be utilized. For instance, you may opt to populate an organization's details based on information from the IRS verification service rather than requiring the user to enter their own organizational details.
How will you synchronize data structures across programs?
You may manage multiple programs over several years across various teams. Consider strategies to ensure consistent use of the same fields and structures across multiple programs and teams. Additionally, evaluate whether your application cycles necessitate versioning to apply form changes solely to specific cohorts of applicants.
What will the process flow entail?
Numerous individuals may contribute to the form, including the applicant, their team, as well as internal and external teams involved in the review, advisory, or approval processes. Will you utilize features such as invitations, annotations, and group emails? Contemplate the entire application lifecycle, including how outcomes will be reported and how you will demonstrate the impact of the funding, such as identifying beneficiaries. Additionally, consider the types of communication you will maintain with the applicant. Will you employ notes, annotations, emails, or a separate UTA to manage these communications? Can applicants submit an audio/video application or explanation using the media library, or will all communication be text-based? How can users receive assistance if unforeseen issues arise? Will you integrate AI as part of the pre-screening process and allow other roles to seek assistance from the artificial intelligence in their workflows? Will you utilize e-signature integration for digital document signing, and if so, which vendor will you choose?
Determining the Structure and Layout of Questions
Having established the data structure necessary for producing the information your community requires, consider the visual presentation of the form.
How will you logically organize content?
What groupings will align with your community's cognitive framework? For example, will you categorize all questions related to applicant outcomes under a single title bar? Will you position related content within the same tab, and if so, what logic will govern the grouping of similar content? Organizing similar content under a title bar facilitates user navigation to the desired information. Will you employ the title bar navigation pane to access sections of your application? Will you prioritize vertical scrolling for an enhanced mobile experience or opt for a horizontal tabbed layout? Exercises such as card sorting can assist in designing the information architecture of your form.
How will you present the content?
Consider the following content presentation options:
- Present the content in a single or multiple column layout
- Establish the display order and visibility of questions
- Utilize the linked record list to display records inline
- Employ the Title Bar Navigation Pane for navigating to content sections
- Incorporate an instructions custom field for clarity at the section level
- Include a countdown timer for expiring calls
Determining the Quantity of Questions to Ask, Timing of Questions, Data Access, and Duration of Access
Now that we have established the organization and layout of the questions, we must consider the number of questions to include, whether all users should have access to every question, and when those questions should be answered.
What is the optimal number of questions?
The likelihood of form completion diminishes as the number of questions increases. The appropriate number of questions is contingent upon your community and specific needs. Be cognizant that an excessive number of questions may create barriers to entry, particularly for vulnerable applicants who may lack the resources to engage a grant writer. The number of questions may also depend on the funding amount and your relationship with the applicant. A shorter, trust-based application may be suitable for applicants requesting a modest sum or those who have previously received funding and fulfilled their reporting obligations. Additionally, evaluate whether each question must be mandatory and whether you have already collected that information, either from the previous year or during the signup process. If a question could be optional, is it still necessary to ask?
When should a question be presented?
Consider that it is unnecessary to pose every question simultaneously. You may initiate with an eligibility questionnaire to determine if the user meets the program criteria. Subsequently, ask initial questions, and employ progressive disclosure to introduce additional questions as they progress through your process. You may wish to implement conditional logic for certain questions or utilize Dynamic Field Visibility Controls, as not all questions may be relevant under every circumstance.
Who can access the data, and for what duration?
Certain questions may involve personally identifiable information (PII). Ensure transparency regarding the data collection purpose, its usage, and the duration of data retention. Consider your data retention and masking policies, as well as compliance with legislation such as GDPR. Additionally, identify which individuals (roles) will have access to specific data. Consider concealing certain information that may influence reviewers and decision-makers, thereby aiding in the reduction of bias related to diversity, equity, and inclusion (DEI). You may also require users to acknowledge your privacy and security policies prior to permitting their application to your programs.
Evaluating the Quality of Questions, Captions, and Instructions
Having established the appropriate questions, assess their quality.
How effective are the questions?
Based on the data you intended to gather, are you receiving the desired responses? If not, should the question be rephrased or clarified? If the question fails to elicit the needed information, is it still relevant?
How effective are the instructions?
If you are providing instructions, are they succinct? Do they utilize clear language, or do they over-explain and complicate matters? Are you employing the appropriate structure for your instructional text? In some instances, you may wish to position text beneath the caption, at other times in a tooltip, or perhaps create an instructions field with visibility permissions based on roles.
Identifying Actionable Insights for Form Improvement
Having evaluated the effectiveness of your questions and instructions, consider how to identify challenges within your users' journey.
What challenges are users encountering during their journeys?
Reflect on how you will uncover the challenges your users face as part of their journey. Are users successfully completing their tasks, or are applications being abandoned? If users are encountering difficulties, where in the process does this occur? Consider the service design of your application process. Various methods exist for conducting user research. Behaviorally, you can observe user actions through metrics. Qualitatively, you can understand user motivations and behaviors via usability testing, interviews, and focus groups. Attitudinally, you can gauge user sentiments through surveys and examine the information architecture of the forms through exercises such as card sorting. Quantitatively, you can analyze reports, list views, and statuses to ascertain how many individuals are facing challenges and in which areas. By analyzing trends in incomplete fields and applications, you may gain insights into potential roadblocks.
Bear in mind that your system may encompass various users, including applicants, program managers, reviewers, stakeholders, funders, and administrators. Each user role may present distinct challenges. Furthermore, users may possess varying abilities and levels of expertise, so it is crucial to maintain an inclusive approach.
Identifying Necessary Changes and Managing the Change Process
Once we have identified the challenges faced by users, we must consider what changes are necessary and how to manage those changes.
What changes are necessary?
You may have compiled a list of user pain points; however, you must also consider limited time, budget, and technical constraints. Attempt to consolidate your list of challenges and prioritize them based on perceived benefit (value), effort, and risk. Changes may range from simple text modifications to more complex adjustments involving internal processes or the adoption of new features or integrations.
How will changes be implemented?
Consider the implementation strategy for the changes. Will the modifications be carried out internally, or will an external party handle them? If external assistance is required, will the changes be executed by SmartSimple (Support, implementation team, configuration hours, an RFS) or a SmartSimple partner? Is stakeholder buy-in necessary? How will stakeholders be informed of the upcoming changes, and when will they be enacted? Is there a review process in place for the changes? Will features such as Versioning, Draft Portal, Batch Update, Autoloader, or the test to production (T2P) tool be utilized? How will you measure the impact and success of the changes?
Creating an application form that effectively collects the right data while providing an excellent user experience entails more than merely adding questions to the form. Consider the seven key areas discussed above prior to form creation. What is appropriate for your needs will be as unique as your evolving requirements.
Record Page
Record pages provide the capability to view the details of an individual item within an application. They encompass both the standard fields and custom fields. Record pages may be created for organizations, users, and Level 1 entities. From the record page, users can execute various actions on the record, such as editing fields, modifying the status, adding it to a SmartCard, attaching notes, assigning contacts and accounts, and associating it with a Level 2 Activity.
Configuration - Essentials
When a new record is introduced to an application, the record page prompts the user to provide information for various standard and custom fields. While the standard fields are predefined by the system's default settings, the custom fields can be created and managed by the Global Administrator. Each unique application will necessitate distinct custom fields based on the information being tracked and the actions required.
A sample view of a record page for a Level 1 entity utilized in an application.
# | Component Name |
---|---|
1 |
Header Contains: logo, main menu items, header button group |
2 |
Action Bar Contains: history button group and action bar button group, pagination control |
3 |
Action Bar Button Group Contains: new (level 1, level 2, and other options), view/edit mode button, options menu |
4 |
Title Area Contains: title and high visibility options |
5 |
High Visibility Options Contains: hide/show instructions, add to SmartCard, enable/disable dock |
6 |
Hierarchical Navigation Bar Contains: links to parent object (UTA > L1 > L2 > L3) |
7 |
Body Contains: custom/standard fields, tab area |
8 |
Tab Area Contains: custom fields of the type layout tabbed section |
9 |
Left Navigation Contains: main, notes, contacts, invitations, organization, level 2s (activities) |
10 |
Submit Bar Contains: save and submit buttons |
11 |
Tab Bar Contains: tabs, new tab button, multi-task button |
The body area of the record page encompasses all custom fields. To configure custom fields for all records within your application, navigate to UTA Configuration Settings > (Level 1) tab > Custom Fields. Configuration settings for each application can be found by clicking the gear icon in the action bar. To establish custom fields for organizations, proceed to Global Settings > Organizations tab > Custom Fields. To configure custom fields for users, navigate to Global Settings > Users tab > Custom Fields.
Setting Up Custom Fields
For a basic application, when creating a new custom field, you may choose from a predefined list of field types based on the intended use. For instance, a record containing a simple field for “About” may utilize the field type Text Box - Multiple Lines. A field designated for “Shipping Address” could adopt the type Special - Geo Mapping. Once the appropriate field type is selected, you may also assign a name to the custom field in the database (Field Name) and a display name that will be visible to users (Caption). The Display Order determines the position of this custom field within the form. A higher number indicates a position closer to the top of the form. A Description is not mandatory and will only be visible to Global Administrators, however, providing a brief description for each custom field will facilitate tracking changes and recalling the purpose of each field. In the Permissions & Availability tab, you may further customize access to the custom field based on user roles, type categories, or specific status changes that may trigger access.
Configuration - Advanced
Submit & Save Buttons
Submit & Save buttons are utilized to execute custom actions on each record, such as saving a record, altering the status, validating input, or adding annotations. Similar to custom fields, submit and save buttons can also be customized to be active solely for specific roles, statuses, or record categories. To access the settings for any individual custom field, navigate to the following:
- UTA - Configuration Settings > (Level 1) tab > Submit & Save Buttons
- Organization - Global Settings > Organizations tab > Submit & Save Buttons
- Users - Global Settings > Users tab > Submit & Save Buttons
Record Layout Custom Fields
Title bars and tabbed sections assist in organizing your records page by grouping similar custom fields. A title bar delineates related content on the same records page, while a tabbed section allocates blocks of related content to a separate tab. The arrangement of custom fields can be managed through the Display Order.
Settings Explained
Numerous custom fields can be displayed on the record. To access the settings of any individual custom field, navigate to the following:
- UTA - Configuration Settings > (Level 1) tab > Custom Fields
- Organization - Global Settings > Organizations tab > Custom Fields
- Users - Global Settings > Users tab > Custom Fields
Each custom field generally includes additional display options under the General Settings tab.
Display Settings
- Caption Location
Allows for the positioning of the field label either above, to the right, or to the left of the input, or for it to be hidden altogether.
- Instructions
(Optional) Text that provides guidance on how the user should input data into the field.
- Placeholder Text
(Optional) This is greyed-out text that pre-populates the input field, which can be useful for illustrating examples or suggesting the desired input format.
- Tool Tip
(Optional) A tooltip will display a special icon beside the caption. When the user hovers over this icon, additional text will appear, providing further information or assistance regarding the field.
- Width
(Optional) Allows for the specification of the total width of the field from a selection of dropdown options.
- Height
(Optional) Allows for the specification of the total height of the field in either percentage or pixel format.