[Sigia-l] UI job requirements

[Brett Ingram]

Our team is involved in usability engineering and user interface 
desgin. We have passed off requirements to our developers and watched 
them build something... well, something rather different than we 
intended. We have taken up building functioning prototypes for the 
developers to fully understand our design intent. This has meant a lot 
more coding (UI developing) within our team. Many of the people on our 
team have at least a partial technical background in things like HTML 
and Flash, so this hasn't been a problem.

The company has been moving to a .NET foundation for, eventually, all 
of the applications. And we have found increasingly that we get a "it 
can't be done in .NET" response when someone doesn't want to build 
something. So now, we have hired on our team a technical specialist in 
order to provide real answers for us.

In other words, we are becoming more technical in order to do our 
Usability/UI work. As a team, we have been working to counter the 
assault on our flanks that Ziya warns about.

Which has lead me to think its time to start spending more of my time 
brushing up on technical computer skills.

-Brett Ingram


Listera wrote:
> While "regular" designers of web apps may know about the UI-level 
widgets
> and functions of, say, HTML/DHTML, they rarely have an understanding 
of the
> range and limitations of, say, Swing widgets. So, the conventional 
corporate
> thinking goes, why not give that job to a Java programmer who does.
> 
> Is this going to be a problem? As I have been preaching here, 
absolutely.
> This is one of the flanks of UCD that can/will be usurped by 
developers.
> This is precisely why I keep harping on the futility of chopping up 
the
> design processes into million titular bits. There are lots of 
clients out
> there who simply don't want to chop up the design stage to half a 
dozen
> self-important title holders who keep passing "deliverables" to each 
other.
> 
> If the beef against GUI *developers* is that they don't really 
understand
> UCD/interaction, then UC designers must begin to fully understand the
> technical ramifications of their UI choices. This issue will be 
resolved
> when finally functional prototyping becomes the domain of designers, 
not the
> developers, but that's my other obsession. :-)
>