Just flow?

It was sometime during the year 2005, I think, I attended this seminar on "Workflow Management and the Effective Process Management". The person who was making the presentation was a famous management guru with loads of experience. Back then, I thought that all this was just some mumbo-jumbo and fit enough just to be in a book. In the next few years, I was in-charge of managing teams and establishing workflows. Not really aware of it, I was actually following a lot of what the man had talked about. I had to improvise a bit, but there is always something that comes with the strings attached.

In my life, I have led teams that consist of designers, developers and test engineers. Many of whom have bigger degrees and many years of experience. We've always had a mix of technologies and skill sets – newbies, seniors, idle-bugs etc. At first, I tried to be the "No process man". I failed miserably! With experience came the art of getting it all right.

In my job (and most others), designer <-> developer workflow is a very important thing. It is becoming more and more important to have an easy and effective workflow with the era of richness moving really fast and becoming the order of the day. Project turn-around times are becoming lesser too. If your workflow is not efficient, deliverables are delayed and lot of problems are caused. A proper flow can be established when all sets of people involved first understand their portions of the work to be done. In my experience, I have had various hurdles.

1. When the project is more "design based" with a minimum team of artists/designers, it becomes more difficult to establish a process and method. Designers want more time to ideate, visualize, layout and finalize. They don't want to have time constraints on any of these, especially, if their manager is a development guy! Mostly they prefer individual contribution and don't like working that much in a team..rightfully so, coz many have told me that ideas differ and final execution doesn't turn out as visualized if the entire designer's workflow is pushed through to other designers also.
   
2. If it s a totally developer oriented job, there occurs a lot of arguments in code models especially. Developers easily fit into workflows established.
   
3. The "mix" is getting into some soup! There is always the – "that design and this way" argument. There is also the more famous – "At the end we become the slave to the grind." It is often true that as the project gets well along the way, designers finish early and developers take a lot of stress and burden. This builds a bit of envy, which also affects smooth functioning.
   

While designing stunning and rich exteriors is the designers' job, making things rock in the interiors is the developers'. It is not just process and/or mentality that governs a good workflow, it is also the tools that have an equal say in matters. Collaboration, interoperability, familiar user-friendly GUI, a bit of backward compatibility..all these are important features. Both my favourite companies (Adobe and MS) have come a long way in this regard, making software more along these lines of efficiency. Would there be a day when the creative editor approves a design and does a File > Save as > Banner from a print document? The CS4 suite is really close to it, with interoperable formats and familiar environments, it allows us to remove some of the old barriers and be more efficient and quick. Whether it is transitioning from a prototype to a widget or creating a rich application from a layout created, the CS4 suite has all that we need and can use. PhotoShop, Flash, Fireworks, Flex..and now Catalyst all work together!

Using Adobe Flash Catalyst, designers can create the GUI (or the "user experience" as we now call it!). They can import PSD, AI or PNGs and create the GUIs with basic interactivity (transitions, style changes etc). The file is saved as FXG. The FXG opened by the developer in Flex Builder. He does a "code merge" and adds functionality. Changes in design are again "code merged".

Traditionally, most developers are used to creating a new document and adding the design elements manually into a new Flash document or a new MXML file. We often need something in a particular way, other than, what the designer has designed. Eventhough we don't "redesign" anything ourselves and leave that to the designer, it causes a clash sometimes and often the "I am a designer, you just code" T-shirt is worn! A good process must have all this laid in and made a pact. Design is made according to a plan, with some design standards and best practices. It should make people work easier with each other. The same goes for developers too. Standards, patterns and best practices is the name of the game.

"Build once, deploy on whatever" is almost a reality. There used to be a clear classification when I started as a programmer – "Desktop Application Developer" and "Web Developer". The Flash Platform and platforms like dotnet really bridge a lot of the gaps. It is going to be a really awesome future! Bring it on!