Simple Form Fields and Big Buttons
My Children Info form
Sign and Submit
Required Statements with Summary
Features and Functionalities The notable features and functionalities behind the application
autopopulating: if a user states that they have five children, they must fill out information for five children. this prevents users from leaving out anyone.
progressive disclosure (a variation of it): the application only shows one form field at a time to prevent the user from becoming overwhelmed
gated form advancement: the form doesn’t allow users to simply jump to whichever section they feel like. only when the user has filled out the form with valid information is the option to continue available.
activate select form fields. Users click to add select form fields if a section applies to them. For example, rather than show all the form fields for a ton of income sources, users can add the ones that pertain to them.
Approach to the Design & UX The design started with a few personas in mind. First, I wanted to design a system that could accommodate a family with a very simple scenario. The second persona was someone whose situation might be complex, such as having multiple income sources. If it doesn’t take the person a long time to fill out a form on paper, then it should be equally fast online. For someone with a more complicated situation, the form was already complicated. How could the system also allow for the type of unique circumstances of income that might be true of that family?
Keeping these users in mind, I went through and tried to understand the entire form. Mapping out the architecture of the form, especially of the complicated sections such as income.
Prior to designing the form’s mockup, I did the following;
- I also prototyped a sample form using standard online form components to get a feel for the experience of filling out the form online
- Prior to reading the household scenario matrix, I created a flow chart on my own to understand how different users might flow through the system based on the various resources provided by hackathon. Then I compared my flow with the matrix to ensure my flow, at the very least, accommodated the cases presented in the matrix.
- Lastly, I created a mockup in Sketch which allowed me to begin fitting the functions and content onto a single interface
For the UX, I used a few key innovations that provide advantages over paper:
Keeping information overload at a minimum. For example, gradually showing additional questions and form fields makes filling out the form less overwhelming. At the same time, as soon as sections were finished, they collapsed as the user proceeds to fill out similar data.
For the required statements that had to be included, I also wrote an example of a summary which can be used to help users understand the passage without needing to read it themselves. Unlike most other lengthy legal documents, these required statements actually have useful information so I wanted to make sure users at least saw some nuggets of information rather than skip to the next section.
Maximize efficiency for users. 1) the system bypasses the user from the allow users who can skip sections. I followed the main scenarios to ensure that users enter as little unneeded information as possible.
Solve the primary problem of users forgetting to include information. To avoid a painful experience for applicants, I wanted to balance efficiency while ensuring completeness of information.
The issue mentioned above is most complicated for income information. Users have to add multiple income sources, keep track of different frequencies of receiving income, and sum everything up. The approach here was to group the different sources of income. For the most common sources of income, the form shows up by default. For sources of income that are likely from individual to individual, users are given the option to add the choice that they want. If none of these apply to them, they can proceed to the next section.
Rather than forcing users to confirm each individual income source, at the end, the application requires users to confirm that they are sure that the income answers are accurate. This encourages users to review their application without being overbearing.
As much as possible, I didn’t want the user to have to do any calculations or cognitive outside of locating their information. For example, the paper form currently requires users to add up all the totals on their own and input the total into the form. This system only asks users to input the information, and it does the calculations on the backend.
At the beginning of the application, there is a pre-application survey. This pre-application survey serves three different purposes: 1) make application seem shorter and 2) encourage users to think about their answers and 3) create a system of automatic checks on the backend allowing for error checking and auto-populating the correct fields.
Simplicity of form fields. Where possible, I used big form fields and radio buttons. These form fields should resemble the paper format as much as possible not only because they’re good design patterns but also because some users may not be as computer literate. Getting to cute or fancy with the interactions could actually make it easier for pro users while worsening the experience for people who are don’t surf the web regularly.