Pull in Viget posts
This commit is contained in:
85
content/elsewhere/stop-pissing-off-your-designers/index.md
Normal file
85
content/elsewhere/stop-pissing-off-your-designers/index.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: "Stop Pissing Off Your Designers"
|
||||
date: 2009-04-01T00:00:00+00:00
|
||||
draft: false
|
||||
needs_review: true
|
||||
canonical_url: https://www.viget.com/articles/stop-pissing-off-your-designers/
|
||||
---
|
||||
|
||||
A few weeks ago, our local [Refresh](http://refreshthetriangle.org)
|
||||
group pitted me (representing web developers) against Viget designer
|
||||
[Mindy](https://www.viget.com/about/team/mwagner) in a battle for the
|
||||
ages. Our talk, "Ten Things Designers Do That Piss Developers Off (and
|
||||
Vice Versa)," offered a back-and-forth look at some of the issues that
|
||||
crop up between web professionals. Despite the overwhelming strength of
|
||||
my arguments, I won't deny that she got some good shots in. Here are
|
||||
some of the key lessons I took away.
|
||||
|
||||
### Stay off the bandwagon
|
||||
|
||||
One of Mindy's best points was the tendency of developers, when
|
||||
selecting technologies to use on a project, to go with what's new and
|
||||
hip rather than what's the best fit or what will yield the best final
|
||||
result. I think we can all relate to learning a new technology or
|
||||
technique and then wanting to immediately apply it to whatever we're
|
||||
working on.
|
||||
|
||||
Technology bandwagon-jumping goes hand-in-hand with another common
|
||||
problem: over-engineering. In my experience, when a chosen technology is
|
||||
a bad fit for a project, it's typically because it's too powerful. An
|
||||
over-engineered solution is a nightmare for the next developer --- in a
|
||||
past life, I maintained a Spring-powered, Lucene-searchable monstrosity
|
||||
running on dedicated hardware that would have been better served with a
|
||||
WordPress install on Dreamhost.
|
||||
|
||||
When selecting technologies, stick with the best fit, whether that's
|
||||
what you know best or what will lead to the best final product. If
|
||||
you're just dying to try out some new technology, do what I do: redo
|
||||
your personal site (in lieu of actually posting any new content to it).
|
||||
|
||||
### Avoid the knee-jerk "No"
|
||||
|
||||
Picture this: you're sitting at your desk one morning, happily reading
|
||||
Hacker News, when an IM window pops up on your screen. It's your PM, and
|
||||
she's got a new feature request from the client. It's not a major
|
||||
change, but it will involve a substantial overhaul of the messaging
|
||||
system you built. What's your response? Be honest --- you give her
|
||||
seventeen reasons why the requested change is a bad idea.
|
||||
|
||||
When discussing feature requests, keep in mind that the ultimate goal is
|
||||
to create the best product possible. Requirements change, and though it
|
||||
sucks to complicate elegant solutions, sometimes change is necessary. As
|
||||
an added benefit, if you avoid staying "no" instinctively, when a
|
||||
*truly* bad idea lands on your plate, your objections will carry a lot
|
||||
more weight.
|
||||
|
||||
### Remember: you are not the user
|
||||
|
||||
Mindy noted a trait common to many developers: a lack of empathy for the
|
||||
user, or rather, the mistaken idea that we ourselves are the typical
|
||||
user. In other words, developers are prone to creating features that
|
||||
they would want to use, regardless of how well they might serve the
|
||||
actual audience of the site.
|
||||
|
||||
When deciding on geeky features, it's important to keep your audience in
|
||||
mind. If you're designing a site about web productivity, by all means,
|
||||
go nuts --- bookmarklets, keyboard shortcuts, customizable RSS feeds,
|
||||
the whole nine yards. But if your site's intended audience is, say,
|
||||
gardening enthusiasts, your time would probably be better spent
|
||||
elsewhere.
|
||||
|
||||
### But in the end
|
||||
|
||||
We all want to create the best web sites possible. Disagreements arise
|
||||
about definitions of "best"; while a designer wants a site that's
|
||||
attractive and intuitive, the developer wants one that is stable and
|
||||
maintainable. In the end, these qualities aren't mutually exclusive ---
|
||||
the highest-quality websites have them all.
|
||||
|
||||
Mindy has posted [her
|
||||
thoughts](https://www.viget.com/inspire/stop-driving-your-developers-crazy)
|
||||
on the talk, and our slides are available on
|
||||
[SlideShare](http://www.slideshare.net/mindywagner/10-things-designers-do-that-piss-developers-off-and-vice-versa).
|
||||
And if you're in Durham (or lesser nearby cities), come on out to the
|
||||
next [Refresh](http://refreshthetriangle.org) meeting.
|
||||
|
||||
Reference in New Issue
Block a user