Chapter 4. Working with Clients
This final chapter deals with walking clients through the Drupal process. It collects what I’ve learned over years of running a studio and dealing with clients, and also touches on how to collect what you learn over the course of your projects, so that the next one is always just a little bit easier.
Proposing and Estimating Projects
Over the years, I’ve learned to break the discovery process into two distinct phases. The first, outlined here, happens prior to estimating the project, and gives me the background I need to create a proposal and estimate for the project. The second, more comprehensive phase happens during and after the project kickoff. This phase, described in Chapter 2, is where we start framing the design challenge that we’re facing, fleshing out the user experience, and making sure that the client is on board with our approach.
Pre-proposal discovery: what you need to know
The initial discovery phase should give you enough information about the client, the project’s goals and the level of complexity that you can put together an accurate proposal. During this phase, you’re looking to learn:
Who is the client?
How well do they know the business, and themselves?
Who are they trying to reach?
What’s the real goal here? What are they hoping their site will accomplish for them?
What kind of functionality are they going to need? Is it something you can handle on your own, or will you need to bring in external resources?
What’s the process for decision making within the organization? Are we dealing one-on-one with the main decision maker, or does everything have to go through one or more layers of red tape before it can be approved?
What kind of content are we working with? Do they have examples to show? How many pages, sections, etc.? How do they expect people to access or organize the content?
How big is their budget?
How open are they to your ideas and approach? What “vibe” do you get from them?
All of these questions should help you get a sense of what it’s going to be like to work with the client, and whether you’ll be able to create a productive working relationship. During initial conversations with potential clients, I often start putting answers to these questions in a standard Project Brief (available in Appendix A, at the end of this guide), that will get fleshed out in the project kickoff meeting as the beginning of the Discovery phase. I’ve also included it as a download from my website for potential clients to fill out before we estimate projects. While it doesn’t replace an initial phone call, it’s very good at helping weed out clients who may be more interested in price-shopping than in hiring a serious design team.
Pricing a project: Fixed-Bid versus hourly
The question of how to charge for Drupal is a sticky one. On one hand, most significant web projects will carry with them a level of uncertainty that makes an hourly rate attractive. What happens when the client needs extra changes? What happens when a certain functional problem is trickier to solve than you had accounted for, and you end up spending twice as many hours as you had intended? All of these are very valid reasons to charge hourly for your work, and many developers I know have no problem getting clients to agree to hourly billing.
That said, many clients (and designers) prefer a fixed-bid approach. Clients often equate the hourly approach with a ticking clock that must be shut off before things get too expensive, and that often means that quality gets sacrificed in the name of doing things quickly. I’ve especially seen this in consulting work. For example, working with a client to reposition their brand can require anywhere from 20–100 hours of time to really see results; however, many clients working with an hourly rate will cut the process off as early as 6 hours in, afraid of getting a huge bill at the end of our work together. As a result, the client doesn’t get the results they were hoping for, and they often feel that they wasted their money.
Using a fixed-bid approach attaches a very real and specific value to your work that clients have an easier time dealing with. It also helps with creating consistent income and cash flow; if, during the process of learning Drupal, you find yourself building websites much more quickly than you used to, a fixed bid allows you to charge the same (or higher) than you used to when you were still learning the ropes.
The trick, I have found, to working with fixed bid pricing is the following:
Keep very detailed time records. Over time, you’ll start to realize how long things actually take to build.
Have a contract that specifically states what clients will get from you. In estimates, I always account for up to three iterations of a site’s look and feel, with one opportunity to completely redesign it. Anything above and beyond that becomes a change order, and results in hourly charges.
Work with clients to establish payment schedules. With smaller clients, I tend to take an initial deposit, and then break the rest of the balance into monthly installments, regardless of when the project is finished. This helps me plan cash flow, while giving the client a chance to budget for the work. Other designers prefer a milestone-based approach, with one installment due upon approval of designs, and another due at the end of the project. Both approaches carry certain risks. With the monthly billing approach, you get paid sooner and more regularly, but it can be harder to define where, exactly, a project ends. With the milestone-based billing approach, you risk running into a negative cash-flow situation at any point where the project runs into delays. And believe me, it will run into delays.
Ultimately, whether you work hourly or fixed bid, you still have to be able to give the client an approximate idea of what their job will cost, and how long it will take to complete. The best process I’ve seen for estimating Drupal projects comes from CivicActions in San Francisco; their Estimating Spreadsheet is a brilliant way to break up the individual pieces of a Drupal project by hours needed for specific team members. For working with distributed teams, I find translating the spreadsheet into a Google Doc offers a great way to collaboratively come up with numbers for a proposal.
Writing the proposal
Once you’ve collected the initial discovery, and estimated what resources you’ll need and how much the project will take to build, it’s time to craft a proposal. At a minimum, a good proposal should include:
Your initial assessment of the goals, audience and objectives of the project, based on your discovery sessions with the client.
A statement of work that describes what you’ll deliver to the client. This should include a number of original concepts you’ll deliver, as well as how many rounds of revisions included in the budget. It should also include a list of deliverables you’ll need from the client in order to proceed, and a note about what happens if they’re late on their deliverables.
Estimated prices for the project you’re discussing. Many teams like to give a low and a high bid, with the note that pricing is based on the information you have on hand, and that new information, such as additional stakeholders or new content that wasn’t discussed up front, may push the project into the upper price range.
Any terms and conditions that apply to the project. This should include things like a schedule, what happens if you or the client decide to cancel the project, and how you’ll deal with issues such as delays or new information.
In addition to these things, some teams find it helpful to include:
An overview of the design and development process, which gives the client an idea of what to expect.
Case studies or images of previous design work done for other clients.
A more detailed scope of work, which would include Drupal-level deliverables, such as custom page templates or content types included in the estimated cost. Include this information with caution; not all clients understand “DrupalSpeak™,” and it could cause confusion.
Bios of team members, and other information about the company.
In my own work with clients, I use two proposal formats. For larger projects, especially ones where I have to put together a team for the project, I use a proposal format adapted from Chicago design firm Rogue Element’s proposals. The format has the benefit of being both concise and comprehensive, and it’s easily adaptable to any studio’s needs.
For shorter projects, I use an amended proposal, or Work Agreement, that includes just the first set of information above. I use this format for smaller projects (for example, budgets around $5k or less), or for repeat clients. For new clients, I may also include a bit of information about the studio and a list of previous design work.
A sample of both the proposal and Work Agreement is available in Appendix A. The content is unique to my studio and the client involved, but the format is free for you to adapt as you need to.
Getting clients to love you, even when you have to tell them “no” (and what to do if they don’t)
There comes a time in every Drupal project where you are going to have to say “no” to something your client wants. This could happen for a number of reasons. Your client could have seen an amazing widget on somebody else’s site and feels that they MUST have it on theirs. Or they decide all of a sudden that what they really need to “engage their community” is a full set of social media tools that customers can use directly through their site. No matter what the reason is, you’ve already set the scope for the project, you’re probably already worried about meeting the deadlines you have, and you need to find a way to diffuse this situation without losing your patience or the client.
There are a few things to remember when this happens to you.
Most of the time, the client will actually have a very good reason for making this suggestion.
Just because something can’t be part of the site now doesn’t mean it can’t ever be; in fact, often these types of conversations lead to future enhancements down the line.
What the client needs from you is to know that they’ve been heard, and to know what you’re going to do about it.
This is why it’s so essential to have up-front documentation that clearly describes the technical and design scope of the project, user objectives and business goals. The documentation won’t prevent these ideas from cropping up; what it will do is give you a foundation for the conversation you need to have with the client when they do.
For example, let’s say that you contracted with the client to build a simple, mostly promotional site with an events listing, news page, blog and contact form. You’ve gotten through the discovery phase and have already started theming and approving designs, when the client realizes that she’d really love to add some interaction to the mix. She’s seen other companies that have forums where users hang out, converse and help each other. She’s heard that Drupal “makes it easy” to add forums to a website, and she wants to implement it straightaway.
First, does Drupal actually “make it easy” to add a forum to your site? Technically, yes. Forums are part of Drupal’s core functionality, and you can enable the forum simply by clicking a button on the Modules page. However, enabling the forum is just a tiny piece of what’s actually involved in creating a forum. You have to figure out where it belongs in the site’s architecture, decide who has access and who doesn’t, set up the appropriate permissions, and style it to mesh with the look and feel of the rest of the site. Also, the client will have to promote the forums, create categories for forum topics, get people actually using them, and monitor them consistently for trolls and spammers. What we think of as “easy” at first glance rarely is once we’re in the process of making it happen.
There are several ways to approach the challenge of pushing back, most of which will at some point involve referring the client back to the documentation you created at the beginning of your project. My personal approach is to say, “Great idea! Let me ask just a few questions to figure out how this can work...” This assures the client that you’re listening to them, but also helps them talk through the business logic behind the request, and understand all that actually goes into making their request happen. Often, this approach will either talk them out of the idea completely or put it in the works for the next iteration of the site. Either response is a good resolution.
To elaborate on this example, any of the following questions could work with most reasonable clients, depending on where you are in the project plan:
“A forum could be great! How were you planning on promoting it? Do you have resources to monitor it for spammers and trolls?”
“I like that idea, but one of our business objectives was to focus on the organization’s human-friendly approach to customer service. A user forum might give the impression that you prefer your customers to handle issues among themselves. What do you expect the user will gain from the forum?”
“That sounds like a great idea, but right now, our push is to get the basic functionality into the site before launch on Tuesday. Do you want to have a discussion about adding it to the next iteration of the site? I’ll work up some estimates on what it would cost.”
There are a few things to note about this approach. First, clients really love it when you tell them they’ve had a great idea. Second, you’re making it clear that although the idea is good, they have to be prepared to do some work to make it happen.
Third, and this is the really important part: you’re not pointing to a specific document and saying “if you remember the piece of paper you signed...”
In my early days of working with clients, I used the “that’s not in the contract” line frequently, and it never ever worked. Something about referring people back to legal agreements sets up the conversation to be combative; the client ends up perceiving that you’re trying to pick a fight with them. Referring to themes that you’d agreed on in the course of discovery shows the client that you’re interested to see how this new idea might work with what has already agreed upon, and you want to find a solution that works for everybody.
This process of dealing with client requests that push a project beyond the original scope has caused some teams to adopt a hybrid Agile approach to Drupal projects. While the process still involves defining the scope of work and planning things out up front, design and development happen together, iteratively and collaboratively. This helps teams keep everyone on track while accounting for the inevitable bumps in the road that come with designing for Drupal. Says Four Kitchens’ Todd Nienkerk of their Agile process:
We rarely say “no” to a client with regard to functionality, but we do explain that:
Adding something before launch means something else needs to be pushed back;
Their current budget doesn’t really allow for this extra work, so let’s reprioritize or find more money, etc.
Scrum provides a very handy framework for this discussion because all ideas, regardless of how enormous or superfluous or whim-driven they may be, go into the project backlog for future discussion. Usually having it in the backlog—i.e., captured somewhere for the client to see every so often—is enough to make them happy and never actually push for that feature to be implemented.
That’s easy for you to say...
Of course, this approach doesn’t always work. Occasionally, you run into the type of client that I like to call “the Dictator.” They grab ideas completely out of left field and present you with them, and you’re expected to take that idea and run with it. If you try to spin the conversation back to the scope that was agreed upon, they get hostile and say things like “this is what I hired you to do,” or “just make it happen.”
Or, worse, you run into the type of client that loves everything you do, gives you complete creative freedom, and gives you absolutely no direction, feedback, or restraints—but will come up with an idea once a week that absolutely won’t fit into the budget, and she can’t understand why when you explain it to her.
When you run into these types of clients, you have to make a choice. Is it more important to preserve the client relationship, or to stand your ground and risk walking away from the project?
I’m fortunate in my career to have grown skilled at managing “difficult” clients. But the most important part of this skill is knowing myself well enough to know the types of clients that I just can’t work with. In my entire career, the handful of times that a project has gone sour can be directly attributed to deciding to take on a project despite the obvious conflicts between myself and the client. If you’re on a team, it can be easier; you have other team members who you can lean on when things get to be more than you can handle. If you’re working solo, or as part of a small distributed team, it can make you wonder why you got into this field in the first place.
Either way, part of managing your career is learning how to navigate difficult situations with grace. If you find yourself faced with a client who refuses to hear the word “no,” it’s on you to evaluate whether their request can be accommodated within the current budget, and to make any adjustments that need to be made, including possibly letting the client go.
The “Professional Relationship” clause
Recently, I gave a brief talk on the state of designers and UXers in the typical Drupal team. During discussions after the talk, I mentioned the “Professional Relationship” clause that I include in all of my Work Agreements, that establishes the working relationship I expect with clients, and states that I (or the client) can terminate the agreement if one of us isn’t living up to the terms of this relationship. This statement—that I basically told clients how I expected them to treat me, and what they could expect of me in return—was met with expressions of shock and curiosity by everyone in the room, most of whom were developers.
The reason I put the clause into my contracts was simple; as a self-employed designer, I’m selling my time and energy. If that time and energy is being sapped by abusive or disrespectful clients, I need to be able to address the situation proactively in a way that protects my business and my sanity. The “Professional Relationship” clause, which encompasses a few bullet points on the front page of the contract, helps clients understand that I’m here to help them—and if they won’t respect that, they should find someone else to work with.
I put the clause into my contracts with the help of Jessica Manganello, a client, friend, and co-founder of New Leaf Legal, a terrific team of entrepreneurial lawyers in the Boston area. She and I got together to look at my contracts after a particularly nasty situation with a client who turned abusive after ignoring his project for over a year. Although he had clearly breached his end of the contract, I had also set up my initial contract, which was cobbled together from sample contracts I got from a copy of Legal Forms for Graphic Designers (Allworth Press) and the AIGA’s website, with no way for me to get out of a project that wasn’t working out. Establishing the clause helped me make it extra clear to clients that I meant business, and I’ve yet to meet the client who refused to sign as a result of the clause.
If you want to consider adding the clause to your contracts, you can find it in my sample Work Agreement in Appendix A. If you want a contract that fully covers all your bases and makes sure that you’re covered for anything, give Jess at New Leaf a call.
After the Handoff: The project retrospective
“Unfortunately, this critical step [of reflecting on a project after its completion] is nearly always ignored by professional designers. Assessment implies internal criticism, something many companies prefer to leave up to public relations or external product reviews. The assessment [of the project’s success] must be at a user and project level, rather than a quality assurance level, and benchmarks for success have generally not been developed or acknowledged within corporate America. In many high-pressure design consultancies, to reflect is to waste time. Reflection is not productive and is frequently viewed as a poor use of money and resources.”
The case study. Some designers swear by them as a valuable marketing tool; others refuse to do them, insisting that there’s just “too much work to do,” or insisting that images of their work will speak for themselves. I’ve even heard designers say that clients don’t like reading case studies. I’ve never personally seen this, but then, I’ve never quite subscribed to the idea of being “too busy to read.”
Let me state one thing emphatically: reflecting on your work—whether you share them as case studies or not—is vitally important to your career as a designer. Whether you’re part of a team, an independent designer, or working in corporate America, the time that you take to think over a project—how it went, what went right, how you can make things better next time—is one of the most important things that can you can do. Every time I’ve taken the time to reflect on a project, no matter how well or how horribly it went, I’ve learned something valuable that I can take into the future. Reflecting on “nightmare” projects has proven particularly valuable; not only does it give me a way to move on from them productively, it also gives me a wellspring of lessons for those inevitable “have you ever had a project that just went horribly?” questions that clients or job interviewers sometimes like to spring on you.
The time that you take to reflect at the end of a project depends on the project, and often on your role in the project. When I’m leading a project I’ve done before and all goes well, a simple retrospective can take as little as a half hour with a coffee and my journal; if I’m part of a larger team, or if the project hits some bumps in the road I wasn’t anticipating, it can take much longer. The process you use is up to you, but the goals are often the same:
Identify what was involved in the project that made it unique;
Identify any factors that worked particularly well. This could be the client, your style of communication, a new kind of documentation—anything that contributed to this project going well.
Identify any factors that made the project harder than it needed to be. This is an area I tend to spend the most time on. When I reflect on a project, I want to know what I can improve on the next time, see if there were any areas I need to develop more skill in.
Document the things that will be particularly useful for later projects. This may be code, or it may be a way of dealing with clients; whatever it is, make sure you have it set aside somewhere where you can find it again.
The key to doing a successful retrospective is to find a process that works for you. Sometimes, long-form prose works, like a blog entry or journalling. Sometimes, if I’m stuck, I’ll use a Mind Map to get all of my thoughts out on a page before I commit anything to prose. (For more on Mind Maps, check out Chapter 2.)
Including clients in the retrospective
The choice of whether to include clients in your post-project reflections is completely up to you. Asking clients for feedback, especially if the project didn’t go as well as you’d hoped, can be hard. Nobody likes to hear that they were harsher than they needed to be in a particular conversation, or that their design solutions weren’t particularly good.
Whether you choose to allow clients into the retrospective process or not, getting feedback from clients is an essential part of the growth process, and it can also provide useful information for future projects. Designer Todd Nienkerk of Four Kitchens says:
“We frame the conversation by saying that we won’t take anything personally and by leading off with some thoughtful self-criticism to get the conversation started. As you say, it can sting, but it’s important to learn what needs attention and growth.”
There are several ways to include client feedback in your post-project reflection. The easiest way is through simple surveys; whether you do them through an online service like Survey Monkey or through a simple thank-you note with a questionnaire, asking the right questions can get some very valuable feedback. While surveys can be valuable, I often find that a simple conversation, over the phone or over coffee, works best. For one, it’s more likely that the client will actually give you feedback (often a challenge with other means of communication); second; it gives you a valuable chance both to deepen your relationship with the client and find out if there’s additional projects in the pipeline that you can create a pitch for.
Documenting what you learned
An important benefit of the project Retrospective is being able to document what you’ve learned. This could be a new way of collaborating with clients, a new productivity tool, or a new module that you can’t wait to share your glee about. How you set up this documentation is, again, up to you, but the best documentation is:
Searchable (so you can find notes when you need them);
Sharable (so when you’re chatting with another Drupal buddy who’s dealing with a problem you’ve had before, you can send them a link to it);
Has the option of being private. Let’s face it: if a project really sucked, the last thing you want to do is blog about it publicly. But there’s knowledge to be gained from it, regardless, and you want to be able to document what you’ve learned so you can remember it next time.
Every team has their own way of collecting documentation. Some will make their own wikis in Drupal, or use OpenAtrium, a Drupal-based project intranet created by DC-based Drupal shop Development Seed. Others will collect documentation in a personal blog, built in Drupal or Wordpress.
Evernote is a free cross-platform application that allows you to easily collect, tag and share notes by e-mail, and it syncs your notes over the Internet without forcing you to be online in order to create or edit your notes (Figure 4-1). You can also organize your content into distinct notebooks, which is incredibly useful when you want to separate, for example, theming notes from modules you want to check out. And, it’s available for iPad, iPhone and Android, so collecting notes is super-easy if you don’t always have your computer on you.
Documenting for the community
Dries Buytaert, creator of Drupal, has been quoted many times as saying that the Drupal community needs designers. But what the community also needs is more people to help document Drupal modules, best practices, and other things that can help Drupal newbies not cry their way through their first several Drupal projects. While many development teams have made a habit of blogging their Drupal knowledge, too many contributed modules on Drupal.org have woefully inadequate documentation, which makes it harder for folks new to Drupal who aren’t hardcore programmers to access the brilliance of these modules. If, at the end of a project, you find yourself with knowledge of a particular module that isn’t being shared, consider contributing documentation on Drupal.org, or on your own blog. The community will love you for it.
 available as an OpenOffice download here: http://civicactions.com/estimating-worksheet. It should also open in Mac’s Numbers application or Microsoft Excel. I’ve also imported it as a Google Doc with some success.
 Kolko, Jonathan. Thoughts on Interaction Design, p. 34