How to Design a Front-End Application
All the steps and considerations when building a form to collect an applicants information.
This guide is written with the Dynamic Application in mind. The process for the static application is nearly identical, but you'll need to gather the associated data for each risk and coverage parameter from the Appendix.
To design a front-end application, you'll need to have a good grasp on risk and coverage parameters. To refresh your memory, an application is essentially a series of questions for a set of products, categorized as risk values (each question is a risk_parameter) and coverage values (each question is a coverage_parameter).
Since the Dynamic Application is….well, dynamic, Herald provides metadata for each parameter to help you render them on-screen with proper validation.
In this guide, we’ll teach you:
1. Format Each Question
For every risk and coverage parameter, we’ll include some useful information to help you render it on screen. The 3 pieces of metadata you should use when formatting individual parameters text, schema, and input_type.
Any number of conditional questions can appear when using the Dynamic Application, so it’s important to build logic to handle every situation. For the most part, parameters are either text inputs, number inputs, multiple choice questions, or objects. We strongly recommend having unique styling in place for each of the 14 input types.
Let’s take a look at a few different parameters based on their input_type.
2. Render Nested Questions
Since some questions have a parent/child relationship, it’s important to visually communicate this hierarchy. You’ll also need to associate the child parameter with the parent when submitting values, with the child parameter nested beneath the parent. Child parameters are nested under the parent in an array:
Let’s use the example of an applicant with multiple locations. The applicant may have different class codes under each location, like a manufacturing plant in a San Francisco location and a sales department in Los Angeles. In the application response, each location will have a class code nested below it within the child_risk_values array.
It’s important to render each class code visually below the correct location. This way the applicant knows which class code to submit for each instance of class code. Otherwise, they could see 2 class code inputs without the context of what each of them are for.
This segues nicely into our next step.
3. Allow Multiple Values
Parameters that can have multiple values have the property creates_array: true. Inherently, parents parameters can have multiple values, because the child parameters are related to a unique instance of the parent. Many parameters support multiple values, some examples of this are:
- Class code for a specific location. Some applicants have multiple locations, performing different types of work at each one.
- Payroll for a specific class code. Some appliances have multiple professions, and are required to submit an exposure basis for each one.
- Property Limits for a specific building. Some applicants have multiple buildings, and have the option to choose unique limits for each one depending on its size and value.
- A field for domain names, that allows for applicants with multiple domains.
By default, The Dynamic Application only provides 1 instance of each parameter. You can generate additional instances by following the steps in our guide to using instances.
To build a front-end that supports multiple values, you should pay attention to the following metadata: creates_array, instance, and required_for.
To support these cases, your application should support the ability to add and remove instances. All parameters with the property creates_array: true support multiple values. Let's continue with our same example from above. Class code, which is a child of location, can have multiple values to support applicants that perform work across multiple industries.
To power this feature on your front-end, we recommend building logic to:
- Render an Add + button for each parameter that has creates_array: true. When clicked, a new instance should be created. Steps for creating instances are documented here.
- Render a Remove - button for each creates_array: true parameter when multiple instances are present. This feature must be restricted when only 1 instance is present. Steps for deleting instances are documented here.
Here’s an example of how a front-end could power this functionality:
It’s important to build this logic to globally support parameters with creates_array: true, not on a parameter by parameter basis. Here’s a matrix of how this logic would render different questions on screen based on the parameters value of creates_array:
When adding and removing inputs on your front-end, you should also be adding and removing the parameter in your application body. Each individual instance of a parameter will have a unique instance. Our guide to using instance outlines how to use this property to map the correct value to the correct instance when filling out an application.
4. Update the Application
As we discussed at length in our Dynamic App doc, the dynamic application handles conditionality for you. As you collect and submit values, additional conditional questions can come back. Any risk or coverage parameter that can potentially yield additional parameters is given the property affects_conditions: true.
As you update your application and receive new questions, you’ll need somewhere to put them! Some ways we’ve seen this handled:
- You could render them on the same screen as you continually update the application, making a PUT request after each value is entered.
- You could collect the values for the initial set of questions, make a PUT request, and put the next level of conditional questions on the following screen.
- You could ask each question 1 step at a time for a more conversational approach, inserting each new question with a null value in a following step.
Continuing with our example, we’ve now added a class code input below Location, with the ability to add multiple class codes. Since class code has affects_conditions: true, let’s update the application and see what comes back.
Conditional questions can come back anywhere after each update, they are not always placed at the bottom. For example, if State is question [ 1 ] and Name is [ 2 ], a conditional question based on State could be returned below [ 1 ]. In this case, Name would now be placed as question [ 3 ].
5. Build Front-End Validation
Alluded to Herald includes a schema object to describe the expected value. This property can help render items like enum values on screen, but it can also power front-end validation. Depending on the input_type, schema can define things such as:
- Min and max values for number inputs.
- Patterns, for inputs such as phone number.
- Max characters, for things like FEIN number.
You can use the information denoted in the schema to power your own front-end validation. Here’s a few examples:
6. Decide Which Questions to Require
A risk and parameter can either be optional or required depending on the product and event you are tracking toward. This is conveyed using the required_for array. If it is required for quote, it will be required_for: [”quote”]. If it is optional, the array will be empty like this [ ].
There is a chance that optional questions will still be required to bind a policy when you bridge to the carriers portal. If your goal is simply to get quotes in your platform as quickly as possible, you could choose to only show required_for: [”quote”] parameters. If you want to make a seamless experience after going to the carriers portal, it may be better to ask all questions up front. Here’s an example of how this appears in the application response.
7. Structure Your Application
At last, it’s time to decide how to structure your application. Herald provides you with metadata to build an application that works for you. The most basic form of rendering our Dynamic Application response on screen is by making a 1-page application, where conditional questions appear on the same screen as updates are submitted. If a 1-page application works for you, you can simply make a PUT request every time a value is entered into an input.
If you’re looking to build a fully integrated application with an existing front-end, where you’d like to pick and choose where to place each individual question, our static application might be best for you. But we’re continually looking to improve our Dynamic Application API to support more use cases. If you’re still deciding what to build and want to chat, reach out!