Nov. 15, 2011 dani nordin talking to clients about drupal projects

DRUPAL FOR DESIGNERSTalking to Clients about Drupal

Dani Nordin• UX Designer and

Strategist• Specialize in Design

Strategy for Drupal teams

• Founder, the zen kitchen

• Author, Drupal for Designers series

• Twitter: @danigrrl• Email:

[email protected]

Lifecycle of a Drupal Project

Discovery• Understand the client’s specific functional needs• Get clear on the client’s marketing and business goals, and

how this project fits in• Get a handle on resource issues, time investment and other

practical considerations• Research the client’s competitive landscape and audience

UX/Architecture• Get an understanding of the site’s target users• Map out how users will flow through specific key tasks, and

what information needs to be there to support them• Find out what content exists for the current site, what needs

to be created, and how the content will be organized• Come up with a set of assumptions, and standards that will

govern the project as you move forward

Prototyping• Start setting up initial Drupal architecture, and laying in

content to see how it works in “the real world”• Test task flows and assumptions with real users, and see

where you need adjustments• Refine functional requirements and understand what needs

to be done to finish the project

Functional Implementation & Theming

• Often happens concurrently• Takes the knowledge gained in the UX, Architecture and

Prototyping phases and works it into a more finalized version of the site• Creates a set of visual and functional standards and applies

them to the site’s framework• Can be the longest—or the shortest—part of the process

Testing and Launch• Moves the site from development to staging• Makes sure that everything is working correctly in the

new environment• Makes last-minute updates to modules, content and

other customizations

Project Wrap-up/Retrospective• Takes a look at what went well, what needed tweaking, and

assesses the client/design team relationship• Creates documentation and understanding that will help

make future projects better• May result in blog posts, articles, DrupalCamp sessions, or

even a book!

Talking to Clients about Drupal• Speak in the client’s language; avoid “DrupalSpeak” • Nodes = “pieces of content”• Views = “content displays” or “page displays”• Blocks = “callouts” or “bits of content”• Content types = “types of content”

• Break down projects into logical chunks• Sections of content• Bits of functionality (e.g. “the homepage slideshow” or “the contact

form” instead of “creating all the content types”)

• Encourage them to give 3–5 pieces of *real* content for each distinct content type

Estimating Drupal Projects• Get enough data to understand how much work is involved

and which aspects of your approach will be most effective in landing the project• Be clear on numbers• How many iterations will they get?• How many types of content will you be creating?• What happens if they go beyond the scope?

• Don’t bother if there’s not a good chance of winning the project

Questions to ask• What does your company do?• Who are the people you’re trying to reach? • What’s the primary message you want them to get?• What are the functional goals of the website?• What are the business or marketing goals of the website?• Who will make decisions regarding this proposal, and about

the project itself?• Are there any deadlines we should know about?• What budget do you have set aside for this project?

Talking Money• Talk money as soon as possible, but not before getting a feel

for the client and whether the project will be a good fit• Have a range available, with a representative project• “This site, [URL], had this type of functionality; we were able to put

that together for about $5k; this other site, [URL], was more complex for [reasons], and that cost $20k

• Get a real number to work with

Talking time and effort• Keep good time records; know what it takes to do something• Don’t trust anyone who says, “why would it take you [x]

hours just to do content types?”• Break down work by distinct bits of functionality or sections

of content; don’t promise “all Views delivered by [date]”• Be realistic about schedule