Today’s workflows

Last week CSS guru Dave Shea started a workflow discussion by describing how he starts visually in Photoshop, only moving to code as the visuals are approved, and has discrete “handoff” stages where he passes generations of finished visual assets to interaction designers. I thought the comments were notable for the diversity of workflows that others described.

This week Jason Fried at 37 Signals described their approach, which goes from paper sketch directly to HTML/CSS, and comment here again show the diversity of workgroups and workflows. Jeff Croft had a good followup essay showing how the workflow is dependent on the workgroup and the types of tasks each group is attempting: “So who’s right? The answer is simple: we both are.”

One angle that Jeff touched on is how the project’s approval process dictates so much of the workflow… a single-person project doesn’t need to gain consensus on ideas the way that a single-company team would, and the situation is even more complex for a multi-company project, such as an agency achieving approval on an implementation from multiple individuals and teams within a client company. Projects have vastly different needs to explain themselves before completion.

People creating content come from different backgrounds, have different mental models, prefer different ways to bring an idea into reality. Then each different team creating content has different needs, different flows of passing work among the group, building pieces up into a structure. And then atop that, different projects have different constituencies that they must satisfy during development. Individual creation, team coordination, stakeholder approval… layers of variables piling up atop each other.

Back in the early part of the decade Macromedia introduced “the designer/developer workflow”, DevNet and the rest, to unite the different disciplines of serverside applications (ColdFusion) and clientside applications (Flash Player). That was a necessary step, but not a sufficient one, as the three conversations above show. Few workgroups have just a designer component and just a developer component. The process is iterative, and usually involve many more stakeholders than one individual creating interaction logic and a second creating business logic.

I was impressed by the range of workflows, skillsets, and approval needs people added in comments to the essays from Dave and Jason. Adobe has been working in this area for awhile, but it’s a very difficult problem to solve… or, rather, set of problems to solve. We can’t just satisfy a single workflow, but must work to support the range of different ways that groups work together today, all while remaining accessible (in learning curve, cost, and flexibility) as well as open (so your data remains portable, and other components can be plugged into the workflow).

Hard task, but that’s what we’re trying to accomplish here….