The pre-build design review: what we look for before we build a single template
The pre-build design review: what we look for before we build a single template
Most template projects start at the wrong point.
A design comes in. It looks good. Everyone agrees it looks good. The brief is to turn it into a working Word template, so that's what happens. Six weeks later the templates are delivered, and that's when the problems surface. The custom font doesn't render on half the team's machines. The heading structure requires three manual adjustments every time someone applies it. The beautifully layered layout that worked perfectly in InDesign becomes genuinely difficult to edit once a real user is inside the document.
None of these problems are hard to fix. They're just expensive to fix after the build, because fixing them means rebuilding. Which is why we do a design review before we start.
What the review actually is
It's simple in concept. Before any template gets built, we ask for a PDF of the proposed design and we look at it from a template perspective. Not for aesthetics — that's the designer's domain, and it's usually already resolved by the time a project reaches us. We're looking at how the design will behave once it's inside Word, PowerPoint, or Excel, and whether there are elements that will cause problems once real people are using it under real conditions.
The review is free. It usually takes a day or two. And it consistently catches things that would otherwise become expensive midway through the build.
What we're looking for
The same categories of issues come up repeatedly, which is how we know where to look.
The first is heading hierarchy. A design might use four or five distinct text sizes to create visual rhythm on the page. That's good design. The question we're asking is whether those sizes map to a logical heading structure that a staff member can apply with one click in Word. If the visual hierarchy doesn't correspond to a clean style hierarchy, the user will have to manually adjust size, weight, and spacing every time they apply a heading, which means the formatting will drift the moment someone decides to do it their own way.
The second is font compatibility. Brand fonts are chosen carefully, and they're often beautiful. They also need to be installed on every machine that will ever open the template. If they're not, Word substitutes whatever font it can find, which changes the character spacing, sometimes the line breaks, occasionally the entire layout. For editable templates, we advise using system fonts for body text and editable headings, and reserving the brand typeface for static design elements that aren't going to be typed over.
The third is text box behaviour. Designs often use layered or grouped text boxes to achieve precise visual layouts. In a PDF or an InDesign file, this looks exactly right. In a Word document that a staff member is trying to update, those layered elements become genuinely unpredictable. They shift when clicked. They resize unexpectedly. They sometimes disappear behind other elements. Editable content needs to sit in native Word placeholders, not in floating boxes that behave differently from what the user expects.
The fourth is spacing. A four-point difference in paragraph spacing that's imperceptible in a design tool can cause real inconsistency across a multi-page document. We check that the spacing between headings, body text, bullet points, and table elements is consistent and translatable into a paragraph style rule, rather than pixel-perfect positioning that only holds on the machine it was built on.
Why this matters more than people expect
The things the design review catches aren't design flaws. They're translation problems. The difference between how something looks in a design environment and how it behaves when a real person opens it in Word on an ordinary Tuesday morning, on a machine with different fonts installed, on a different version of Office, with content pasted in from three different sources.
A beautifully designed document that doesn't hold up under those conditions isn't actually a functional template. It's a document that looked right once, when the conditions were controlled.
The review is how we make sure the build starts from a position where those problems are already solved, rather than discovered.
If you'd like us to review your designs
Send us your artwork as a PDF and we'll take a look before the build begins. It's free, it takes a couple of days, and it routinely saves far more time than it costs.