Something funny happened while at Drupalcon Copenhagen. I was approached a guy in a bar after I gave my talk on Design For Drupal: A Template Approach, who said, "Your talk was good, but you should talk about what you REALLY do." I was stunned and confused by this at first, but then slowly realized that he was right. There was a much larger piece of my work that I wasn't talking about. The "client wrestling part." The part where you sit in a conference room for 5 days straight systematically deciding what you're going to do for the next 3-8 months depending on the size of the project.
So how do we do this? How do we get people to agree on things when there are sometimes as many as 10 voices in the room?
Here are some pieces of the puzzle for you to chew on.
Listening
Clients have already done a lot of thinking before you start working with them, and it's your job to let them talk first. The foundation of a successful project is excellent communication and understanding. I recommend reading this useful article on Active Listening. It is a skill that will help you with pretty much everything.
Who Decides What
When you start a project, define who the players are, their responsibilities, and who has sign off. Do this on both sides to create transparency, trust, and clarity of how things will work. Find out who has the final say on the client's side. You may find yourself working with a person who has the authority to make decisions, but be sure to ask if they have superiors to will trump those decisions. Make time for the final decision makers to weigh in on things before the project is done.
One Is The Magic Number
Make sure you have one single person on the client side who is the point of contact. This is generally the Project Manager. Do not agree to a structure where you address their team as a group. It is inefficient and will take more time than is necessary.
Timeline
Figure out when the project needs to launch. Ask your client if there are external factors, such as an event, that makes that date a hard launch date. I've seen large technology projects take 3 times longer than expected, so take that into consideration when planning. Every project has unexpected things that come up. The key is to work with your client and tell them early and often if the schedule is being pushed. If you communicate openly with them, they will collaborate with you on expectations and solutions.
Soliciting Feedback
Guide your client on how to give you feedback. Give them deadlines on when you need to receive that feedback so that they can help you do your job. Train your clients on the kinds of things they should be looking for and giving you feedback on.
How we do it: We implore a weekly deliverable cycle where we give the client the work about 1 day before meeting in person or over the phone. They are responsible for soliciting feedback from their team and consolidated that feedback. During the meeting we ask questions and collaborate on solutions. We try to force quick turn-a-round like this to keep the project inertia going and to stay on schedule. We continue to meet weekly after we transition into development, keeping the weekly conversation active throughout the project cycle.
We Love Deadlines
If you want something done, give it a deadline. Do it for yourself, your team, the client, and their team. If you don't know the deadline, make it up, and say it with confidence. Creative thinkers (developers and designers) thrive within time constraints, producing their best work as the clock tics down. I wish I could always work as efficiently as I do under the gun.
The Roadmap: Define Your Goals
The goals are the foundation of the site. The rock on which you will stand six months later when you receive feedback that seems outlandish. Being able to refer back to the goals keeps people on track of what really matters. It's your ace in the hole. It will prevent scope creep and keep things on budget. Keep these goals in the forefront of your weekly conversations and talk about them in every meeting. They are your shining light of guidance and should be considered in all choices.
Know Your Audience
Know your primary, secondary, and tertiary users. Make your design most effective for your primary users. When defining your audience, add as much detail as you can about both their likes, dislikes, age, technical background, cultural background, how much time they spend online and so forth. Get a target audience members lined up early in the process to test your work once it's ready.
Deliverables
-
Project Schedule (example)
This document outlines key deliverables on a timeline that is agreed upon by all parties.
-
Strategy Document (example)
This document outlines the goals of the project, audience, and other important findings which serve as a building blocks for the project.
-
Content Inventory (example)
This is for existing sites. This document outline all the pages on the site and where they live. This is an excellent research step to do before the kick off meeting because it will give you a comprehensive understanding of where you're starting from. To learn more about this, read Content Strategy For The Web.
-
Site Map (lo-fi example | graphic example)
The site map is the document that shows the navigational architecture of the site. Sitemaps can be simple or complex. The Lo-fi example provided is from the Drupalcon SF project which I took the simple approach on due to time. The graphic example is from the redesign of the Chapter Three website.
-
Page Tables (example)
These pages are meant to document the key template pages, the goals for each page, the content buckets for each page, and also address if new content needs to be created or edited. This is a step that should be done before you begin wireframing. It serves to inform both the purpose, functionality, and content for each page. It will also help you organize content that needs to be created or edited.
-
Personas (Persona Template) | Example
Personas are fictitious people who represent your key customers and illustrate their unique desires and motivations on your site. These Personas will eventually define your sites functionality as well as prioritize it. To learn more, read my blog post explaining how to leverage this powerful tool.
-
Use Cases (example)
Document outlining key user paths and functionality requirements
-
2 Rounds of Wireframes (lo-fi example | greybox example)
We send Greybox PDFs to the client to work through the general layout and functionality of the site
-
2 Rounds of Graphical Comps (example )
We deliver Fireworks files with pixel perfect renderings of the key template pages
-
Style Guide (example) (General Drupal Elements Example)
This outlines all of the typographic and graphic styles on the site as well as a list of other HTML elements that may have not been addressed in the design of the key template pages (see: Design for Drupal, a Template Approach)
other things that matter...
Project Managers
A good project manager is worth their weight in gold. They are the keepers of the torch from beginning to end and are the primary contact for the client. If you don't have one, try to get one, or if you find a person on your team who has a knack for it, see if the want to transition into that role full time. Project managers are grown organically and it's worth it to foster their growth.
Try A Little Understanding
You will get far with people if they know that they're being heard. This holds especially true on projects with large number of stake holders. It's impossible to meet the needs of every single stake holder sometimes, but often you can make collaborators feel at ease if you really take the time to simply hear them out with an open mind. If all else fails, tell them that you can address their concerns in "phase 2".
Hire A Copywriter
If your client does not have a copywriter on staff suggest hiring one. Content is key. A site with good design and solid technology is nothing without content. Do not save it til last. Loop it in from the start.
Take This With A Grain Of Salt
This is an evolving practice. Anything I share here is from my own experience. In the world of web, we're figuring it out as we go, and learning from one another. If you have a better way of doing something, share it. In the end, we all benefit.
Tools of the trade
-
Adobe Fireworks
This is what we use to design and wireframe our sites.
-
Snap Z Pro X
Top notch screen grab tool. I use this about 50 times a day.
-
Skitch
Fantastic for a mocking up notes visually of anything on your screen and then sharing via email or web. NOTE: if you all use skitch, you can actually open Skitch files, edit them and repost as a "comment". Pretty great.
-
Google Docs
Great for organizing with multiple people. My favorite latest use of this is with the redesign of the Chapter Three Website it. We're using it as a live doc for the new copy on the site.
-
Open Atrium
Drupal product that allows groups to organize and collaborate around projects.
-
Adobe Illustrator
Great for doing fancy stuff with vectors and print stuff(I know, that's not web, but it comes up).
-
Notable
Great for giving feedback on comps in a web environment. I started to design an app like this for Drupal for sharing web comps, but Notable basically does almost everything I was hoping to do, so hats off.
-
Papparazzi
Great for taking screen shots of entire websites, no matter how tall. Can be used in tandem with Notable if you're having issues with font displays.
-
Firefox
Great for analyzing site code using Firebug (and much much more).
-
WebEx
Great for teleconferencing.
