Think about the word deliverable. It implies something you deliver, carrying a certain sense of finality. The word is also singular. In my experience, neither is true. Deliverables that I author are iterative and rarely have a designated “final” state. To date, I’ve never published a “final” deliverable that didn’t end up having another iteration published a day or two later.

That iterative nature also implies that a deliverable doesn’t occur just once, but over and over again until you’ve tuned it just right (or, you’ve moved on to another project). So much of this iteration is triggered through involvement of different audiences over a project’s life cycle.

So it’s worth asking: should you create a single artifact that you evolve, expand, and enhance over a project life cycle? Or should you try to communicate via more specific deliverables targeted to each audience?

Deliverable Life Cycle

I know, I know. It depends. We all work under constraints on unique projects for different audiences blah blah blah.

But this is a critical question since most of my time communicating user experience follows this general design life cycle:

1. Form a conceptual vision for an experience. Outputs: models, stories, maps, rough wireframe concepts
2. Refine the story via focusing on a core experience path or key cases. Outputs: moderately refined wireframes, flows, maps
3. Illustrate variations of key pages and call out specialized but likely conditions. Outputs: near-final wireframes with variations, light annotations
4. Document deeper details and fill out the design. Outputs: final wireframes, deeper annotation, spec for behaviors & conditions, use cases, error messaging, and more

This is a common progression from high-level to low-level design process, regardless of calendar time or project purpose. While variations on this theme are innumerable, it’s nature should be very familiar.

Audience

Yes, this question comes down to audience. We’re user centered designers, so we should be comfortable creating a (deliverable) user experience that meets those varied needs.

During a deliverable’s life cycle:

• The IA is the only audience that cares about every bit of information in it
• No audience is present every time it is consumed
• Project participation for a specific audience will ebb and flow

I’ve found each audience has their own unique objectives when consuming a IA deliverable:

Product owner
Objective: Know - and focus on - what’s going to “move the needle”
Your Task: Tell the story, align it with business goals, and establish the confidence that everything else will be “taken care of.”

Visual design
Objective: Know how the experience aligns with or provides structure for their polished visual system
Your Task: Provide a basis for mockups, answer key questions, and monitor that presentation aligns with structure and behaviors

Engineer
Objective: Understand how to build the system of interactive behaviors, data feeds, variable conditions, and more
Your Task: Provide a comprehensive, documented view into system function, identify edge cases & expectations, and create mappings to whatever other inputs they receive

QA
Objective: Write test cases
Your Task: Provide a structured, comprehensive view of cases, behaviors, exceptions, and more that they can build from and you can audit later

Copy editors
Objective: Write copy
Your Task: Identify content you’ve intentionally crafted (and they don’t touch), suggested (and they can polish), and left crude (and they write from scratch). And oh yeah, make it so they can “fill in the blanks.”

Thresholds

Information architecture authors must be keenly aware of thresholds of their audiences.

Going down, it’s that line of further details and specifications that product managers and visual designers will object to cross. No matter how hard you try, you can’t make ‘em read it. In creeps that glossy, blank stare. Or worse yet, your finely tuned details that generate a “Can you explain this to me like I’m a two year old?”

Going up, there’s a different threshold of illustrations, concepts, and product strategy that QA and engineers don’t - or generally shouldn’t - care about. Personas, conceptual models, and high-level storyboards help neither engineers write code nor testers compose test cases. So often its that first dev/QA review that you want to set the tone for a build, but after an unresponsive intro you skip the concepts and dive to details.

Such thresholds go both ways. So ask yourself, does your deliverable design keep that in mind?

Interestingly, some high-level illustrations actually apply to all levels, such as a site map or navigation that serves a guide for explaining the story and setting a referenced roadmap.

What do IAs do?

Well, most folks I see have a “all content for one deliverable” model. For this, they’ll iterate a single deliverable during the project life cycle and add more and more outputs over time.

This deliverable intermingles many layers of detail together. Sometimes, chapters may emerge to divide introductions, strategy, flows, and all other detail. Hopefully, conventions arise for describing an interaction, illustrating a state, or listing error messages. But almost always, these “wireframe documents” combined general descriptions with error messages with behaviors with variations with data attributes with display condition with so much more.

The result? A deliverable almost never engages each audience via a scannable, targeted experience. More likely, it disables each audience from easily consuming what they care about without muddling through everything else. Worse yet, it’s a aggregation of so, so, so many words. No one wants to read so many words. So the deliverable doesn’t get read.

What could you do?

Well, in today’s workflow and toolset(s) that most folks use, your opportunities will require change and investment. We live in a single “all for one” deliverable model because of time, money, and scope. It takes too much time to craft deliverables for each audience and maintain synchronization of each of those artifacts over time. Change is hard, you’re making a good living now, so you can keep doing what you’re doing.

But there are some things you could do.

First off, spend some time redesigning your deliverable. Think about those audience needs. Scan your current documents and imagine yourself as someone from QA, and then a product manager. Woah, that’s often eye-opening, considering those audience objectives.

Then dive in and create reusable templates and structures that enable you to add detail with intentional, strategic, audience-based context rather than tactical, reactionary needs to document something somewhere. And then test them with your most valuable colleagues and consumers to get feedback. If you use Visio, create an extensive library of annotation stencils, page backgrounds, etc; if using InDesign, try pre-filled masters, object libraries and snippets. You get the idea.

But better yet, think about creating a deliverable environment that leverages modularity. Once you go modular, it’s increasingly easy to reuse - and maintain - a collection of artwork and even prose content that you can leverage in 2+ deliverables. Turn the approach on it’s head, and generate “one” content for “all” your deliverables.

What, more than one deliverable? Absolutely. So long as your artwork and key content is abstracted from a single deliverable, you can - and should - repurpose it to communicate more specifically with each audience.

Maybe try it out by splitting into two deliverables. Early on, you’re creating a higher-level document that tells a story and focuses on business strategy with light annotation. With it, you gain consensus from the business and can inform visual design. Later on, that same artwork can be placed into deep specification documents for engineers & QA. Look in wonder as the IDs, tabular guidelines, detailed content, and small type becomes more usable for your downstream builders.

What should you do?

Entirely depends on your constraints, ambition, time, and toolset. I’ve established practices that work for me, and they evolve all the time. And often, they work for many others. But it’s up to you to prescribe the proper medication - and dosage - for what may ail your deliverables.