davideisinger.com

My personal website
Log | Files | Refs | README

index.md (4053B)


      1 ---
      2 title: "Stop Pissing Off Your Designers"
      3 date: 2009-04-01T00:00:00+00:00
      4 draft: false
      5 canonical_url: https://www.viget.com/articles/stop-pissing-off-your-designers/
      6 ---
      7 
      8 A few weeks ago, our local [Refresh](http://refreshthetriangle.org)
      9 group pitted me (representing web developers) against Viget designer
     10 [Mindy](https://www.viget.com/about/team/mwagner) in a battle for the
     11 ages. Our talk, "Ten Things Designers Do That Piss Developers Off (and
     12 Vice Versa)," offered a back-and-forth look at some of the issues that
     13 crop up between web professionals. Despite the overwhelming strength of
     14 my arguments, I won't deny that she got some good shots in. Here are
     15 some of the key lessons I took away.
     16 
     17 ### Stay off the bandwagon
     18 
     19 One of Mindy's best points was the tendency of developers, when
     20 selecting technologies to use on a project, to go with what's new and
     21 hip rather than what's the best fit or what will yield the best final
     22 result. I think we can all relate to learning a new technology or
     23 technique and then wanting to immediately apply it to whatever we're
     24 working on.
     25 
     26 Technology bandwagon-jumping goes hand-in-hand with another common
     27 problem: over-engineering. In my experience, when a chosen technology is
     28 a bad fit for a project, it's typically because it's too powerful. An
     29 over-engineered solution is a nightmare for the next developer --- in a
     30 past life, I maintained a Spring-powered, Lucene-searchable monstrosity
     31 running on dedicated hardware that would have been better served with a
     32 WordPress install on Dreamhost.
     33 
     34 When selecting technologies, stick with the best fit, whether that's
     35 what you know best or what will lead to the best final product. If
     36 you're just dying to try out some new technology, do what I do: redo
     37 your personal site (in lieu of actually posting any new content to it).
     38 
     39 ### Avoid the knee-jerk "No"
     40 
     41 Picture this: you're sitting at your desk one morning, happily reading
     42 Hacker News, when an IM window pops up on your screen. It's your PM, and
     43 she's got a new feature request from the client. It's not a major
     44 change, but it will involve a substantial overhaul of the messaging
     45 system you built. What's your response? Be honest --- you give her
     46 seventeen reasons why the requested change is a bad idea.
     47 
     48 When discussing feature requests, keep in mind that the ultimate goal is
     49 to create the best product possible. Requirements change, and though it
     50 sucks to complicate elegant solutions, sometimes change is necessary. As
     51 an added benefit, if you avoid staying "no" instinctively, when a
     52 *truly* bad idea lands on your plate, your objections will carry a lot
     53 more weight.
     54 
     55 ### Remember: you are not the user
     56 
     57 Mindy noted a trait common to many developers: a lack of empathy for the
     58 user, or rather, the mistaken idea that we ourselves are the typical
     59 user. In other words, developers are prone to creating features that
     60 they would want to use, regardless of how well they might serve the
     61 actual audience of the site.
     62 
     63 When deciding on geeky features, it's important to keep your audience in
     64 mind. If you're designing a site about web productivity, by all means,
     65 go nuts --- bookmarklets, keyboard shortcuts, customizable RSS feeds,
     66 the whole nine yards. But if your site's intended audience is, say,
     67 gardening enthusiasts, your time would probably be better spent
     68 elsewhere.
     69 
     70 ### But in the end
     71 
     72 We all want to create the best web sites possible. Disagreements arise
     73 about definitions of "best"; while a designer wants a site that's
     74 attractive and intuitive, the developer wants one that is stable and
     75 maintainable. In the end, these qualities aren't mutually exclusive ---
     76 the highest-quality websites have them all.
     77 
     78 Mindy has posted [her
     79 thoughts](https://www.viget.com/inspire/stop-driving-your-developers-crazy)
     80 on the talk, and our slides are available on
     81 [SlideShare](http://www.slideshare.net/mindywagner/10-things-designers-do-that-piss-developers-off-and-vice-versa).
     82 And if you're in Durham (or lesser nearby cities), come on out to the
     83 next [Refresh](http://refreshthetriangle.org) meeting.
     84