For the last year, the industry been hearing a lot about designer developer workflow. Both Adobe and Microsoft are developing tooling that enables designers and developers to integrate more effectively, and iterate on software more rapidly. Let me ask a question that seems obvious: So What? Who does this “rapid iteration” serve?
Look at Adobe’s own diagram for RIA workflow:
Ironically, this diagram does not show true iteration – it only accounts for “design tweaks”. Where’s the business requirements? Where’s the measurement of milestones? And… the most important question, where is the person that the software is intended for?
I’m not completely dense, I realize that Adobe’s diagram is not intended for for use as a project planning roadmap. They aremerelyshowing how CS4 fits into an RIA project – (folks at EffectiveUI often look at our public facing process documentation and complain that it is too simplistic or not entirely accurate – truth is, every project we do is unique in its own way so it is impossible to accurately & concisely diagram any realistic software process)
Where was I …. oh yeah – workflow…
It is easy to get stuck in the tooling and forget about the end result – to value process and the technologies over the final product. There is a shift happening in our industry – I would say we are trending in the right direction. New workflows are forcing designers and developers to collaborate – why is that good? Because it forces humility into the process. In the software creation world, “Big Egos with Big Ideas” rarely produce “Big Wins”.
A Healthy Conflict
Our projects are lead by 2 types of architects. One is technical, of course. But we do not categorize the other architect as a “designer”. Design is just a part of the overall objective. We’ve adopted the term “Experience Architect” – Both architects are held accountable to 2 goals – 1) end user satisfaction and 2) ensuring a business success. While the Technical Architect focuses development architecture and legacy integration, the Experience Architect focuses on the end user and the business and user goals as well as brand consistency and aesthetics.
I have yet to work on a project where no compromise is required. Designers will always need to make compromises because of technical or integration limitations – development will always need to make compromises because of what the end users really need. Where I’ve seen projects fail is when one department is given priority over the other. When design “owns” the initiative, you can wind up with software that looks amazing, but is ripe with performance issues. When development owns it, you can wind up with software that performs, but is not usable. When both teams are equally subservient to the user and business goals – they are forced to work together.
There are some surprising results from this type of structure … interestingly enough, developers have good ideas for usability, and designers can challenge development into new ways of thinking.
What about “me”
It is time to look beyond mere team collaboration; we need to involve the people who the software is intended for. We need to listen and have empathy for those we are creating for. I know – not an original concept… but we must keep saying it until it is heard. New workflow improvements only get us half way there and do not ensure highly usable software…