Once you are in your project, you can navigate to the Project setup section, which is effectively a checklist for your project.
Scrolling down will give you an easy stepwise procedure for building your project.
REDCap is intuitive, so clicking on the will give you further explanation on what each aspect involves.

By default, a project will begin in 'Development mode', what that means is that any changes to the project will be made instantaneously as the project is still in the process of being developed.

Surveys

If you would like to utilise surveys, you can enable that functionality here.
A survey enables an instrument to be completed without the respondent needing access to REDCap itself (a link will be created allowing anyone who completes it to contribute data to your project).

To learn more about surveys, there is a more detailed 'REDCap Survey Guide' PDF that can be located in the additional resources. For a video tutorial on creating and managing surveys (5.5 minutes duration) click here.

Longitudinal data collection

Longitudinal data collection allows you to implement a project for a longitudinal study with multiple events.
For example, if you are collecting data for the same instrument (set of questions) at 7 different time-points, you can create 7 events in REDCap and designate that instrument to be tested at the 7 different time-points.
In the example below, there are 7 weekly events where I am collecting data for the 'Research Diary' instrument:

If you selected a longitudinal database when creating a new project, it will be enabled, otherwise you can enable longitudinal collection here in the project setup tab.
Once enabled, you can define your events and designate the relevant instruments to the events in which they will be collected. (More detail is provided on this in Step 3)
Click this box if you would like to see the longitudinal section from Step 3 now.

Longitudinal Data collection
Firstly, the events need to be defined through the additional step that appears for longitudinal projects:


Click here for a video tutorial (5.25 minutes) on defining longitudinal events.
Below is an example of a longitudinal project with 7 events defined.

Once completed, any instrument can be designated to the relevant event in which they will be utilised in the 'Designate Instruments for My Events' tab.


In Step 3 (now step 4) under optional modules and customisations, there is the capability to use a scheduling module. 

Scheduling Module:
If a longitudinal project is enabled, the scheduling module can utilise the defined events in the project to link into the calendar to allow for better project management. 

By enabling the scheduling module, you can program in the defined events into the calendar using the days offset column. Click here for a video tutorial (7 minutes) on the Scheduling module.

Scheduling module:


Calendar with scheduled events:

Calendar preview in project home page:

There are a couple of options to design your project, the easiest is via the online designer.
The other option is via the data dictionary which is essentially an excel file of the fields (questions) structured in a certain format. Once you have some fields in your project and wish to make bulk changes you can use the data dictionary to quickly make these changes.

One of the reasons for creating separate instruments is the capability of restricting access to specific data to certain users.
For example, if sensitive data is being captured in 'My First Instrument', you can limit which users have access to that instrument, either to view and/or edit data. This can be done via user rights which is one of the later steps in the project setup.
 
Other reasons for separating forms into instruments could be to:
- utilise surveys, which allows a link of the instrument to be sent, allowing the respondent to complete it without needing to login to REDCap. 
- collect data at certain time-points, such as in a longitudinal project or repeated when required by using the repeating instruments feature.

To modify an instrument, simply click on the instrument's name.

Once inside the instrument, you will have the ability to add fields into the project.
If you are modifying the first instrument in your project, there will already be a field for the Record ID.

This field can be modified but cannot be deleted as it allows you to identify the records in your project.

To add a field simply click on  

Adding a new field

What are the different options when making a field?

Field label: The text that will be placed on the page, most often times will be the question that you wish to ask.

Action Tags: Tags that can be attached to the question to customise the data entry experience.
For example, hiding questions or answer choices, setting the default value for a field, tagging a multiple choice answer as a 'none of the above' option, setting word or character limits, making a field read only.
For an online tutorial you can visit the following page: Action Tag Demo (+piping)

Variable Name: Short name of the field label to refer to the field in the project.
(A variable is often referenced throughout a project in calculations or other features such as piping (examples in the action tag demo above) using square brackets []).

Validation (only for text boxes): 'Validates' text boxes, forcing the data to be entered in a certain format. More detail is provided in the next section.

Required: Marks a field as required . If marked as required and left empty, a prompt is provided upon the completion of an instrument.

Identifier: Marks a field as an identifier which allows it to be removed when exporting de-identified information from the project.

Custom Alignment: Provides options for the orientation of the field.

Field note: Small text that will be shown directly underneath the field which can function as a reminder or instruction for data entry.

For text box fields, the following validations are available:


Free text fields should be validated where possible.
For example, it would make sense to capture dates using date validated fields to ensure that dates are actually captured, which allows for easy comparison and filtering of data. By capturing validated dates, these can then be used elsewhere in the project eg. to carry out calculations.

Below is an example of date validated text boxes where admission and discharge dates are captured using D-M-Y (date-month-year) format. These dates are then used in a calculated field to calculate length of stay rather than manually typing the length of stay which introduces a potential source of error.

Calculations

