1. DRUPAL FOR
DESIGNERS
Talking to Clients about Drupal

2. 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:
dani@tzk-design.com

3. Lifecycle of a Drupal Project

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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!

10. 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

11. 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

12. 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?

13. 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

14. 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