Design Loves Small Business

From a 2007 Ted Talk by Eames Demetrious:

“The role of the designer is that of a good host anticipating the
needs of their guest.”

In the last while I’ve heard this subject come up a lot, so I thought it’d be worth starting a topic.  I was surprised I had so much to say about dealing with developers.  I currently work at a very small company, less then 20.  But compared to the other stories I’ve heard lately from Interaction Designers like myself, our company gets surprisingly consistent results from our developers in regards to design.  Following are my 13 lessons that have helped me get better results from the developers I’ve worked with.

1. Be a developer

I can’t stress this one enough.  Development isn’t something that can be appreciated, it has to be experienced.  HTML and JavaScript don’t cut it, you have to go out and actually do what your programmers do.  Write SQL statements, create classes, build an application.  When you can follow along and contribute intelligently to all the technology discussions, the developers will start to trust you that you understand them.  Let alone the fact that you will be able to call them out on their bullshit, and yes they bullshit a lot.

2. Get in bed with the business people

At the end of the day the business people run the company and they control what the developers do.  At my company I spend a great deal of time with our project manager, VP and CEO.  I try to develop personal relationships with them.  I make it obvious that my goal in life is to help them articulate what they want to the development team.  Then when I present something to the development team, it’s not my idea, this is what the boss wants so you better get it right.  There is nothing more powerful then presenting a finished interaction document to development and saying that this is 100% approved by the CEO.  And in the end the developers are actually happy you managed all that back and forth crap with the business guys so they don’t have to.

3. Ease their pain

Developers just want to develop.  They don’t want to worry about requirements gathering, deadlines, art, research, politics and all the stuff that goes into running a project and a company.  So the more you take responsibility for all these things they don’t want to do, the more reliant they will become on you.  When they need something from you, do it fast and with a smile.  The more enjoyable you make their lives the more responsive they are going to be when you ask them to do things.

4. Force business to iterate in design, not in development

There’s nothing a developer hates more then spending months on something that once the business guys see it they realize they want to do something else.  I won’t hand anything off to the developers until I have thought it through and iterated through it with the business guys as much as humanly possible within the time I was given.  There are many decisions that can be made off of drawings rather than programming it.  And business will quickly realize that getting the designers to change their designs is a thousand times cheaper than paying those expensive developers.

5. No one gives a rip what the artist thinks

The irony is they hired you to be the design expert, but they never listen to what you say.  And guess what, they never will.  You have to get over the illusion that they will do what you say because you know better, it doesn’t happen.  To be happy you have to accept the fact that you will never get to design what you want.  Instead you have to learn to enjoy the reality that you are there to facilitate and assimilate everyone else’s ideas into a single coherent whole.  If you need an artistic outlet, do it at home, or you’ll always be bitter.

6. But you do get to do what you want

Once you’ve checked what you want at the door, something amazing starts to happen.  The funny truth is most business guys and most developers don’t want to think about the details, so you get to!  Other people on the team only care about their pet features, no one wants to take all that time to think through the rest.  So as long as their pet issues are represented, you get to fill in the rest with whatever you want.

7. Write it down!

The beautiful thing about writing is it’s the universal standard for communication.  Yes a picture is worth a thousand words, but you cannot draw interactions as well as you can write them.  My documentation is a mix of what we call “stories” with supporting graphics at key points.  My friend is an html guy at a large company and his biggest complaint is that he gets handed a large photoshop file with no documentation.  Somehow he is supposed to read the mind of the of the designer to figure out what actually happens in ui when the user interacts with it.  The designer has failed to communicate the interaction.  Writing is a royal pain in the ass, but it is incredibly effective at communicating the interaction to the developers and the QA team.

8. Get in bed with the QA team

The QA team is the group of people whose job it is to tell the developers they did it wrong, they are your enforcers.  The better they understand what you wanted from the developers the better they are going to be at telling the developers what they did wrong.  It’s critical QA has the right kind of documentation to do their job, and you want to be in charge of that documentation.  The cool little secret about QA is that they like checklists.  I write my documents so that they are essentially checklists that the QA team can say, hey dev, item 3.i.b is wrong, fix it.

9. You have to have a middle man

Developers do not like to do HTML.  It’s a fact of life that will never change.  As much as they think HTML is easy, it takes just as much concentration to do HTML as it does any other kind of development.  In my experience the very best scenario is to hire a UI developer to be the middle man.  In the web world this is called a Web Designer.  A Web Designer is someone who cares about the visual details, but they can also code.  If you don’t get this guy you’ll always be fighting a losing battle with the developers because they don’t want to do HTML, they don’t give a rip about visual details and you don’t have the time to program the HTML either.

10. Sit next to them

There is a direct correlation to your physical distance from the developers and how effective you will be with them (remember Fitts’ Law?).  Currently I sit right next to my developers.  I hear everything they say, I’m accessible, we go to lunch, I know what they are doing and saying.  If you hide in an office or work off site, you’re screwed plain and simple.

11. Spend time with them

This one should be obvious, but there’s a basic rule that the more time you spend with someone the better you are going to be able to interact with them.  Be friends with the developers, kick their ass in Team Fortress, go to lunch, carpool, whatever it takes.  Get in their face and take as much time to figure them out as you do figuring out your customers.  Do you even known your developer’s names?  Have you spent enough time with Derron to understand why he is such a grumpy prick?

12. Learn to articulate well

