Specify how your app should work. With an outline, an Afterpattern developer can quickly deliver a prototype of your app.
What an outline includes:
A variable spreadsheet; and
Copies of the documents (if any) your app is going to auto-populate with labels indicating where the variables will go.
What an outline does not include:
Explainer text
Images or videos
Style choices
These things are important but they can be added later. The purpose of an outline is to build a functional prototype of your app.
In this guide:
Background: An intro to variables
Part 1: Variable spreadsheet
Part 2: Document templates
The essential purpose of your outline is to describe what information is required to populate your chosen document templates. Each piece of required information is known as a "variable."
How do you identify a variable? i.e. how do you identify all the pieces of information your App needs to collect in order to populate its document templates?
The answer: look at your documents.
Sometimes, it's obvious from looking at your document what pieces of information are required. For example, to populate this section of a document it's obvious the App needs to collect the end-user's name and an address:
But what about this section: how does the App know where to populate the end-user's name?
Does the name go on top of "Petitioner" or "Respondent"? To answer that question, the app requires an additional piece of information: the end-user's role in this legal matter.
The lesson here is that not every piece of information your app requires is a "blank space" on the document template itself. Sometimes, your app requires meta information which is then used to populate a "blank space" with another variable.
In the example above, the variable 'user_role' is a meta piece of information that is used to determine where the variable 'user_name' will be populated, i.e. above the line for "Petitioner" or the line for "Respondent."
The variable spreadsheet is a list of all the information required by your app in order to populate your chosen document templates.
Get started by downloading this spreadsheet template.
The spreadsheet has two tables:
Table 1 is where you'll describe those variables that are defined by asking the end-user a question. This is how most of your variables will be defined.
Table 2 is for describing variables that are defined by logical reasoning or by pulling information out of a database.
Add each variable that you want to define with a question. For each variable, you can include the following information:
Each page of your App is known as a "Block". A single Block can include multiple questions. Use this column to group questions across multiple Blocks.
Most variables will be defined with a question. For example "what is your name?" or "how are you going to deliver these documents to the other party?" (note: you don't need to be so verbose; oftentimes, question labels can be as simple as "name").
Different types of questions are appropriate for different types of variables. For example, if you want to ask the end-user "do you have any children?" a 'True/False' type question is more appropriate than a 'Short Text' question.
Some important notes about question types:
If the question type equals 'radio' or 'checkbox', use this column to list the multiple choice options. Separate each option with a comma.
Coming up with a good variable label is a subtle but important step. Although the only rule is no symbols, we recommend using prefix + underscore to indicate when a variable is part of a group (e.g. user_name, user_phone, user_address).
✅ Excellent variable labels
❌ Bad variables labels
Not all questions have to be asked of the end-user. For example, you may only ask the end-user for their spouse's name if they indeed have a spouse.
If you want to conditionally ask a question, use this column to communicate when that question should be asked. There is no wrong way to write this logic; try to be as clear as possible.
This is a catch-all for any comments / notes you'd like to add. For example, if you want to conditionally display some text depending on how the end-user answers a question, you would describe that here.
You can ask the end-user the same question multiple times. This is the best way to collect information about an undefined number of people/items/things.
The classic use-case for repeating questions is collecting information about the end-user's children. For example, you can have a Block that asks for a child's name and date of birth, and then you can allow the end-user to repeat over that Block for each child they want to add:
In the above example, the questions 'Name' and 'Date of birth' are repeated.
Although questions are the most common method for defining variables, it is not the only method. There are two other options for defining variables:
Example of logical reasoning: The variable ‘Petitioner’ can be defined by two sets of logic depending on the user’s path: 1) if ‘how-paternity-established’ is “The father signed a Paternity Affidavit” then ‘user_name’; or 2) if ‘user_role’ equals “Petitioner”, then ‘user_name’, else ‘other_parent_name.’
What this is saying is that 1) if the user selected “The father signed a Paternity Affidavit” then ‘user_name’ is automatically the Petitioner; or 2) if the variable ‘user_role’ (which should be defined elsewhere in the App) equals “Petitioner”, then ‘user_name’ equals ‘Petitioner’
Example of pulling information from a database: You could have a database with information about courts (address, phone number, etc). Imagine you then have a variable in your App called 'court_address'; this variable could be defined by looking up the appropriate court in your database.
Go through your document(s) templates and add a variable label for each piece of data you want to populate, including text, checkmarks, and signatures.
For PDF templates, use the Adobe Acrobat 'prepare form' feature to add labels to the PDF fields:
For Word templates, designate a variable by wrapping it in double brackets, e.g. {{ user_name }} or {{ user_street }}:
