part of the struggle with conversing on a topic as broad as UX in or outside the ASD loop is one of “size.”

for reasonably “straightforward” features that require UX design, a couple of iterations is usually sufficient to get to a good place. my steps are typically:

• understanding the basic requirement (e.g., we need to use a special service to look up critical special info from a ZIP code as part of a custom address UI),
• the domain details (often down to methods/sequence diagrams),
• some dynamic behavior of how the UI might interact with the domain model/server (after zip is entered, make a server call, get the linked lists of the related objects), and a
• rough sketch.

When to spawn a separate UX project

if the team senses that:

• UX is a major and critical aspect of the final product (as something like the iPhone probably was),
• the design is very complex,
• “getting it right” will impact greatly on the success or failure of the product,
• there is a need to explore a handful of design ideas before committing…

well, sounds like you need to have a project to do this effort unto itself.

The UI is Independent of Domain

In general and virtually “always,” while the “UX Big Design” project is underway, the rest of the team can carry on with much of the other part of the system development. The UI — regardless of the complexity or simplicity of the UX design — is rather independent of the server or domain side of the world. So, even tho my project may have a parallel cool UX design component going on with its own features/iterations, i have all of the features still visible in the iterations through what I termed the “Rough UI.”

Whether the feature is surfaced in an ugly, simple UI control world, or a slick Flex/RIA world matters little. The core “back-end” API still needs to function. As the fancy UI components get finalized, they can be connected to the real API one by one.

Soon the ugly duckling UI turns into a beautiful swan.