[nycphp-talk] Working with designers
ramons at gmx.net
Thu Aug 20 20:36:36 EDT 2009
Chris Snyder wrote:
>> 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.
> Exactly. When a designer takes on web work they have to learn the
> limitations of the medium: web fonts for body text, no custom form
> controls, no flowed text. I'm happy to educate anyone I'm working with
> about what is a bad idea, what is really expensive, and what is
I think you should rather educate everyone including yourself about what the
end-user wants. It is well possible that the end-user doesn't need fancy stuff
and eye candy, but unless you _are_ the end-user I'd be a bit careful about
ironing over all this with the "we don't need this stuff" approach.
Clearly define what is asked for and required. That is why a business analyst
should have no clue about coding, but know everything about the end-user /
customer. And that for the same reason why developers make really bad software
testers. First figure out what needs to be done and what needs to be
accomplished, which is the point where everyone involved has a chance for
input, but without loosing sight about, yes, you guessed it right, the
end-user (which is often enough the paying customer). If after that there is
still a need for custom form controls or flowed text (or whatever else) then
so be it and it becomes irrelevant what the programmer thinks about it.
The vast majority of software created is not used by those who make the
software, so who are they to say it has to be this or that way?
More information about the talk