diff --git a/LUFA/DoxygenPages/WritingBoardDrivers.txt b/LUFA/DoxygenPages/WritingBoardDrivers.txt
index e09e7d0d95..0f5342945d 100644
--- a/LUFA/DoxygenPages/WritingBoardDrivers.txt
+++ b/LUFA/DoxygenPages/WritingBoardDrivers.txt
@@ -8,20 +8,40 @@
*
* LUFA ships with several basic pre-made board drivers, to control hardware present on the supported board
* hardware - such as Dataflash ICs, LEDs, Joysticks, or other hardware peripherals. When compiling an application
- * which makes use of one or more board drivers located in LUFA/Drivers/Board, you must also indicate what board
- * hardware you are using in your project makefile. This is done by defining the BOARD macro using the -D switch
- * passed to the compiler, with a constant of BOARD_{Name}. For example -DBOARD=BOARD_USBKEY instructs the
- * compiler to use the USBKEY board hardware drivers.
- *
- * If your application does not use *any* board level drivers, you can omit the definition of the BOARD macro.
- * However, some users may wish to write their own custom board hardware drivers which are to remain compatible
- * with the LUFA hardware API. To do this, the BOARD macro should be defined to the value BOARD_USER. This indicates
- * that the board level drivers should be located in a folder named "Board" located inside the application's folder.
- *
- * When used, the driver stub files located in the LUFA/CodeTemplates/DriverStubs folder should be copied to the user
- * Board/ directory, and fleshed out to include the values and code needed to control the custom board hardware. Once
- * done, the existing LUFA board level APIs (accessed in the regular LUFA/Drivers/Board/ folder) will redirect to the
- * user board drivers, maintaining code compatibility and allowing for a different board to be selected through the
- * project makefile with no code changes.
+ * which makes use of one or more board drivers located in LUFA/Drivers/Board, you must also indicate which
+ * board hardware you are using in your project makefile. This is done by defining the BOARD macro using
+ * the -D switch passed to the compiler, with a constant of BOARD_{Name}. For example,
+ * -DBOARD=BOARD_USBKEY instructs the compiler to use the USBKEY board hardware drivers.
+ *
+ * If your application does not use any board level drivers, you can omit the definition of the BOARD
+ * macro. However, some users may wish to write their own custom board hardware drivers which are to remain compatible
+ * with the LUFA hardware API. To do this, the BOARD macro should be defined to the value BOARD_USER.
+ * This indicates that the board level drivers should be located in a folder named "Board" located inside the
+ * application's folder.
+ *
+ * When used, the driver stub files located in the LUFA/CodeTemplates/DriverStubs folder should be copied to
+ * the user application's Board/ directory, and filled out to include the values and code needed to control
+ * the custom board hardware. Once done, the existing LUFA board level APIs (accessed in the regular
+ * LUFA/Drivers/Board/ folder) will redirect to the user board drivers, maintaining code compatibility and
+ * allowing for a different board to be selected through the project makefile with no code changes.
+ *
+ * \section Sec_BoardTemplates Board Driver Templates
+ *
+ * The templates for each board driver are reproduced below.
+ *
+ * \subsection SSec_BoardTemplates_Board Template for USER
+ * \include "DriverStubs/Board.h"
+ *
+ * \subsection SSec_BoardTemplates_Board Template for USER
+ * \include "DriverStubs/Buttons.h"
+ *
+ * \subsection SSec_BoardTemplates_Board Template for USER
+ * \include "DriverStubs/Dataflash.h"
+ *
+ * \subsection SSec_BoardTemplates_Board Template for USER
+ * \include "DriverStubs/Joystick.h"
+ *
+ * \subsection SSec_BoardTemplates_Board Template for USER
+ * \include "DriverStubs/LEDs.h"
*/