[Sigia-l] Designers and Developers

[Dimitri Glazkov]

Hi everybody. My first post. Glad to be here, blah, blah. Anyway, let's
get on with it: 

> But who will lead? Today, it's the developers. The vast majority of
> apps/sites out there are driven by developers. Why? Because 
> they can. They
> can because project owners/managers believe developers are vital to
> development and deployment in a way designers are not.
> 
> Common procedure is for developers to select a 
> product/platform/language/IDE
> long before design is even considered. Even today, design is 
> something you
> "skin" over and, as such, is often skin deep. Architecture, 
> navigation,
> interaction, branding and other aspects of user experience 
> are usually for
> version 2.0, *after* they are shown to be issues. Oddly, I 
> get paid to solve
> these problems, but my goal is to avoid the post-deployment 
> surgery as a
> business practice. Hence, my crusade.

Sign me up. I am with you on that one.

> So how do we get there?
> 
> 1.  Designers have to know much more about the technical 
> ramifications of
> their design choices.
> 

<skipped>

> I don't think you can get a decent web designer job without 
> knowing HTML
> and/or XML, ASP, etc. I expect this trend to slowly expand 
> into middleware
> as well. There's, after all, no point in designing stuff that's not
> efficient, scalable, maintainable, etc.

Umm... Aren't designers going to turn into developers after they learn
all this stuff? And how much would such a genius cost?

> 2.  Prototyping tools have to become dramatically better.
> 
> From business analysts to interaction specialists, the Design 
> team has to
> acquire a way of seeing the impact of their design choices as 
> functional
> models, without writing code or waiting for weeks for 
> developers to build
> them. Pipe dream? Not really. Curiously, I'm beta testing one 
> app this week
> that can pretty much compose a fairly complex web 
> services-based RIA without
> writing any code and deploy it as Flash. More needs to be done here
> obviously, but the historical trend is clear to me: designers 
> need better
> tools/methods to express themselves and their intentions, way 
> better than
> the wireframe nonsense.

Alright, a technocratic approach. Solving process dichotomy by applying
a tool -- to be honest, I myself often find yearning for something like
this. Kind of like installing an electronic voting system to improve the
voting process. Sometimes it works, more often it simply shifts the
problem domain.

But wouldn't this give false hopes to designers that they could become
developers? In a way, isn't this going to be another "curse of
FrontPage" -- everybody thinks they can "just whoop it up"?

> 3.  Developers have to become implementors.
> 
> Writing efficient/scalable/maintainable code is a very difficult job
> already. The incentive for managers shouldn't be to push developers to
> tackle non-engineering aspects of a project, but to hire designers to
> conceive and design the app so that developers can concentrate on
> implementing it as efficiently as possible. We don't want our 
> buildings to
> be "designed" by general contractors why should we want our apps to be
> "designed" by developers.
> 
> There's also another trend afoot here: rapid commoditization of the
> procedural aspects of programming which requires an increasingly more
> demarcated separation of design from development as the latter moves
> offshore. From fashion industry to consumer electronics that 
> has been the
> pattern. This, incidentally, is what makes designer-driven 
> prototyping so
> crucial for the future.

Hang on just a sec here. So, what you are really saying is that
designers have to become engineers? I think I understand the idea, but
isn't this just reassigning the labels? I could also say that what we
need is good engineers who understand design. In either case, so far
both you and me are looking for the super-soldier of Web development.
And those are usually very few, proud and don't come cheap.

> 4.  Designers have to become leaders.
> 
> Above all, this is the key. Designers (with a capital "D") 
> have to assume a
> leadership position in digital app creation so they can seamlessly
> interweave all IA/ID/UI/UX issues into a coherent whole. This 
> should be
> become the Designer's domain and Designer's alone. When a 
> company needs an
> app they should think of consulting the Designer first, not 
> the Developer.
> The Designer, not the Developer, should own and drive the app
> conceptualization, architecture, design, usability process. 
> They should do
> this for the integrity of the app and the benefit of the 
> user. If there's a
> turf to fight for, this is it.

Again, we tacked on another responsibility on our soldier: project
leader and possibly even a client liason.

The fundamental problem of Web development process is not new: it is the
congenitally low cohesion between the right and left sides of the brain.
This problem is historically solved by natural selection: in early 20th
century, there were over 2000 car manufacturers. But cars needed to run
fast, be safe, economical and still look pretty and fit like a glove.
Well, look at us now.

Unfortunately, with the Web development, the entry threshold is so low
("All I need is my trusty FrontPage!") and the industry is so young
("Look at 'em pretty flapping mail boxes! Ain't that grand!") that the
standard of quality is a dotted line in the sand, at best. Besides,
crashing Web site hasn't killed anyone (that I know of), so there isn't
the same urgency to correct the issues of ergonomics and accessibility
as there is with automotive industry.

Well, that came out looking all morose... Alright, here's the positive
note to end this rambling with: 

If we are to solve this problem, we face two possibilities:

1) Train super-soldiers and hope that they can outmuscle the FrontPage
mob.

2) Keep your focus on the process and finally invent something that
balances design, engineering, and implementation with realistically
cheap resources.

And maybe it's both. Who knows?...

:DG<