Posted by kathysierra
on March 19, 2004 at 9:38 AM PST
Software development principles have been applied to dating. The Half-Bad-Boy-Plus-Protocol dating design pattern might just get you more than a phone number. But what about the opposite? Are software developers exempt from the fundamental principles of dating? Could software developers have something to learn from those with expertise in the art of the Blind Date?
Maybe your mother knows more about software development than you ever imagined. Perhaps the advice she gave you before that fateful blind date--with that special someone your friends convinced you was The One For You--works for software development as well as dating. The assumption here is that you are crafting something that someone else will be using, and it works the same whether you're designing an API for other developers, or an end-user experience rendered through your Swing GUI or browser-based web app.
Wear Your Good Shirt
Face it--how you look does matter. In fact it matters more now than it did before, as we've evolved (for better or worse) into a Culture of Style . The bar has been raised; your target market (not that you should refer to your prospective date that way, but still...) expects more than just functional today. Look at the iPod phenomenon. Dozens of devices play mp3's, and for less money, but people keep choosing sleek and sexy (or today, colorful) over purely functional. In other words, you can't just get the job done--you need to look good doing it.
Now, before you flame me about how surely Ease of Use (and ReUse) is more important than Look and Feel, keep in mind that the two aren't entirely orthogonal. The most successful designers, engineers, and architects in the world understand that beauty lures the user into the experience in a more intimate, engaged way. Quite possibly my favorite geek book in the world is Gelernter's "Machine Beauty" where he explains "how beauty drives the computer revolution: how lust for beauty and elegance underpinned the most important discoveries in computational history and continues to push research onward today."
And come on--can you honestly say that you have never looked at some code, an algorithm, an API, an implementation, or a UI and used a word like "elegant", "sleek", "slick", "cool", "beautiful", or "sexy"? We're human beings, and we're genetically programmed to respond to beauty. Give someone an ugly-yet-functional application or API and they might find it perfectly acceptable, but they won't have that transcendent experience.
In a previous blog about API design, I suggested Don Norman's book The Design of Everyday Things. . And in that book he claims that there's no excuse for making something hard to use. But some of his proposed solutions are a little, well, unattractive. In fact, he rails on engineers and designers for making something look slick (like by using fewer buttons and instead making the existing controls modal) at the expense of usability. And I agree. But why should it have to be an either/or choice? Usability/functionality vs. elegance/beauty? And even Don Norman admits now that it's time for products that will "appeal to the emotions as well as to reason". His new book Emotional Design is driven by his goal to make products more alluring. He says, "For years I worked hard to ensure that products were usable. Now it is time to make sure they are pleasurable as well. Usable, effective products need not be ugly or dull. So, I'm on a campaign to ensure that our products have beauty and emotional impact as well as effectiveness and understandability."
But wearing your good shirt isn't just about looking good--it's about showing respect for the other person. How would (or if you've got some experience with this, how DID) you feel if your blind date couldn't be bothered to even find something clean? Besides, first impressions tend to be metaphorical... I just got off an airplane a little while ago coming back from the Software Development conference. The airplane seat back tray table was a little dirty, and that always makes me wonder, "What else didn't they maintain on this plane?" (a comment which made fellow java.net blogger Sue Spielman say, "Remind me never to sit next to YOU on a plane"). If your code, API, interface gives users a first impression that you didn't take the extra care to make something look decent, that sets the tone for how they view everything they see of yours after that. And it takes a lot more work to undo a first impression.
OK, so does this assume that every product, bit of code, interface, or API has to conform to some extremely high, fully-accepted standard of beauty? To bring this back to dating, does that mean every male must look like he stepped out of the pages of GQ, and every female the pages of Vogue? Of course not! No, I said, "Wear your good shirt", not "Look like a model." In other words, pay attention to aesthetics. Put it on your priority list. It's about acknowledging that the end-user has an aesthetic sensibility, and putting some effort into making what you've got appealing.
Don't Assume You'll Never Have Competition
You can get away with ignoring the "Wear Your Good Shirt" rule while you have no competition. If you're the only member of whatever sex the datee is looking for, it might be less a factor. If you're the only API, product, framework, game in town, for example, you can probably survive and even thrive being sloppy and unattractive. But what happens when you're no longer the only player in the field?
Don't Be Fake
Don't act like you're one thing and suddenly become another. Be honest. Be real. Be yourself. We've all seen software that starts out nice and friendly, and then switches into something different. A long time ago, there was a comparison made between the Macintosh OS and Windows, that went something like this (can't remember the exact original), "With Windows and the Mac OS, it's like you're in a lovely lobby of a nice hotel. But with Windows, you can make one wrong turn and suddenly find yourself thrown into the boiler room." Being clean and honest is better than being a poser. Brenda Laurel, in her book, Computers as Theatre believes a software system should always "stay in character", and that the end-user should be able to rely on what the system initially appears to be.
Be Fun. Be Someone Others Want To Be With. Don't Be Negative.
I wrote my first book using the publisher's Microsoft Word template. I was depressed for about six months. I sat five feet away from my co-author, also working in Word, and I had to listen to him swear several times a day. When we started our next book, we switched to InDesign. And the world brightened. The weather was always a little sunnier. More flowers bloomed in the yard. The pets and kids were better behaved. Of course, this assumes that InDesign was suited for our particular task, and it was, beautifully. But wow--it was like falling in love.
Make a list, even a short one, of the products, APIs, frameworks that made you happy. That made you think, "This is awesome. This is perfect." Now make a list of the ones you struggled with (I'm wildly speculating that this second list will be, um, longer). Next time you design and build something, try to focus on having that thing end up on someone's "made me happy" list. You'll have their undying loyalty and respect for life.
It's Not About You.
Who would you prefer to be with: someone who you are impressed with, or someone who makes you impressed with yourself? Someone who makes you think, "Wow, that person is so much better than I am." or someone who makes you feel, "I rock!"
You know when you're around someone special when they bring out the best in YOU, as opposed to leaving you in awe of who THEY are. When you feel good about yourself, and your capabilities. On the other hand, the people you're less likely to date are those that leave you feeling somehow less capable. Less smart. Less attractive. Less clever, less interesting, less... you get the idea. Way, way too many APIs, books, products, interface, programs, seem designed to get the user to recognize how smart the designer was, when the most appealing products should leave the user recognizing how smart the USER is. If the API you design leaves the programmer feeling frustrated and stupid, they'll run like hell the next time they're given a choice between something that you've designed and something from another candidate. And we all know that lowering someone's self-esteem is NEVER a good recipe for bringing out someone's finest work.
So don't focus on what YOU do... focus your energy on that other person. Paste a picture of him or her (and if you're building for a large unknown group, just pick a picture of someone who represents a member of that target group) on your monitor. Always remember that your work is about THEM, not YOU. Instead of thinking, "What cool thing can I do?" think, "What cool thing will my work let him do?"
Your mother warned you about good manners. Imagine you're on a first date and suddenly the person you're dating just gets up and walks away, without a word. No indication of where they're going or when they'll return. Ever had a software app do that to you? The little things like progress meters REALLY matter. If you don't think it's good to be rude, then don't have your software apps be rude either. Let people know what's happening. Reassure them. Reduce their stress.
There are a lot more I could add here, like "Be Memorable. Be Engaging. Be Interesting. Be a Good Listener.", but I think the main point I'm trying to make is that crafting something that another human will use should be taken as seriously as any other important human interaction. I'm often shocked at how people will pull out all the stops to try to impress a prospective mate, but appear to care less what their end-users think and feel. Of course, I'm guilty of the same things and no shining example myself. This is something I personally have to work on every step of the way. I DO wear my good shirt on a first date. Yet I've found myself making excuses for errata in a book that with a little more effort I could have prevented.
But I think there's a fairly simple solution, and it gets back to the first blog I made here--make the receivers of your product or service humans. Not abstract "users" that appear on a report somewhere. Not abstract "customers" or "programmers", but REAL living breathing people. Find ways to force yourself to see those who receive your work as individuals with needs, concerns, issues of their own. You KNOW how it feels when you do something that delights someone, right? Like, when you cook something for someone (which in my case, is limited to grilled cheese and pancakes, but still... I'm brilliant at them), and you watch their face intently as they chew the first bite. You're looking for that little smile... that subtle way their face lights up and you know you've made them happy. Think about the ways in which someone else's pleasure makes you feel good. If you can truly conjure that sensibility when you're designing a product or API, you'll have to hire a bodyguard to fight off the rabid fans.
I'm serious about the picture thing. I pasted pictures of customers in my cube. I made a sign when I was at Sun that said, "Someone just paid $3,000 for my service. Was I worth it?" and eventually I started seeing those same signs tacked up throughout our building. (With some minor word changes, although I can't understand why... ; ) And if you're a manager, encourage your staff to watch video tapes of REAL people or better yet, TALK to real customers. Last time I blogged about this someone commented that if management is doing their job correctly, workers shouldn't have to have any contact with customers. In other words, the spec should say it all. But what I'm talking about goes beyond the cold, hard, specification and into the realm of emotions and beauty and passion.
I have to believe that if I had a webcam at home, and the developers of Adobe InDesign could watch me at work, it would make them happy to hear me say, "I LOVE this program!" at least once a day (and this is after more than a year of full-time use). That doesn't mean that I don't have some issues and complaints, but as it is with any worthwhile relationship, when you're head over heels in love, you don't dump them just because they don't meet every possible need.
Perhaps instead of reading so many technical books, developers should go back and ask their mothers for some good old fashioned dating advice. And hey, just because you're already in a long-term, committed relationship doesn't mean you should take ANYTHING for granted. Imagine how delighted your long-term partner would be if you came home one day acting much the way you did back in the days when you were still trying to impress them ; ) Just because you've got customers you don't believe can, or will, go anywhere else shouldn't be an excuse for slipping on the fundamentals. Putting a smile on someone's face can be so easy... you can usually delight someone simply by doing just a tiny bit more than they expected. Imagine a world where we all work just .01% harder at trying to put a smile on someone else's face : )