Nov. 15, 2011 dani nordin talking to clients about drupal projectsPresentation Transcript
DRUPAL FORDESIGNERSTalking 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: firstname.lastname@example.org
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