Evolution of Visual Design - A Workflow

In this blog I detail visual design workflow deltas from Waterfall to Landslide to Agile and then to Lean.

Let's start with the Waterfall process

A seemingly simple process? If you’ve designed in a waterfall workflow, you know that it actually looks more like this:

• Designers and business communicate via documents - a very slow way to work.
• Designers spends hours building their visual language in a Photoshop document (PSD).
• A series of stakeholders spend lots of time on email to create a thick-document of feedback on the designs.
• Repeat (for weeks/months) until the stakeholders are happy with a picture of their website-to-be.
• Business finally delivers documents and requirements to development.

As designers never speak to developers prior to User Acceptance Testing (UAT), they have one shot at communicating via documents. This means time lost writing, refining and digesting books of documentation. Post that, as developers moves PSDs into visual assets, more translation time-consumers emerge - typefaces not suitable for web, non-normal blending in gradients, specific image treatments, inconsistent colors due to color-pickers. As do “short-cuts”, like image-sprites cut from PSDs to save developers the hassle of fully translating PSD into a Cascaded Style Sheet (CSS), which leads to technical debt and future problems (think retina screens.. and beyond retina).

Progression of “landslide” (fake-agile)

This is better than waterfall, but it still lacks pairing of the designer and developer. It is common for teams to practice landslide without even knowing it. At least they are trying.

Agile 101: Finally pairing!

• The designer creates the PSD. The key being that the PSD is piecemeal, not a comp.
• Brings the PSD to pair with the developer.
• Developer and designer pair on translating the PSD.
• Future proofing is discussed.
• Knowledge share / culture share can finally happen. Developers learn more about design principals used and designers learn more about how to execute their designs in the final medium.

Lean (version 1): This is fast

• Live changes to production code are the first and final medium.
• The designer and developer work in the final medium.
• The designer can tweak and polish on a consistent basis as their efforts are the final product.
• Icons, illustrations, and graphics are made as needed.
• Surprises are non-existent. You see how it looks in the browser now.
• Translation issues like non-normal blending methods for colors are non-existent. 
• Feedback rounds result in modified stylesheets. No need for more documentation. Time and money is saved.

Lean (version 2): This is faster.

• Both are skilled as designers and developers.
• One of the pair may have stronger developer skills, the other may have stronger visual skills.
• Why two of them? Always pair. Never design in a silo.
• The team executes their ideas directly in code.
• No wasted time/money/documentation.