For all of us engaged in Web projects on a daily basis, we are often surprised by how much can change from project to project. Flexibility is key when you are a digital strategist, Web professional or online communications expert. The goal of this series is to provide information from leading experts in the field on how to create best practices for Web projects. In the next three columns, we will focus on the art and science of the deliverable.
My panel includes:
- Chris Moritz, Content Strategist/Information Architect (@chrismoritz)
- Jeffrey Rum, Visual Designer (@jsrum)
- Daniel Eizans, Content Strategist (@danieleizans)
- Alice Coleman, Information Architect
- Randall Snare, Content Strategist (@randallsnare)
- Michael Hogenmiller, Visual Designer (@mhogenmiller)
You’ll find my takeaways at the bottom of the panelists’ answers. Thank you to my talented and fantastic panelists.
How does your subspecialty within UX help you create and set a list of deliverables?
Chris Moritz, Content Strategist and IA
Chris has a diverse portfolio of meaningful content strategy deliverables.
My current subspecialty (Content Strategy) affords me a nonstop bevy of chances to create, modify, adapt and extend deliverables, including:
- Prose and poetry (ok, maybe not so much so on the poetry)
But definitely everything else! Given the diversity of communication challenges and industries my clients represent, I find I need to tailor a loose set of approaches to a blank sheet of paper, whiteboard or screen to craft a meaningful, persuasive deliverable.
Jeff Rum, Visual Designer
Jeff understands the multidisciplinary aspect of Web projects, and often creates deliverables outside of visual design.
When creating a list of deliverables, I have two groups in mind: The users and the client. The deliverables must focus on achieving a positive user experience and ensure each milestone reached is one more step toward meeting the client’s business goals and objectives. Deliverables may include information architecture, wireframes, prototypes and, of course, visual design.
Daniel Eizans, Content Strategist
Daniel focuses on the content deliverables, but also knows flexibility is critical.
For me, deliverables shift from project to project. That said, my background with UX usually helps me most in evaluating the potential channels that will reach users, and recommend when additional study is required to determine how users are crossing channels.
I also leverage my knowledge of the space to set content thresholds for pages and to set copy and character limits. Experience with usability testing alongside an IA also allows me to help set editing guidelines for content creators.
Alice Coleman, Information Architect
Alice has a more standard set of information architecture deliverables, but can also create other important Web deliverables.
There is a fairly standard set of information architecture deliverables -- annotated wireframes --but I find that, oftentimes, I have to deliver other artifacts that provide the fundamental information needed to create an informed user experience. For example, when my client has very little insight into who their online customer is, I create personas or online target audience descriptions. When a client doesn't have a clear picture of how their customer is using their website and/or how an online consumer relationship is developed, I might create an experience map to show user tasks and flow through the site. The set of deliverables on a given project are driven by understanding what kind of information is available to me as input to my standard set of deliverables, and to understand user tasks and client business needs in an effort to create the best user experience possible.
Randall Snare, Content Strategist
Randall appreciates that specialties can help fine-tune deliverables on a project that might otherwise be handed to someone who doesn’t have the training to manage them.
In some ways, specialties within UX can be bad for a project. You can't extrapolate content from design! Functionality from layout! But of course, we must have specialties; otherwise, we'd all be mediocre jacks-of-all-trades. Specialties can also be good for a project. A specialty is another word for "owner," and owning something is the only way things get done.
For example, for a project I'm working on now -- a large charity website -- we've decided to add testimonials to many of the pages within the new site. We've put them both in the wireframes and the IA document. Because I'm the content strategist on the project, I have to follow up on that. I have to make sure that there are enough testimonials (there are), audit them and map them to the key pages. If there weren't a content specialist on the project, there's a good chance that this would come up at the migration stage. And, the poor migration resource would have a job to do that he/she wasn't prepared for.
So while I have standard design deliverables -- Information architecture spec, content brief, content creation, migration and on screen, review plans (i.e. spreadsheets galore) -- I also have reactive deliverables: Things that I do as we make decisions during the creation process. And, those are directly because of my specialty.
Michael Hogenmiller, Visual Designer
Michael tries to pick the best point to bring in the client on the visual design process.
As a visual designer, the big question when it comes to deliverables is, "At what point in the creative process do I want to bring the client in?" Some designers build out an entire prototype before they present to the client, asking questions along the way but never tipping their "creative hand" until the presentation. Others bring the client in on discussions re: Wireframes, information architecture, content channels, user personas, moodboards, typography, illustration, etc., educating the client along the way and teaching the client to think strategically -- using design as a tool to solve each problem along the way.
While the second path can sound exhausting, and some clients just aren't up for the challenge, my favorite client experiences have been with project partners who were genuinely interested in understanding the hows and whys of all of the strategic decisions we were making together.
Most of our subspecialties help determine deliverables -- but that doesn’t mean there is not something new to learn. As a professor of mine once told me, “Know something about everything and everything about something.” Great teams are composed of people who overlap in their disciplines. Don’t be afraid to learn how to create a deliverable you don’t know much about -- it will help inform your own process.
Next week, we’ll talk about aligning deliverables to project goals.