One-Way Street
Let me just say up front that the engineers, programmers and developers I work with are some of the most talented people in the industry. They manage to write software and code few others have the skill to create, and I am often in awe of their abilities. That being said, I’ve recently been reminded of an inequity between designers and programmers which I have to get off my chest.
Last week I watched the excellent video from the C4 developer’s conference with my friend Cabel Sasser of Panic fame called Coda Confidential. Something he said in his presentation struck home. At the 22 minute mark Cabel starts talking about Coda’s “Toolbar of Doom” and the implications the toolbar had on his developers. If you’re not familiar with the story, you can listen to the description of the problem from the C4 video, or check out Cabel’s blog post on the subject. The short version is that Cabel designed Coda’s toolbar to appear a certain way, the way he knew it looked best. But it turned out that designing it this way was hard. Very hard. After trying to bend the Cocoa toolbar implementation to their will, they decided instead to throw in the towel. And when Cabel says “throw in the towel” he means write their own toolbar code. From scratch.
Despite their impressive ability to solve the toolbar design problem, Cabel makes the point that he’s constantly “choosing his battles” between himself and the programmers at Panic. They don’t always have the luxury of writing code from the ground up to solve a particular design problem. They are constantly asking themselves is this particular design decision worth the time and effort it will take to implement? As I know from personal experience, sometimes the answer to that question is unfortunately, “No”. As a co-owner of my company, like Cabel, I’m constantly looking at the “big picture” to determine if a difficult design is worth the time and money required to implement it.
But from a creative point of view, purely as a designer, I still find it frustrating that the ideas and creations I come up don’t always get implemented. Some are considered “too difficult” or “too time consuming” to put into practice and therefore must be abandoned. I consider this to be a double-standard in our industry between designers and developers. As a designer, I’ve almost never told a developer I’m working with that a particular icon, user interface or web design is “too difficult” to implement. In my entire career, I think I’ve said “no” a grand total of 2 or 3 times. And that only happened because someone asked for something physically impossible, like making a 5 letter word legible at 16×16 pixels. I realize the programmers reading this will probably say “that’s because coding is more difficult than designing”. This may or may not be true, but that’s a whole other topic for discussion.
I know that even programmers themselves can’t always create the software or features they dream up, but it seems like they often have “outs” that simply don’t exist for us designers. We’re always expected to push through and solve the problem, while for them, something is either technically not feasible, would take too long to implement, or is simply a bad idea due to poor user behavior. Just once, I’d love to be able to tell a developer who’s asked me to solve a design problem “Nope, it’s too hard. Not gonna happen.”
I know that given enough time and money, pretty much anything is possible, and unfortunately most small software companies are not made of gold. We must therefore attempt to balance our desires as designers with what is best for the success of the product. I also know that the balance between a talented designer and a skilled programmer can transform mediocre titles into outstanding apps. I just wish I had the ability to even the score every now and then. I take solace in the fact that often as designers, we’re usually only limited by our imaginations rather than API’s or function calls. Our relationship may indeed be a one way street, but for developers, it’s often littered with road blocks.
Valid points you make. I must say I’ve been very conservative when it comes to that particular consideration; does design go over development? Does development go over design?
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!
Coding is not more difficult than designing. Coding IS designing. It’s just a question of whether you’re designing the front side of an app or the back side.
The above poster, who calls coding designing, is right in a lot of ways. The one thing that coders deal with, which designers don’t necessarily encounter, is having design decisions made for them by the platform on which they are developing. I am not talking about things like pixel sizes, etc, but rather, actual philosophical decisions. Platform developers have to make philosophical decisions, and then the people who develop on top of those platforms have to either live with those philosophies in order to complete work, or make herculean efforts to rewrite those decisions.
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.
To be honest, I think it’s an apples vs. oranges comparison. Design and programming are both extremely hard when done right, but they’re nothing alike.
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.
Interesting that we now have two people (programmers I assume) who say coding is just like designing, and a third who says it’s nothing like designing. I come from the standpoint that they are indeed similar, they are just two sides of the same coin.
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.
As a designer AND programmer I’ve found the designs most difficult to program are the ones designed by print designers, designers that are inexperienced in good user experience design, or designers that get “featuritis” and begin adding features beyond the requirements.
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!
In my experience as a developer I’m not usually asking the designer to do something, they’re always tell me what they need implemented. So they don’t have much opportunity to say “No” to me regarding product creation. Maybe the double-standard comes with the territory of being the Owner/Designer to some extent?
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.
Excellent post. This is something i always struggle with. I will design something, and then later be told that it is impossible within the current framework / platform, and that the only solution is to do something that either – a) Is inconsistent with the platform, or b) sucks from a usability point of view.
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!
Well said Ged.
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.