Rationale

Why did we put Unify together?

Well, actually, we made it for ourselves from a practical point-of-view. We work hard at creating good user experience, but we work really hard to make sure we communicate that experience as effectively as we can.

But, we’ve also found that across 1,000+ deliverables we’ve reviewed from over 15 UX teams over the past three years, there’s really no need for such a divergent set of deliverable layouts, practices, and inadequacies in our industry. More than anything else, we aim to unify our voice and practice of communicating design, and maybe – just maybe – other teams can benefit from the same baseline. Maybe information architects will become better, together. Maybe our credibility with our stakeholders will increase. And hopefully, as a bottom line, the experiences we create will improve.

We’re fiends for reuse

There’s absolutely no reason to create a new deliverable template for every document you author or every client you work for (unless they require you to). I’d rather spend 95% of my time working on the actual design solution, and have a system at-the-ready so that communicating that design via some deliverable takes little time at all.

Good annotation goes a long way

And you know what? There’s not all that much to creating effective annotations. With a sufficient set of callouts, markers (including a notched marker for more precision), and a set of useful type styles, we’ve got what we need. You’d be surprised, across all the deliverables we’ve reviewed from UX teams over the years, how meager and inconsistent even those basic annotations are.

Make it usable

Because it’s built in, there’s no reason for any document not to have the basics:

• Document name, author, author contact info, version, and publishing date repeated on every single page
• An auto-generated table of contents for all but the shorted documents
• A change history to communicate how a document’s evolved over time
• An effective cover page that slaps you in the face with the document title, clarifying what it is you are looking at
• Page numbers. For goodness sakes, please include page numbers.

All of these elements are incorporated into each document template, and set a foundation for a usable document.

Flexibility widens use and value

There’s a reason that our document templates are bare bones, with just two pages when you open a template: cover page and interior page. Sure, there’s other master pages you can apply (including a chapter page to divide a document into chunks if necessary). But we tend to use our document templates for lots of different things: wireframe reviews, wireframe specs, style guides, competitive analysis, design strategy, contracts, even offer letters to our prospective employees!

Therefore, document type-specific (or, mostly, page layout-specific) facets are abstracted out of the template, instead easily reusable from a library of 100+ page layouts. Want a consistent starting point and structure for a wireframe review? Then use one of our numerous XML-based scripts to rapidly create a document starting point by combining those page layouts and templates for a specific purpose, like a competitive analysis. But make no mistake, the basic templates are kept simple for a purpose.