The war of Design and Development

Ever since digital design and development were born as professional careers, they have been at war.

In the early days of digital, the process between design and development (or void of process, as some might argue) was inefficient, difficult and, sometimes, just downright painful. Often designers would produce designs without input and review of their technical peers. Whilst Engineers would push back on designs early and reactively, relying on their known (often already out-of-date) skill set instead of exploring innovations or new techniques to deliver the proposed design. Time has improved this somewhat, but still is to this day, in some teams, this is a regularly played game of professional ping-pong.

The practice of user experience and agile processes have, to some extent, helped mitigate this issue. The former introduces a format for early design communication which allows for a degree of technical consideration, upfront. The latter brings design and development processes into parallel action, increasing the propensity for communication and sharing. However, neither fully resolves the common process issues found between the two disciplines. 

Technology has also tried to be our saviour. There's a long-standing history of development IDEs integrating visual tools (Dreamweaver et al), and, more recently, design tools trying to be more technical (think Macaw). The digital industry, being an innovation, workflow-driven world, has happily adopted and tried both approaches. But as most of these applications are aimed at removing the dependency on the opposing side of the equation, rather than improving the process (e.g. designers using these tools want to rely less on engineers, and so forth), both have ultimately failed. We still often rely on the classic someone-designs-then-someone-builds approach. In reality, most designers don't want to learn code (or bother to understand fully), and engineers don't want to take time away from focusing on code and development. They prefer to keep their skills to a singular domain. Fair enough.

Our approach

At Owl & Giraffe, one of our core beliefs is to be lean. To streamline processes and operations until the most efficient and effective approach is achieved for the project or process. The design and development process is one of the key areas we work on to reduce process overhead. The resulting approach below is something we change, constantly, but the foundation is about right.

1

Adopt a project process that enables open, regular communication between teams. We use agile as our base and then modify to fit the needs of the project. Drive regular communication between disciplines and teams. 

2

Use project tools that promote communication, visual sharing and, most importantly, work well on mobile. We use a combination of Trello, Slack and Google Documents which we find work well for most projects.

3

Design using tools that complement the needs of modern multi-device development. We use Sketch, rather than Photoshop. Working vectors, with an assortment of plugins and quick sharing tools reduces the overhead to design communication.

4

 

Prototype at the same time. Creating a prototype as you go allows you to test the rigor of your design and ensure you have the necessary interactive behaviours and states. Not only that, but you have something tangible and easily communicable to share with your peers, clients and users. Tools like Sketch, InVision and Marvel do a fantastic job at doing most of this work for you.

5

Use tools like Zeplin that introduce a presentation and communication tailored for the process between designers and developers. Zeplin renders all the spacing, layout and typographical details needed for a developer. It even provides platform specific code snippets. Layered with a note-and-comment system (similar to that in InVision) makes for an excellent tool to help communicate and iron-out design issues in teams - particularly for remote teams.

Granted this is no golden solution, but it's an approach that we've found works well in agile and waterfall projects. Every new project and tool offers a chance to change it up, but the more we can reduce unfocused, avoidable friction between processes in a project, the more time we have making a greater experience for our users. 

Photograph by Martin Kníže — https://unsplash.com/photos/1iHpSdiZyFA