On
15 January 2009 tagged TILTHW, Work
In this series, I’m exploring the stories about work I find myself coming back to a lot. I call them Things I Learned the Hard Way.
I’ve already talked about designers and how their critique training makes them impossible to work with. Now let’s look at the other side of the coin: programmers.
In Genesis, God creates things in a certain order. Why plants before animals? I dunno. It just seemed right to Him. (Don’t worry, it’s just a metaphor.)
Programmers are the same way. In any programming language, there will be many ways to solve a problem. The right way to do it is a personal decision, made by the programmer, just like in Genesis.
Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies.
So it’s no wonder that, in team meetings, programmers can behave like fickle Gods. “No we couldn’t possibly do it that way,” they’ll say. And they may have reasons, or maybe it’s just not the way things are done in their universe.
So if you’re working with a programmer, you have to treat him or her like a God. You have to pray. You cannot issue edicts. You have to come on bended knee. “Here’s the problem I have. I need a solution. Please help.”
The good news is, programmers want their work to be used, and the good ones know that the design matters. So programmers and designers actually have the same goal: getting the stuff used. If each can honor the talents of the other, great things can happen.
A good technique I’ve found is to be very specific with the result I’m looking for, and the reasons why. “When a user clicks X, Y should happen immediately, because if there’s a lag, we’ll lose people.”
Like designers, if you give a programmer a problem with parameters, they’ll apply every bit of genius they have to solve it in the best possible way. If you tell them how to do it, you’ll suffer the wrath of an angry God.
+
Read More Things I Learned the Hard Way »
On
13 January 2009 tagged Community, Design, TILTHW, Work
In this series, I’m exploring the stories I find myself coming back to in work and life. I call them Things I Learned the Hard Way.
My dad, the great psychologist, once told me that he thought kids would be a snap. In college, he’d trained rats to run mazes in the dark. Surely he had a keen insight into behavioral training.
Problem was, rats don’t smile at you, say they’ll be home by midnight, steal your car, and stay out all night. Suffice to say, dad found raising me and my sister to be more challenging than expected.
But he has taught me a few things, and one I keep coming back to is: ignore the content. Sometimes, when dealing with an interpersonal conflict, logically addressing the complaints is that last thing that will help. Instead, try to address the emotion behind it.
So, for example, when a kid is freaking out because ketchup wasn’t applied to his hot dog in just the right way, it’s never about the ketchup. It’s about a deeper issue (control, fear, low blood sugar – whatever).
Apply this to web communities. Say a well-known site, say, redesigns their homepage. The new version could be better in every objective way, but users will still freak out. Why? It’s not the content – it’s something deeper.
The freakouts mean, “I love this site, I feel ownership of it, and you changed it, and that makes me mad.” When you look at it that way, you can see why a reasonable, factual response on why the new design is better will not work. Instead, you have to address the feelings behind the complaint. For example:
“You’re a valuable member, and we really appreciate how much time and energy you’ve put into the site. We know change can be hard, and we appreciate you writing to tell us your feelings. We think the new version is better, but you don’t have to agree. All we ask is that you give it a little time. See how you feel about it next week, and write us again. We’re grateful for your participation, and sincerely thank you for your feedback.”
See what I did there? No selling the new site. Instead, praise the user for giving a shit (and you should – trust me, I’ve run sites that nobody cared about and it’s much worse), try to make them feel important, show that you take it seriously, and ask for a little time.
With most redesigns, within a week, all the bitching is over (or, at least, moved on to something new). If there are major themes in the members’ complains, maybe there really is something wrong. They’re doing you a favor by pointing out the problems. Take them seriously and implement changes. The complainers will become your most dedicated fans if they see that their input results in positive changes.
The next time someone complains to you, try to ignore the content of the complaint and address the emotion behind it instead. You’ll be amazed how quickly you can convert the haters to lovers and make your site better at the same time.
On
13 January 2009 tagged Clips, Community, Elsewhere
I wrote this story for .net Magazine last year. I believe it was published in the December 2008 issue. Looks like it just made it online.
Keep your Web 2.0 community happy
Running a web community can be fun and rewarding, but you’re always reliant on the good faith of your members. So what happens when rogue elements threaten to disrupt, even destroy, the foundations of your virtual society? Derek Powazek has some suggestions.
Aside: I’d never use “Web 2.0” in a headline. It’s a meaningless term now, if not always. My original title was “Don’t Create Supervillians” which helps the story’s lede make a bit more sense. C’est la vie.
