This talk was originally going to be called “Effective Collaboration Between Designers & Developers,” but when they sat down to create their slides, David (developer) and Mindy (designer) realized they had deeper issues to resolve: he wanted to generate them with a custom templating engine; she wanted drop shadows and vector images of Che Guevara. Instead, they made a list of all the things they just can’t stand about their web counterparts. You’ll be enlightened as to why your co-worker glares at you when you walk in the door and come away with a few good ideas on how to communicate, empathize and avoid bloodshed.

2. PLEASED
TO MEET YOU

3. Thinks purple is sexy
Reads books about
leading and tracking
Adores grid systems
Has 5,643 fonts installed
and still can’t find one
perfect for her project

4. Hi.
_ wrote first
computer program
at age 6
_ fluent in BASH,
git, JSON, ReST &
AJAX
_ 3 level 70s
_ cuts own hair
[David]

5. Hi.
_ does not conform to
societal norms re:
fighting w/ pregnant
women
[David]

6. QUICK - PICK A SIDE

7. READY, SET, BLAME.

8. Designers break
functionality
in the name of quot;attractivenessquot;

9. Fig. 1: Before

10. Fig. 2:
After

11. no workee
Fig. 2b:
After

12. <% form_for @registration do |f| %>
... form fields ...
<% end %>
Fig. 3: Before (Rails)

13. <form action=quot;register.phpquot; method=quot;POSTquot;>
... form fields ...
</form>
Fig. 4: Before (PHP)

14. <form id=quot;new-registration-yay!quot;>
... form fields ...
</form>
Fig. 5: just wtf

15. jQuery:
enough rope for your
designer to string
you up

16. DEVELOPERS
USE CRAP MARKUP

17. TABLES
SRSLY, WHY?

19. AARRRGGGHH

20. Embrace Markup Standards

21. DESIGN CODE

22. LOTS OF BENEFITS
➡ More accessible across devices
➡ Maintain/redesign more efficiently
➡ Improve SEO with semantic code
➡ Faster load time

23. DEVELOPERS
TECHNOLOGY-HOP

25. CVS SVN GIT BAZAAR

26. DESIGNERS != TEST SUBJECTS

27. INVITE-ONLY BETA - BUT
SOOOOOO COOL. MUST USE.

29. D.V.C.S.
[designer version
control system]

30. D.V.C.S.
[committing]

40. D.V.C.S.
[branching]

43. D.V.C.S.
[tagging]

46. O HAI
I CHANGED THE SPEC

47. designers use their
control over the
site’s visuals to
change functionality.

50. quot;Buzzworthyquot;
Text

51. true story

54. DEVELOPERS
CHANGE STUFF WHEN
IMPLEMENTING

55. DON’T IGNORE DETAILS

64. cave
stay in your

65. designers are the
ones in front of the
clients, making
impossible promises

66. Developers can bring:
- technological suggestions
- feasibility
_ more technically-
oriented feature
ideas

67. DEVELOPERS
SAY NO TOO FAST

68. USUALLY, WITH
GOOD INTENTIONS
➡ Looking to mitigate risk
➡ Avoid scope creep
➡ Hesitant to say yes to something vague
and undefined

69. NOT LISTENING

71. YOU’RE THE GATEKEEPER

72. COMMUNICATE WITH US

73. DON’T BE NICK

74. BE MACGYVER

75. SOLUTIONS

76. give
it
away
now

77. designers are much
less inclined to
do work without a payoff

84. DEVELOPERS
LOVE OPEN SOURCE
TOO MUCH

86. http://www.gapingvoid.com/

88. LESS $,
MORE RESOURCES
➡ Smart developers to implement and
maintain it
➡ Lots of time to learn it, customize it
➡ No ready-made manuals, guides,
training

89. FUNCTIONALITY
BELLS AND WHISTLES

90. FRUSTRATES...EVERYONE
(you included)

91. DEVELOPERS
OVERLOOK SIMPLE
SOLUTIONS

93. ?#@&%
DESIGNER!

94. TALK TO US

95. ➡ Sometimes, it’s something that isn’t
that important. Might not be worth the
time and effort.
➡ Sometimes I have a suggestion that
will avoid crazy extra work
➡ Sometimes the complex solution is the
right one. At least you’ll know it’s worth
the work.

96. designers are
afraid
of their
computers

101. <

102. _ you use a computer all day,
so why not use it well?
_ the command line is
your friend
_ we love to help,
provided we like the
platform

103. designers
take a
long view

115. DEVELOPERS
FORGET TO ASK

117. FILL GAPS
➡ Would rather plow ahead with
assumptions than stop and ask
➡ Get frustrated when we tweak the
solution they came up with
➡ Communication would save time and
headaches

118. ASSUME NOTHING

119. ASK QUESTIONS

120. DEVELOPERS
THINK THEY ARE
THE TARGET USER

124. FORGET “AVERAGE”
➡ Push for bells and whistles an average
user would never request
➡ Put this extra functionality ahead of
usability
➡ Don’t tailor things (ie: error messages)
for non-tech people

125. EMPATHY

126. they're
full
of
sh*t

127. geometry

129. astronomy

130. “dimensionalization”

131. but in the end

134. they don't test in IE

139. <!--[if !IE]><!-->
<link rel=quot;stylesheetquot; type=quot;text/cssquot; media=quot;screen,
projectionquot; href=quot;screen.cssquot; />
<!--<![endif]-->
<!--[if gte IE 7]>
<link rel=quot;stylesheetquot; type=quot;text/cssquot; media=quot;screen,
projectionquot; href=quot;screen.cssquot; />
<![endif]-->

140. DEVELOPERS
DON’T TEST IN IE

143. TAKE A “FIGURE IT
OUT LATER”
APPROACH

145. DEVELOPERS
THINK EVERYONE
CAN DESIGN

146. They even build software to
help them do it.

147. “IF I HAD TIME...”

152. SO WHAT IS DESIGN?
➡ Solving problems
➡ Adding form to function
➡ Communicating ideas
➡ Evoking emotions
➡ And yeah, making it pretty to look at.

156. +

157. it doesn't matter

163. BAD DESIGN

164. BAD DESIGN
$$$

165. WHERE’S THE
LOVE?

166. COME WITH
PROBLEMS,
NOT SOLUTIONS.

167. SHOW EACH OTHER
WHY AND HOW.

168. SOME TENSION
IS HEALTHY.

169. TRY
UNDERSTANDING.

170. GO TO REFRESH

171. http://speakerrate.com/talks/280