10 Things Designers Do That Piss Developers Off (And Vice Versa)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

10 Things Designers Do That Piss Developers Off (And Vice Versa)

  • 3,907 views
Uploaded on

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

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.

More in: Design , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,907
On Slideshare
3,884
From Embeds
23
Number of Embeds
4

Actions

Shares
Downloads
60
Comments
0
Likes
11

Embeds 23

http://hagwaar.ch 17
http://www.ireneshen.com 3
http://www.slideshare.net 2
http://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. PLEASED TO MEET YOU
  • 2. 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
  • 3. Hi. _ wrote first computer program at age 6 _ fluent in BASH, git, JSON, ReST & AJAX _ 3 level 70s _ cuts own hair [David]
  • 4. Hi. _ does not conform to societal norms re: fighting w/ pregnant women [David]
  • 5. QUICK - PICK A SIDE
  • 6. READY, SET, BLAME.
  • 7. Designers break functionality in the name of quot;attractivenessquot;
  • 8. Fig. 1: Before
  • 9. Fig. 2: After
  • 10. no workee Fig. 2b: After
  • 11. <% form_for @registration do |f| %> ... form fields ... <% end %> Fig. 3: Before (Rails)
  • 12. <form action=quot;register.phpquot; method=quot;POSTquot;> ... form fields ... </form> Fig. 4: Before (PHP)
  • 13. <form id=quot;new-registration-yay!quot;> ... form fields ... </form> Fig. 5: just wtf
  • 14. jQuery: enough rope for your designer to string you up
  • 15. DEVELOPERS USE CRAP MARKUP
  • 16. TABLES SRSLY, WHY?
  • 17. AARRRGGGHH
  • 18. Embrace Markup Standards
  • 19. DESIGN CODE
  • 20. LOTS OF BENEFITS ➡ More accessible across devices ➡ Maintain/redesign more efficiently ➡ Improve SEO with semantic code ➡ Faster load time
  • 21. DEVELOPERS TECHNOLOGY-HOP
  • 22. CVS SVN GIT BAZAAR
  • 23. DESIGNERS != TEST SUBJECTS
  • 24. INVITE-ONLY BETA - BUT SOOOOOO COOL. MUST USE.
  • 25. D.V.C.S. [designer version control system]
  • 26. D.V.C.S. [committing]
  • 27. D.V.C.S. [branching]
  • 28. D.V.C.S. [tagging]
  • 29. O HAI I CHANGED THE SPEC
  • 30. designers use their control over the site’s visuals to change functionality.
  • 31. quot;Buzzworthyquot; Text
  • 32. true story
  • 33. DEVELOPERS CHANGE STUFF WHEN IMPLEMENTING
  • 34. DON’T IGNORE DETAILS
  • 35. cave stay in your
  • 36. designers are the ones in front of the clients, making impossible promises
  • 37. Developers can bring: - technological suggestions - feasibility _ more technically- oriented feature ideas
  • 38. DEVELOPERS SAY NO TOO FAST
  • 39. USUALLY, WITH GOOD INTENTIONS ➡ Looking to mitigate risk ➡ Avoid scope creep ➡ Hesitant to say yes to something vague and undefined
  • 40. NOT LISTENING
  • 41. YOU’RE THE GATEKEEPER
  • 42. COMMUNICATE WITH US
  • 43. DON’T BE NICK
  • 44. BE MACGYVER
  • 45. SOLUTIONS
  • 46. give it away now
  • 47. designers are much less inclined to do work without a payoff
  • 48. DEVELOPERS LOVE OPEN SOURCE TOO MUCH
  • 49. http://www.gapingvoid.com/
  • 50. LESS $, MORE RESOURCES ➡ Smart developers to implement and maintain it ➡ Lots of time to learn it, customize it ➡ No ready-made manuals, guides, training
  • 51. FUNCTIONALITY BELLS AND WHISTLES
  • 52. FRUSTRATES...EVERYONE (you included)
  • 53. DEVELOPERS OVERLOOK SIMPLE SOLUTIONS
  • 54. ?#@&% DESIGNER!
  • 55. TALK TO US
  • 56. ➡ 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.
  • 57. designers are afraid of their computers
  • 58. <
  • 59. _ 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
  • 60. designers take a long view
  • 61. DEVELOPERS FORGET TO ASK
  • 62. 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
  • 63. ASSUME NOTHING
  • 64. ASK QUESTIONS
  • 65. DEVELOPERS THINK THEY ARE THE TARGET USER
  • 66. 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
  • 67. EMPATHY
  • 68. they're full of sh*t
  • 69. geometry
  • 70. astronomy
  • 71. “dimensionalization”
  • 72. but in the end
  • 73. they don't test in IE
  • 74. <!--[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]-->
  • 75. DEVELOPERS DON’T TEST IN IE
  • 76. TAKE A “FIGURE IT OUT LATER” APPROACH
  • 77. DEVELOPERS THINK EVERYONE CAN DESIGN
  • 78. They even build software to help them do it.
  • 79. “IF I HAD TIME...”
  • 80. SO WHAT IS DESIGN? ➡ Solving problems ➡ Adding form to function ➡ Communicating ideas ➡ Evoking emotions ➡ And yeah, making it pretty to look at.
  • 81. +
  • 82. it doesn't matter
  • 83. BAD DESIGN
  • 84. BAD DESIGN $$$
  • 85. WHERE’S THE LOVE?
  • 86. COME WITH PROBLEMS, NOT SOLUTIONS.
  • 87. SHOW EACH OTHER WHY AND HOW.
  • 88. SOME TENSION IS HEALTHY.
  • 89. TRY UNDERSTANDING.
  • 90. GO TO REFRESH
  • 91. http://speakerrate.com/talks/280