To create a calculation, select a calculated field type and enter the calculation equation in the designated box. You do not need to remember formulas, if you wish to input a calculation, clicking ‘How do I format the equation?’ will bring you to the REDCap Help & FAQ Calculations section to assist you with formatting your equation. If you have any test records with data, you can test the calculation at the bottom to check if it is working. Alternatively you can test the calculation by entering data in a record.

By selecting a numerical validated field for numerical responses, additional parameters can be placed such as a minimum and maximum.  

For dates, there is a limitation that the minimum and maximum might shift based on the current date. For example, the admission and discharge dates cannot be in the future so the minimum and maximums would depend on the current date.

Data Quality
In instances where the data restraints fall out of the custom default validations provided by REDCap, you can utilise the module. Data quality rules can be run to assess the project for any data quality discrepancies. They can also be enabled for real-time execution (ie. to appear during data entry).

Below is an example of a data quality rule that I've set up to provide a warning if the admission date entered is in the future:


I have named this rule 'Admission date is in the future'.
The logic I have used is based on the datediff calculation, comparing the admission date ([admission_date]) with the current date ("today"): datediff("today",[admission_date],'d','dmy',true).
If the calculated value is >0, there is a discrepancy, indicating that the admission date is after 'today's' date.

Since real time execution is enabled, if a page is saved where the admission date is after the current date, a warning will pop up informing the user of the violation.

For this data quality rule, the following calculation was used: datediff("today",[admission_date],'d','dmy',true)>0.

Similarly, to prevent a date from the past being entered, the following calculation could be used: datediff("today",[admission_date],'d','dmy',true)< 0.

Questions with pre-defined choices

For questions with pre-defined choices, each answer choice will need to be coded.
The codes will be separated from the answer choice by a comma(,).
This code can then be used in calculations or other areas in the project where the answer needs to be referred to in a logic, for example, in a calculation, branching logic or report filter.
When exporting the raw data of the project, the codes will be shown (for data exports there is also the option to export the label, which is the actual answer not the code).
Examples of the codes are given below for the Yes-No and True-False questions which are not modifiable:

The other field with non-modifiable options is the Slider/visual analog scale which is on a scale from 0-100. An example of its utilisation is below:

Multiple Choice Questions
Multiple choice questions allow the project user to define the choices in the question.
In this following example, a respondent can only have one country of birth so I have chosen the single answer field type. Since there are over 100 choices, I have selected drop-down list over radio buttons. This saves space on the screen since the drop down answers only appear when clicked as opposed to the radio buttons which permanently appear on the page.



I have also enabled auto-complete for this drop-down. The result is that I can either click and scroll down the list or begin typing country of birth and the options will narrow down to the relevant options for selection:


Utilising a multiple choice question when you know the potential or expected answers is much more productive than utilising a free text box since the answers will be automatically grouped for analysis.
For example, everyone who selects Australia will automatically be grouped into the Australian answer. Utilising free text opens you up to potential issues such as spelling errors which means answers may need to be changed to the correct spelling prior to being used.
Using multiple choice options allows you to utilise the real-time stats and charts of the data in the project:

Multiple Choice Checkbox questions

The final multiple choice question to highlight are checkboxes, which provides options with square boxes instead of the circle radio buttons.
Checkbox questions allows multiple answers to be selected:

Clicking the green button will open up the branching logic options. I can use the 2nd option, the drag-n-drop builder to look for the question and answer I would like to link it to. If I select multiple answers to link it to, I can choose to show the field only if all are true (AND statement) or any (OR statement). Using the drag-n-drop builder automatically populates the logic at the top, which is the alternative and more advanced way to setup branching logic.

Optional modules and customisations
Step 3 is a set of optional modules and customisations that can be setup.
Short explanations are provided below, but once again, you can click the next to the relevant options in REDCap for more information.

Repeatable Instruments
Repeatable instruments allow you to repeat a data collection instrument as often as you would like. In contrast to a longitudinal setup where you define set timepoints to collect data, repeatable instruments have no designated timepoints or limitations for data collection. For example, if you require ad hoc collections for instruments such as diary entries, a repeatable instrument will allow you to create a new instance of the diary instrument when required:

Auto-numbering for records
Auto-numbering for records automatically assigns a new record to have the next numerical increment from existing record values. If no records exist it will begin with '1'.

Below is the page for adding/editing records with auto-numbering enabled:


The add/edit records page will differ based on the setting.
When auto-numbering is disabled, a user will be able to type in an ID, if this ID already exists, it will take them to that record, if it does not, it will take them to a new record with that ID for creation.

Page for adding/editing records with auto-numbering disabled:

Scheduling Module:
If a longitudinal project is enabled, the scheduling module can utilise the defined events in the project to link into the calendar to allow for better project management.

Longitudinal Data collection
Firstly, the events need to be defined through the additional step that appears for longitudinal projects:


