"No matter how talented you are, if you are a C, your talents will often be watered down by A and B. If you want more power, there’s only a limited amount A and B will be able to grant, no matter how much they need and respect you."

Thanks a lot for the comment.

I'll try to answer your points:

1) "The tools do not give complete control as claimed" … you are right, because in real life, you still need some old-school specifications, but they should be enough, and for me I see multiple reason it is not the case, and won't be very quickly:

* you need some kind of “agile” process, where prototyping equal implementation, and specification roughly equal prototype (My program manager won't like that )

* But above all you need to communicate with your client …and he knows MS word…

2) Agreed : I prefer the Control term, over Widget for the "UI technologies" part, it is why I have introduced "Control" in my glossary (the yellow table). The Widget term have effectively been stolen to describe mini application either in a browser or in a native container, this will be part of a later article.

We have begun some work about this Interaction Designer and Engineer interaction, if you have some inputs, or want to share data, I'll be very happy to do so.

1) The tools do not give complete control as claimed, a proper specification document and process can ensure that the person with the correct ability is able to influence the system at the appropriate time. (Software that supports makes life a lot easier).

2) Widget is poor terminology when covering these three disciplines as they could be different things to different people (An application developer and a web developer see widgets as very different things). Additionally in the mobile area it is coming to mean a mini-application running in a dedicated container.

I also think you have highlighted a gap that creates issues with development, by the lack of formalization in the relationship between the Software Engineers and the Interaction Designer

The Interaction Designers today are not as good as they should be of extracting from and agreeing with the software engineer what the impact of certain application events will be in terms of the user experience. Certain application events will take a few seconds (establishing network data connection or heavy requests to a server are good examples). The point at which these events occur and what is communicated to the user at this time is not accurately captured in a screen flow or screen layouts and needs an enhancement to most UI documents I have seen or a dedicated User Experience (UE) document developed after the screen flow has been agreed.

One small note the: The Interaction Designer is also responsible for defining what is to be captured by a screen, not just presented but I see no controversy here.

What I've said is not that technologies is enough to overcome the issue.

It is more, like you said, a Development flow, by development I mean the flow from Marketing for definition, to product management, development, test, etc…and who actually is in charge and responsible for the product delivery: if it is the engineering team, we are screwed, the Interaction Designer has to be responsible for THE END RESULT and not only the design. It is were technology is mandatory but not enough…

You are right, and it was not clear in the article that this notion of responsibility for the finished product (what you depict as "Who has the most control over how well a thing is made?") is the key point.

Thanks for the clarification Morten

Thomas

(You know, Interaction Designers are never satisfied! )

The engineers’ primary task is to implement functionality. When resources are sparse, that's what he or she will focus on. There is also the issue that software engineers are often more interested in the "inner workings". Implementing usability might not involve a programming challenge or a new technology.

You seem to suggest that this problem can be overcome by better technology, and I tend to disagree on that. I believe that the main problem is organizational, not technical. If you want a good UI, you have to put people that focus on a good UI in charge.

Of course, when the user interface can be declared in a markup language, which is a very important benefit. Especially where there are good UI tools available.

An organizations ability or create usable products are not dependent on their choice of technology. Scott Berkun says this better than I can; here is a quote from his blog:

No matter how talented you are, if you are a C, your talents will often be watered down by A and B. If you want more power, there’s only a limited amount A and B will be able to grant, no matter how much they need and respect you.

(http://www.scottberkun.com/blog/2007/usability-is-not-a-verb/)

I really prefer your term of "interaction designer" over mine.

ergonomics specialist is more of an adaptaion of a french word (yes, I'm a froggy) than really what I had in mind. I'll modify the article to reflect that, thanks.

I'm coming from the handset world, more with an ODM vision…where UI design and user experience flow are , hum, let say prehistoric, for the majority of actors. In this world UI are defined in a big MS Word document, and software engineer are trying to code in in C…those technologies allows to put in place new flow, with strong added value in the definition and design phase.

I say this as an engineer, ergonomist, interaction designer, business manager. Knowledge acquired in that order.