What frustrates me the most is many developers seem to think you cannot have both. Sure it may take longer and end up costing more but most times it’s worth that type of investment towards precision and quality that pays off on the user end once released.

However, by knowing your developers, and establishing a good amount of communication with them, you can understand when they’re really struggling with a design, and when they’re just being lazy to get it out the door.

So when they say “That design can’t be done on the current platform.” I like to ask them something like. “Okay, so what sort of thing could we do to overcome that restriction of the platform? Could we talk to someone else to get a branch?”

Certainly it’s important that if the design is just a small little thing that you don’t feel too passionately about, then perhaps you should just let it go. But if it’s an amazing thing that is gonna really kick ass, then definitely push development to find the solution!

I’m careful to never say “impossible” or “too hard” or “no” as I’ve found that they do raise the blood pressure of the Owner/Designer of the company where I work and you’re right, nothing’s impossible. I give estimates. If they’re looking for a piece of software that would be “nice to have” if it takes < 8 hours to do and I tell them it’s going to take 80 hours then it’s like a “Virtual No” I guess. It becomes a decision for the designer as to whether to pursue or not based on the business case. “So actually, I NEVER say NO!” said Ben in his most bombastic, pompous, know-it-all tone. .

Caveat: If I’m a great developer and am on the bleeding edge and using the best software design principles and know my software design patterns cold and wicked smart and get things done and and use excellent software development process maybe I could do it in 8 hours.

Obviously some developers are better than others so what’s an 80 hour painstaking wrestling match for one may be an 8 hour job for the uberdeveloper. And hopefully he/she won’t cost 10 times as much. Even if they do you’ll save on opportunity cost. You’ll be shelling out money fast, but getting lots of cool software fast too. Of course this is an extreme example. (Hint, hint: hire awesome developers and pay them awesomely!)

So here’s my opinion, if I may. You’re always going to hear “no” more often from your developers then you get to say it to them as an Owner/Designer by nature of the relationship. If your developers are giving you estimates that are longer than you hoped (the “virtual no”) and you’re frustrated by that, ask them to put more detail into how they’re coming up with that 1 month estimate when you instinctively feel like it should only take a day or two.

All lack an understanding of good information architecture and organization.

A former tech boss once said to me, “As long as electrons are flowing back-and-forth, anything is possible.” This philosophy has opened up my thinking to what is and isn’t possible as a programmer. Most of the time I get designs that are simply bad for the user for multiple reasons. But when the design sings, is “right” for the user — and it’s still a challenging design, I’ve been able to find way.

PS: CEO’s and COO’s make horrible designers. For the love of Pete, lock-up and gag your CEO or COO until the project’s done!

One is the practical, the logical and the measurable. The other is emotional, subjective and always in flux. They are both different forms of problem solving. Are we talking about things that are completely non-related? No, I don’t think so. I do accept there are some parts of coding that simply don’t translate to design and vise versa as Steven suggested.

Anything that helps designers and developers relate to each other and the work they do better is a good thing I think. I hope this post helps illustrate that.

FWIW, I was always in favor of Cabel’s toolbar, because I felt it was an important visual cue to the way Coda’s toolbar specifically works. I hate the word “impossible” and I bristle any time I hear it at our office. So, I spent a couple weeks trying to make that toolbar work, and I wasn’t the only one of us to make such an attempt.

We were getting into method swizzling, and all kinds of related nastiness, and while it worked about 80% of the time, there were still problems, such as when you dragged the toolbar items to re-order them, it would leave pixels behind. The root of the problem was in the system code that draws the toolbar. It simply doesn’t draw the entire height of the toolbar in all cases, as would be necessary to achieve the desired look.

So, my next step would have had to have been something like mach_injecting code or somehow patching the system frameworks, thereby affecting all running applications. Would it have been possible? Eventually. Was the designer’s vision REALLY worth comprising the integrity of the entire OS? That was the reality of the decision.

That’s why we decide to write our own toolbar. It accomplished the design goal, and the only sacrifice was losing the ability to re-order items, rather than our code infecting every app on the system.

But the argument was never that it was “too hard”. The argument was “it could take a month or two to reverse-engineer the OS frameworks and implement a patch that will almost certainly break with every subsequent OS update, or we can roll our own toolbar. How should we spend our time?”

The only parallel situation for a designer I can think of is to imagine if you made an icon that had to be completely dependent on another icon. If the other icon changes by even a single pixel, your icon disappears from the user’s system. Furthermore, the other icon you’re dependent on is maintained by someone else who works at a different company, who has no obligation to ensure that your icon remains visible. You also can’t see the other icon, but there’s someone who can describe it to you. Periodically they update this other icon, and every time that happens, you have to update and re-release your icon. If the other icon changes significantly, you might have to completely start over.

Is this an impossible situation? Of course not. Is it too hard? Not really. Is it a wise investment of time?

Believe it or not, most programmers love challenges. The whole messy business is about solving impossible problems. I don’t think any programmer worth his/her salt would use “too hard” as an escape hatch to avoid work. They are probably trying to hint that you are entering a potential world of update and support hell.

There’s no satisfaction to be gained from the “one is harder than the other” conversation. They are just different. You can lament that difference, which is what I think you are frustrated with, or celebrate it. I am filled with joy when I look at something beautiful, and I think I appreciate it so much because I am not capable of crafting it.

Even saying that you must weigh these hard decisions with ‘common sense’ won’t get you anywhere, because in the end, what is common sense? It’s no common sense to re-implement an entire toolbar for a slight change in appearance… or is it? I think opinions will vary enormously, and while I am a fan of that notion, others may regard it as valuing design unrealistically high.

I constantly struggle with my cases when it comes to interface design as well; is this feasible? Is it pragmatic to implement? All too often, clients are all too happy to spend weeks on implementing some new type of nonstandard view or control that lives or dies on my design skills, but in the end, it’s a careful consideration of the situation and the big picture that helps you gauge if you must do it or not. And I think, in most of those cases, design does go over development, because with the right judgement, you can minimize the time spent on ‘inessential’ coding, and maximize the benefits of your users.

Excellent post!