Click here for a video tutorial (5.25 minutes) on defining longitudinal events.
Below is an example of a longitudinal project with 7 events defined.

Once completed, any instrument can be designated to the relevant event in which they will be utilised in the 'Designate Instruments for My Events' tab.


By enabling the scheduling module, you can program in the defined events into the calendar using the days offset column. Click here for a video tutorial (7 minutes) on the Scheduling module.

Scheduling module:


Calendar with scheduled events:

Calendar preview in project home page:

Randomisation: 
The randomisation feature allows records to be assigned to different groups based on chance. It's most common use would be in clinical research or clinical trials where a patient is randomised to a particular treatment.

Email field and Twilio for surveys
The following two options allows REDCap to send survey invitations via email and phone respectively.

Designating an email field for surveys requires a field that is validated as an email field. This will allow an email to be listed in the survey distribution tools. If this is enabled, survey confirmation emails in public surveys will be automatically sent rather than asking the respondent for their specific email at the end.

Twilio allows you to make and receive voice calls and SMS text messages, this modules utilises a third party service called Twilio, which has small costs associated with it.

Additional Customisations
In the additional customisations section, there are other features you can utilise, the explanations provided being self-explanatory.

Bookmarks are another optional customisation that can be utilised in the project.
Potential uses for bookmarks could be to highlight particular pages for data entry personnel or shortcuts to commonly used reports. An example use is below.

User Rights
User Rights allows you to control the access levels of each user in your project.

The picture below shows some of the options in user rights:

Data Access Groups

Data Access groups are an additional way to limit the access of users.
In Data Access groups, users are limited to accessing the data of records from their particular data access groups.
Any records they create will also be added to their specific data access group.
A common use case is multi-site studies.

Click here for a video tutorial (7.3 minutes) on Data Access groups.

In the example below, I have created access groups for 8 different sites. When users are assigned to their relevant group, they will only be able to see records from their own group whilst contributing data to the entire project. A user not assigned to any group would be able to see all the records.

Testing a project

It is important to test your project to check that it works as expected. As mentioned above, pay attention to whether branching logic and calculations work as expected. To test these functions, create dummy records. Records can be created via the Data collection tab utilising the record status dashboard or add/edit records options.

When testing, it is important to enter data as though you are capturing real data and consider the types of answers that can be provided based on how the questions are currently asked.
For example, if you are asking multiple choice questions and a common answer you wish to select is not actually an option, then you can add the response as an option.

Other things to look out for are the validation of your fields and the quality of the data you are capturing. For this, it is useful to test the entry of implausible data. For example, if you are capturing height in cm, it would be advisable to create limits for appropriate maximums and minimums in cm. This would prevent any outliers from data entry errors, which would require the data to be cleaned prior to analysis, such as the entry of height in metres or wildy incorrect typos, the latter being difficult to rectify without the original data source. The project should be created in a way to ensure that only plausible data can be entered where possible. This is where testing and implementing data quality rules will be vital.

Basic things such as whether your questions have typos or make sense should also be considered.

It is also important to test out the practicality of your data collection process. Testing out the data collection process is important to nut out any workflow issues. If you have multiple staff working on a project, will the process of creating a record in the project work? Does every user have the appropriate access based on their role in the project?

If you plan to run specific reports on a regular basis, it is important to test these reports to see if your project has this streamlined.

For an example of some testing in action, please see the Introduction to REDCap Presentation between 37:52 and 49:10. 

If you are interested in specfic tips regarding project testing considerations, you can have a look at this guide.

Production Status
Once testing is completed, it is important to move your project to production status.
Production status effectively signals to your project that real data is being collected and additional measures are in place to protect your data.

If you have tested real data whilst in Development mode and would like to keep this data, you can choose to keep this data when you move the project to production mode or start with a blank slate of data.


The main difference in production mode is that changes to the project are not necessarily instantaneous.
To make changes in the online designer, a user would need to enter draft mode:

Once changes are drafted, they will need to be submitted for screening.

For example, if you delete a question that already has data collected, this will be flagged. In development mode this change would be instantaneous. In fact, any changes to the project that affects existing data will be flagged and cross checked by the REDCap administrator prior to being applied.

An example of an existing question with data collected is below:

If we decide to add purple as option 4 with the code 4 (eg. 4, Purple) then the change would not affect existing data and will be approved.
However, if we give purple the code of 3 instead of 4, all existing answers that were coded 3 for yellow will still retain their code of 3 but instead of representing yellow will now appear as purple. As a result, this change would be flagged to the REDCap Administrator before being implemented. If a user is set on using 3 for purple, then any existing answers coded as 3 will need to be recoded.
If a user wishes to just have purple appear as the third option in the list they could still do this by placing it with a new code in the 3rd position like below: 

This addition would not affect existing data.

Any changes to the database that do not affect existing data will be applied when submitted. An example of this change is the addition of an entirely new question.