When designing themes for clients, I try my best to make them as modular and flexible as possible. Put another way: with a well built theme, my client should be able to create new pages of any type with the confidence that they’ll all work properly. In 2015, you shouldn’t need to contact your web designer to add a page to your site — it ought to “just work.”
To achieve that goal, I force myself to do as much of my development as possible at the theme level, rather than at the page level. What’s the difference? When you commit code at the theme level, that code applies consistently across the theme; when you make edits at the page level, your changes only affect that individual page — and moreover, it turns that page’s code into a sort of island (future theme updates and fixes won’t be applied). The more you use page level edits, the less extensible and the less updatable your theme becomes.
So what are you to do then? Never deviate from NationBuilder’s default page types? Have no custom page layouts? Of course not. You can exercise a great deal of flexibility at the theme level, particularly if you use “if statements” to narrowly target certain page types, etc. For example, on my recent redesign of the Young Professionals in Foreign Policy website we decided that — rather than develop a fancy, hard-to-maintain page-level template — we’d use NationBuilder’s “FAQ” page-type for the staff page. It’s great: each team member’s bio gets its own permalink page, but they’re also all displayed in an easily-reordered list. But there was one problem: each team member’s bio would be prefixed with the “Answer:” label.
To fix the issue, I could have edited that page’s page-level template to remove ”Answer:” from the code. It would have worked. But instead, I edited the theme level template for FAQ pages to hide the text unless the page’s slug contained “faq”. This approach is flexible and extendible. If we want a genuine FAQ page, we just need to include “faq” in the page slug and the proper labels will appear. Otherwise, we have a whole new page type — a bulleted list of items and descriptions, perfect for a staff page, issues page, list of programs, etc. — that’s available to the staff without ever editing any code.
The point here is that you want to be as forward-thinking with your theme development as possible. By editing at the theme level, rather than the page level, you’ll save yourself from a lot of medium- to long-term maintenance headaches. And perhaps more importantly, you’ll build your theme in a way that’s extensible — allowing you, and your clients, to build your site over time with the confidence that it’ll “just work.”