Application form design in SmartSimple involves seven key areas that span data requirements, structure, layout, and ongoing maintenance. Addressing each area helps ensure forms collect the right data and deliver a good experience for the community.
Grant and research application forms are typically the first step in the grant-making process. They gather information about the applicant's intended use of funds, objectives, anticipated outcomes, and timelines. The responses help determine funding decisions.
Who: This framework is for Grant Administrators, Program Managers, System Administrators, Internal Staff, and Global Administrators who design, build, or maintain application forms in SmartSimple.
When to Apply Form Design Standards
Apply form design standards when:
- Building a new application form from scratch in SmartSimple.
- Redesigning or auditing an existing form.
- Onboarding a new program team and establishing form design standards.
- Planning a new grant cycle or program and defining data requirements.
- Evaluating why applicants are struggling with or abandoning forms.
- Preparing to implement changes to an existing application process.
Data Requirements
Before a form is built in SmartSimple, four questions are worth considering: who, what, why, and how.
Who Needs the Data?
Identify who needs access to the data. Some data may be used by internal teams, note which teams and individuals. Other data may be needed for government or third-party reporting, or to demonstrate funding outcomes.
What Data Must Be Collected?
Even when using a template or existing form, identify what data is actually needed and confirm a question exists to collect it. Remove questions that are not necessary. Every extra question makes the form longer and harder to complete, and unnecessary questions dilute what matters most.
Why Is This Data Being Collected?
Be clear about the reason for each question. Some responses may be critical for funding decisions; others may support outcome reporting. If a question, like an applicant's mission statement, is not needed for decision-making, consider leaving it out.
How Will the Data Be Used?
Consider how the data will be used in supporting processes. For reporting, responses may be anonymized and aggregated, or sent to government agencies or third parties. For decision-making, data access and restrictions within the system need definition. Bias reduction related to demographic information is also a factor; self-identification may be allowed and made optional.
Data Structures
Once the required questions are known, the appropriate data structures for those needs can be considered within SmartSimple.
What Custom Fields Are Appropriate?
Select the custom field type that matches the expected answer style.
| Answer Style | Custom Field Type |
|---|---|
| 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 option when many options are available | Lookup (Autocomplete) |
| Reference documents, files, or media | Upload (Multiple File storage, with or without Media Library; Image) |
| Tabular information | Upload (Multiple File storage, with or without a parser); Advanced/Basic Data Table |
How Will the Data Be Shared?
Different stakeholders may need access to data in different formats, such as a report export, PDF, JSON file, web-based portal, public search, map plot, or a custom API integration. The intended output method influences how data should be stored and which SmartSimple features and fields will work best.
Where Will the Data Be Stored?
Identify the best place to store collected data. For example, information about a grantee may be best stored on that grantee's profile or their organization's profile. This reduces the need for users to enter the same information across multiple forms. If information must appear in multiple locations or systems, identify a single source of truth and the features needed to update other locations, such as system variables, data exchange, or the SmartConnect API. If data comes from an external source, identify which integration applies. For example, an organization's details might populate from the IRS verification service rather than requiring manual entry.
How Will Data Sync Across Programs?
Multiple programs may be managed over several years across different teams. Consistency in fields and data structures across programs and teams is an important consideration, as is whether application forms need versioning to apply form changes only to specific cohorts of applicants.
What Will the Process Flow Be?
Many people may contribute to a form: the applicant, their team, and internal or external teams involved in review, advisory, or approval. Features such as invitations, annotations, and group emails may support this. The full application lifecycle is worth mapping out, including how outcomes will be reported and how the impact of funding will be demonstrated. Communication with applicants may include notes, annotations, emails, or a separate UTA. Audio or video submissions through the media library, AI assistance during the workflow, and e-signature integrations are also factors to evaluate, along with which vendor to use if applicable.
Structure and Layout
Once the data structure is known, the look and feel of the form for users becomes the next consideration.
How Should Content Be Organized?
Content groupings should make sense for the community. For example, questions about applicant outcomes might be grouped under one title bar, and related content might share a tab based on a defined grouping logic. Organizing similar content under a title bar makes it easier for users to navigate to the information they need. The title bar navigation pane can support access to sections of the form, and layout choices such as vertical scrolling for mobile or a horizontal tabbed layout should reflect the needs of the audience. Exercises like card sorting can help design the information architecture of the form.
How Should Content Be Presented?
Consider the following presentation options:
- Present content in a single or multi-column layout.
- Set the display order and visibility of questions.
- Use the linked record list to display records inline.
- Use the Title Bar Navigation Pane to navigate to content sections.
- Add an instructions custom field for clarity at the section level.
- Include a countdown timer for expiring calls.
Question Quantity, Timing, and Access
Once organization and layout are set, the next considerations are how many questions to include, who should see which questions, and when those questions should appear.
How Many Questions Should Be Asked?
The likelihood of form completion decreases as the number of questions increases. The right number depends on the community and specific needs. Too many questions can create barriers to entry, particularly for vulnerable applicants who may not have access to a grant writer. The number of questions may also depend on the funding amount and the relationship with the applicant. A shorter, trust-based application form may be appropriate for applicants requesting a modest amount or those who have already received funding and fulfilled their reporting obligations.
Whether each question needs to be mandatory is also worth evaluating, along with whether that information has already been collected, either from a previous year or during the sign-up process. If a question could be optional, it is worth asking whether it still needs to be asked at all.
When Should Questions Appear?
Not every question needs to be asked at once. An eligibility questionnaire can confirm the user meets program criteria, followed by initial questions and progressive disclosure to introduce more as applicants move through the process. Conditional logic or Dynamic Field Visibility Controls can support questions that are not relevant in every situation.
Who Can Access the Data, and for How Long?
Some questions may involve personally identifiable information (PII). Transparency about why data is being collected, how it will be used, and how long it will be retained is important, along with data retention and masking policies and compliance with legislation such as GDPR. Roles with access to specific data should be clearly identified. Hiding certain information from reviewers and decision-makers can help reduce bias related to diversity, equity, and inclusion (DEI). Users may also need to acknowledge privacy and security policies before applying.
Question and Instruction Quality
Once the right questions are in place, it is worth assessing whether they are working well.
How Effective Are the Questions?
Based on the data intended for collection, the responses received should be evaluated for usefulness. If a question is not producing useful information, it may need to be rephrased, clarified, or removed.
How Effective Are the Instructions?
Instructions should be clear and concise without over-explaining or adding complexity. The right format for instructional text depends on context: text below the caption, a tooltip, or an instructions field with role-based visibility permissions may each be appropriate in different situations.
Identifying User Challenges
Uncovering challenges users face as part of their journey starts with reviewing completion patterns: are users completing their tasks, or are application forms being abandoned? Identifying where in the process users run into difficulty is the next step. Several research approaches can help:
- Behavioral — Observe what users do through metrics.
- Qualitative — Understand user motivations and behaviors through usability testing, interviews, and focus groups.
- Attitudinal — Gauge user sentiment through surveys, and examine form information architecture through card sorting.
- Quantitative — Analyze reports, list views, and statuses to identify how many users are struggling and where. Look for patterns in incomplete fields and abandoned application forms.
A SmartSimple system may include many user types: applicants, program managers, reviewers, stakeholders, funders, and administrators. Each role may face different challenges. Users also have varying abilities and levels of experience, so maintaining an inclusive approach throughout is recommended.
Managing Changes
Once user challenges have been identified, the next step is deciding what changes to make and how to manage them.
What Changes Are Needed?
A list of user pain points needs to be weighed against time, budget, and technical constraints. Consolidating the list of challenges and prioritizing by perceived benefit (value), effort, and risk helps focus the work. Changes can range from simple text edits to more complex adjustments involving internal processes or new features and integrations.
How Will Changes Be Implemented?
The implementation strategy may involve internal teams or an external party. If external help is needed, changes may come from SmartSimple (Support, the implementation team, configuration hours, or an RFS) or from a SmartSimple partner. Stakeholder buy-in, timing of communication, and a defined review process are also worth confirming. Features like Versioning, Draft Portal, Batch Update, Autoloader, or the test-to-production (T2P) tool may support the rollout, along with a plan for measuring the impact and success of the changes.
Resources
For more information on application form design, see:
- Configure Custom Fields and Record Layout
- Custom Field Display Settings Reference
- Record Pages Overview