This is where studying design comes into play.  Design is difficult to communicate verbally, it’s naturally an intuition and feeling thing.  But the cold hard fact is no one is going to trust your feelings, people will always want reason and logic to make decisions.  So you have to learn to verbally articulate your feelings.  The good news is there actually is logic and reason to art, but the bad news is it’s one of the most complicated things on this planet.  Learning to verbally articulate design takes time, there’s no way around it.  You simply have to study it.  Study how other designers talk, learn patterns and read design literature like a mad man.  And what will start to happen is you’ll actually be able to argue for a design and win.

13. Good design is always hard to program

I finally realized this universal truth.  What makes sense to a computer does not make sense to a human being.  It takes a lot of hard work to get a computer to speak human.  This is what you are trying to do as a designer.  Developers are incapable of this because of the very fact that their job is to speak computer.  Your job then is to force the programmers to make the computer to do something it was not meant to do.  That will always mean that have to personally generate an incredible amount of extraneous code, blood, sweat and tears, everything they hate.  This is why there will always be an eternal conflict between developers and designers, because your job is to make their life difficult, plain and simple.

That about sums up what I’ve learned so far.  I hope this is helpful in some way.  The painful truth is that design is a pain in the ass, and getting developers to do what’s right for the users is like standing against a raging river. It’s not natural for developers to do good design, it goes against their nature.  Your job as a designer is to deal with this fact and somehow still get those developers to produce something human beings enjoy using.

What do you think?  What have you found to be effective?

Just came across a great quote in Alan Cooper’s book About Face 3: The Essentials of Interaction Design. The quote perfectly sums up why programmers cannot do design when they are programming:

[...]building an animated status display into the face of a program might require a thousand or more lines of code. Programmers cannot be expected to make the right choice in this situation. They have a conflict of interest, so designers must be sure to specify precisely where information is reported on the surface of an application. The designers must then follow up to be sure that the design wasn’t compromised for the sake of rapid coding. Imagine if the contractor on a building site decided unilaterally not to add a bathroom because it was just too much trouble to deal with the plumbing. There would be consequences.

One thing I’ve learned in my years designing is how to tell when your design is getting good and near completion. Basically the way you can tell is when the people you show the design to start nitpicking about the little details. Typically when someone reaches this point it is because they are comfortable enough with the big stuff that they really aren’t noticing it anymore. I’ve learned that people notice pain more than the absence of pain. If some element of the design is not causing them some kind of pain, whether it be sensory overload or clashes with the other design elements, then it goes unnoticed. People won’t tell you what is good in your design, even though you wish they would, typically only other designers will tell you what is good. But you can tell when a normal person thinks a design is good by the fact that they don’t say anything about it, because they don’t notice it. Some of my most fulfilling moments have been when I walk into a final design review and no one has anything to say. They start talking about the weather or some other project. That’s when I know the design is done, when they aren’t complaining anymore.

Our VP of marketing likes to quote the movie Amadeus when there is too much going on in a design.  In the movie, Mozart has just finished the first performance of his new play for the Excellency of Vienna.  His majesty comes up afterwards and compliments Mozart.  Then this exchange happens…

So then, you liked it?
You really liked it, sire?

Well, of course I did ! It’s very good !

Of course, now and then,
just now and then. . .

. . .it seemed a touch. . . .

What do you mean, sire?

Well, I mean, occasionally,
it seems to have. . . .

How shall one say. . . ?

How shall one say, direktor?

-Too many notes, Majesty?
-Exactly. Very well put.

-Too many notes.
-l don’t understand .

There are just as many notes
as I required, neither more nor less.

My dear fellow, there are in fact. . .

. . .only so many notes
the ear can hear in an evening .

Great art comes from knowing what is really unnecessary and having the guts to take it out, because even though I may love it, there are only so many notes one can hear in an evening.

http://www.youtube.com/watch?v=IG3rgIaXdpk&feature=related

As I am working on a windows app UI, rather then a typical web UI, it is becoming very apparent to me the need for a front-end developer.  A front-end developer is the guy who programs the UI elements and interactions.  In the web that’s the html/css guru.  But in the windows world there’s not really a common equivalent.  So what ends up happening is you get stuck with the canned controls that come with visual studio.  The canned controls are great and based on universal needs, but in web UI you get used to the flexibility of designing a UI to an exact interaction situation.  Canned controls don’t let you do that, I find them too limiting.  Especially because I know there is not a front-end guy who will correctly interpret what I design into a finished UI.

Watching Jonathan Arnowitz’s Interaction 08 presentation today.  His topic was on effective prototyping methods.  He said something interesting about who’s job it is to come up with ideas.  Basically he said, and I agree, that the designer’s job isn’t to come up with ideas, it’s our job to facilitate the ideas of everyone involved and then assimilate them into a final design.  Or as he puts it, you have to make sure there is a designer is in the driver’s seat, but the ideas should come from everyone.

http://interaction08.ixda.org/Jonathan_Arnowitz.php

Our VP of marketing, and a good friend of mine, often refers to design and UI work as nothing more then arranging the deck chairs.  By this he means it does nothing to increase the revenue of the company.  Obviously his focus is on revenue.  But I am undecided if he is right in all cases.  I don’t have an easy answer back.  I do believe he is right to some degree.  Many times I will see that a website got a redesign and I’ll know that in the end it was a complete waste of time except to satisfy someone’s desire for different aesthetics.

I was talking to a friend of mine today about focusing on one thing versus spreading yourself too thin as a company.  His thought was that the important part was to finish what you start.  But once you finish you deduce the next biggest opportunity within your company’s strategy and then pursue it even if it doesn’t seem to relate to the last thing you finished.  But it’s critical that it still fits within your company’s broad strategic framework.  If it doesn’t, then that is when you are foolishly spreading yourself too thin.