[nycphp-talk] Working with designers

David Krings ramons at
Thu Aug 20 20:26:14 EDT 2009

Ajai Khattri wrote:
> On Thu, 20 Aug 2009, Chris Snyder wrote:
>> Yes, designers should have HTML experience. But the best designers
>> think visually, and need to have the freedom to do that.
> The only problem is when a designer comes up with a design that can't be 
> expressed in HTML or doesn't work easily with your coding framework of 
> choice. That's what I mean when I say the HTML knowledge should inform the 
> design process too.

That would be nice, but you rather should choose the tools that suit what you 
want to do, not the other way around. Way too much software is dumbed down or 
misdesigned just because some framework doesn't do this or that or the 
developer is too lazy to make it so. I encounter this plenty of times and like 
to call it "developer arrogance".
So if HTML doesn't work, use something else. Use Flash or Silverlight, or 
rethink the idea of making this app a browser based app. I am sure there are 
several other options. I heard the "VB cannot do that" whine way too often, no 
interest in hearing the "HTML cannot do that" whine. I know that HTML is 
limiting and that the stateless process is a pain in the rear at times. AJAX 
helps here a bit, but I think that heavy use of client side scripting makes 
for a bad end user experience.
Good that I mention that, it all comes down to what the user wants. Not what a 
designer or developer think what the user needs - or what the sales guy 
thought he remembered from the last phone call.

At the company where I work we have one developer who left the team of 
developers to focus solely on UI design, mainly for our browser based 
applications. He crafts the UI and using his developer knowledge crafts it so 
that the "behind the scenes" code is easily attached. But he no longer worries 
about how things are calculated, how they are stored in the database, or how 
the stored procedures work. He also often provides input for our desktop apps 
and it is amazing how much you can get from a really simple solution.

I also worked with designers at my previous job who took the more or less raw 
material and the embedded that into a UI. That was the exact opposite approach 
and there the designers prettyfied the rough, but working product.

Either way, the designer (meaning UI designer, not product designer) shouldn't 
just be a graphics artist or be treated as a sidekick. From product idea over 
coding, testing, UI design to sales and support get everyone involved from the 
beginning and have everyone fully understand what is supposed to get 
accomplished. If the project lead has no clear vision and there is no proper 
statement of scope, functional requirements, and tech specs you run into 
trouble, usually later than sooner. So when working with a designer clearly 
express expectations and document those. Rather spend a few hours more upfront 
to really get things nailed down. And there is also nothing wrong with drawing 
a picture or prototyping. Many people can't really grasp how something will 
look like, they need to see it, even if it is just a cheesy mockup.


More information about the talk mailing list