The design should not "guess" the content: The developers in occasions give this task to the template, and they obtain content using the possibilities of the language of templates, when in fact this it is the programmer's task. For example, it is an error to calculate in the template the amounts of the products of an invoice and the total amount, although this it can seem an example of the use of aggregate functions. The language of templates is not conceived to obtain the lacking information, but to make a good design.
The design should be very wrapped to the content and vice versa: Try to balance the content built in the programming, with the content manipulated in the template, so that it doesn't have more than enough content, which the motor has to discard, neither have more than enough template code, which the motor also ends ignoring.
Divide the design as much as it is possible and not so much that it is absurd: Try to build the templates so that they complete the smallest quantity in objectives and that they are the smallest possible, and therefore reusable. Don't build big templates with many conditions where most is discarded. The developers sometimes mix the templates some with other, to have everything in a file and this diminishes the performance of the project. For example, it is not good practice to have two templates in one, prepared for two different contents separated by a since condition this implies to have another decision variable. If you have not found another solution, divide the template in two parts, make a third and use the inclusions or the pre-processed templates. But remember, it is not good practice to have an isolated template that it is included and always for one template, and therefore it is not reused neither conditionally loaded.