• Treat the specifications and user experience design documents as breathing documents.
• Regularly the development and user experience design teams should exchange feedbacks, and incorporate collective notes.
• User experience designers should stick to constraints defined by product developers, should consider the viability of their design in the context of implementation and marketability, and should consult with product developers on viability of features.
• Product developers should not seek to define how each feature should work, but should rather define the broader project goals and product requirements.
• Both user experience designers and product developers should be involved in identifying opportunities, competitive analysis, market and user research, feature design, design refinement, implementation.
• Both teams should utilize an iterative and dynamic product design process instead of rigid, linear approach.

Moreover, I believe that the optimal product design and development process necessitates both product development and user experience design methodologies. I call this approach “product experience development” to emphasize the equal rolls of both fields in the overarching process. Product design and development focused on only one of the fields is incomplete and ineffectual.

A lot has changed since Rich Internet Application platforms came into existence (post 2003), design documentation has become more complex and evolved into a more mature form of art. Yes, I said “Art”, because in its current form, UI Designers, Experience Designers or Information Architects, use their own creativity to prepare a set of design documents. Hardly there is any standard format which is widely used by all UI Designers. And this makes obvious, on how can an effective design documentation be prepared. Well there are set of definitions for a Design Documentation, otherwise knows as Deliverables, and each design firm has their own process to create and communicate these deliverables. After all at the end these deliverables are meant to communicate one’s vision to other team members.

Effectively communicating the idea of how the application design looks and feels, makes the documentation a valuable asset in the delivery mechanism. Also at times, it makes new team members integrate well with the team, as it helps them understand the application better, and make decisions in coming time more soundly. Design documentation is meant to be designed by and for the people who are :

1. Planners (make deliverables)
2. Converters (use deliverables)
3. Decision Makers (approve deliverables)

So if you are heading on a new assignment or managing one already, just run up a sanity check on your design documentation, it always pays off.