# The Gulf Between Design and Engineering ![rw-book-cover](https://designsystems.international/static/5ffba0cf29e4840e53c459a9dd14b2b9/16c18/social-banner.jpg) URL:: https://designsystems.international/ideas/the-gulf-between-design-and-engineering/ Author:: Rune Madsen ## Highlights > I believe the way most organizations produce digital products is fundamentally broken. The elephant in the room is a dated understanding of the role of both design and engineering, which in turn shapes how organizations hire, manage, and produce digital things. ([View Highlight](https://read.readwise.io/read/01hmrqjwqjcr7056dgtad7pwep)) > It’s safe to say that there is a natural tension between the fields of design and engineering. Traditionally, the role of design is to question, create meaning, and to argue for solutions that make for a better user experience. The role of engineering is to systematize, solve technical problems, and to argue for solutions that make for a simple, scalable, and future-proof implementation. The design process begins before we know what we want, and engineering usually happens when there is a clear notion of what is being built. ([View Highlight](https://read.readwise.io/read/01hmrqkg5xtytmdf33gt81hqpp)) > Engineers work in another closed ecosystem of programming tools that feel as foreign to designers as a drawing program does to an engineer. ([View Highlight](https://read.readwise.io/read/01hmrqm77cvrewgz6pckqq9vv5)) > The most crucial mistake in the collaboration between designers and engineers happens when we conflate this division of tools with a need for a strong division of labor. ([View Highlight](https://read.readwise.io/read/01hmrqmdfd8cbby0gs7zmjv1tw)) > Treating design and engineering as two completely separate processes leads to an isolated waterfall workflow where designers first get to dream up ideas in static tools, and engineers then implement the desired features when they are ready for development. ([View Highlight](https://read.readwise.io/read/01hmrqn23hxg57000qkb3g2v01)) > We have compiled these findings into a small list of principles that we apply on almost every project: > 1. Flatten your waterfalls > 2. Make code the design product > 3. Operate like an open source project > 4. Increase visibility through automation > 5. Plan like a farmer ([View Highlight](https://read.readwise.io/read/01hmrqnttsbn4d22fb4cae5ekn)) ## New highlights added January 22, 2024 at 4:34 PM > 1. Flatten your waterfalls > A key allegory we use to describe our desired workflow is that of moving from a waterfall to a river. A waterfall process is defined by going through a series of discrete and sequential phases, flowing like steps in a waterfall, where each stage has a deliverable that is handed off to the team responsible for the next phase. We replace this rigid structure with the idea of a river, which is a continuous flow moving in a clear direction, where obstacles along the way will affect the flow temporarily, making it move backwards or in circles, until it finds its way forward to continue in the desired direction. > The real-life consequence of this shift is that designers and engineers work together from the very beginning to the very end of a project. ([View Highlight](https://read.readwise.io/read/01hmrt5amk6dn1daf88xgg3npz)) ### 2. Make code the design product > Thinking of the digital product as the real design product is an organizational statement that code is the material we’re building from, and that modern applications are way too complex to simulate in static, page-based design tools. ([View Highlight](https://read.readwise.io/read/01hmrt6pamxdwtv3xf70m9a2rp)) ### 3. Operate like an open source project > This has little to do with whether the code itself is open source or not. What is more important is how accessible these design systems are in terms of adapting to changes needed from the organization. Really great design systems have a core group of stakeholders who oversee the direction of the project, but mostly spend their time prioritizing work, helping adoption, and facilitating contributions from across the organization – including from collaborators in the design systems team. ([View Highlight](https://read.readwise.io/read/01hmrt9469d39nf3nea9stb9kk)) ### 4. Increase visibility through automation > Developers are fairly used to automating their workflows, so the bigger task is often to figure out how to apply these same principles to the design workflow, so everyone has access to the latest design work and can easily get the assets they need. But what does it even mean to automate parts of the design process? We first focus on every place where design elements are consumed by code, and we make processes to automate the creation of these elements. This can be as simple as a good naming convention in Figma with the proper export settings for a set of icons, or a more complicated setup with custom Figma plugins or web-based design tools to export SVG, PNG or MP4 assets. We believe so much in this concept that we have developed an [open source framework for automating design operations](https://mechanic.design/), and we use this to free up time for design teams and make their decision and progress transparent to everyone else. ([View Highlight](https://read.readwise.io/read/01hmrtabvcqm00ka88azt8htex)) ### 5. Plan like a farmer > In the book [Reinventing Organizations](https://www.reinventingorganizations.com/), which I highly recommend for anyone interested in these ideas around collaboration, Frederic LaLoux introduces the idea that organizations should think like farmers. It makes no sense for a farmer to plan the harvest date at the beginning of the season, so they often end up having a years-long perspective but planning only for the next day. Organizations can learn from this by letting go of this obsession over fixed delivery dates and instead build a capacity to sense and respond, which will steer them towards much healthier outcomes. ([View Highlight](https://read.readwise.io/read/01hmrtb899zsma69v97j7azhat)) --- Title: The Gulf Between Design and Engineering Author: Rune Madsen Tags: readwise, articles date: 2024-01-30 --- # The Gulf Between Design and Engineering ![rw-book-cover](https://designsystems.international/static/5ffba0cf29e4840e53c459a9dd14b2b9/16c18/social-banner.jpg) URL:: https://designsystems.international/ideas/the-gulf-between-design-and-engineering/ Author:: Rune Madsen ## AI-Generated Summary The article discusses how the traditional waterfall model of software development negatively impacts the collaboration between design and engineering teams, leading to isolated workflows, slower productivity, and bad digital products. The author suggests a new set of principles for better workflows that focus on treating design and engineering as complementary processes, making code the design product, operating like an open source project, and automating manual tasks to free up time. The article also emphasizes the importance of facilitating cross-pollination between design and engineering throughout the entire digital product lifecycle and planning like a farmer for effective agile processes. ## Highlights > I believe the way most organizations produce digital products is fundamentally broken. The elephant in the room is a dated understanding of the role of both design and engineering, which in turn shapes how organizations hire, manage, and produce digital things. ([View Highlight](https://read.readwise.io/read/01hmrqjwqjcr7056dgtad7pwep)) > It’s safe to say that there is a natural tension between the fields of design and engineering. Traditionally, the role of design is to question, create meaning, and to argue for solutions that make for a better user experience. The role of engineering is to systematize, solve technical problems, and to argue for solutions that make for a simple, scalable, and future-proof implementation. The design process begins before we know what we want, and engineering usually happens when there is a clear notion of what is being built. ([View Highlight](https://read.readwise.io/read/01hmrqkg5xtytmdf33gt81hqpp)) > Engineers work in another closed ecosystem of programming tools that feel as foreign to designers as a drawing program does to an engineer. ([View Highlight](https://read.readwise.io/read/01hmrqm77cvrewgz6pckqq9vv5)) > The most crucial mistake in the collaboration between designers and engineers happens when we conflate this division of tools with a need for a strong division of labor. ([View Highlight](https://read.readwise.io/read/01hmrqmdfd8cbby0gs7zmjv1tw)) > Treating design and engineering as two completely separate processes leads to an isolated waterfall workflow where designers first get to dream up ideas in static tools, and engineers then implement the desired features when they are ready for development. ([View Highlight](https://read.readwise.io/read/01hmrqn23hxg57000qkb3g2v01)) > We have compiled these findings into a small list of principles that we apply on almost every project: > 1. Flatten your waterfalls > 2. Make code the design product > 3. Operate like an open source project > 4. Increase visibility through automation > 5. Plan like a farmer ([View Highlight](https://read.readwise.io/read/01hmrqnttsbn4d22fb4cae5ekn)) > 1. Flatten your waterfalls > A key allegory we use to describe our desired workflow is that of moving from a waterfall to a river. A waterfall process is defined by going through a series of discrete and sequential phases, flowing like steps in a waterfall, where each stage has a deliverable that is handed off to the team responsible for the next phase. We replace this rigid structure with the idea of a river, which is a continuous flow moving in a clear direction, where obstacles along the way will affect the flow temporarily, making it move backwards or in circles, until it finds its way forward to continue in the desired direction. > The real-life consequence of this shift is that designers and engineers work together from the very beginning to the very end of a project. ([View Highlight](https://read.readwise.io/read/01hmrt5amk6dn1daf88xgg3npz)) ### 2. Make code the design product > Thinking of the digital product as the real design product is an organizational statement that code is the material we’re building from, and that modern applications are way too complex to simulate in static, page-based design tools. ([View Highlight](https://read.readwise.io/read/01hmrt6pamxdwtv3xf70m9a2rp)) ### 3. Operate like an open source project > This has little to do with whether the code itself is open source or not. What is more important is how accessible these design systems are in terms of adapting to changes needed from the organization. Really great design systems have a core group of stakeholders who oversee the direction of the project, but mostly spend their time prioritizing work, helping adoption, and facilitating contributions from across the organization – including from collaborators in the design systems team. ([View Highlight](https://read.readwise.io/read/01hmrt9469d39nf3nea9stb9kk)) ### 4. Increase visibility through automation > Developers are fairly used to automating their workflows, so the bigger task is often to figure out how to apply these same principles to the design workflow, so everyone has access to the latest design work and can easily get the assets they need. But what does it even mean to automate parts of the design process? We first focus on every place where design elements are consumed by code, and we make processes to automate the creation of these elements. This can be as simple as a good naming convention in Figma with the proper export settings for a set of icons, or a more complicated setup with custom Figma plugins or web-based design tools to export SVG, PNG or MP4 assets. We believe so much in this concept that we have developed an [open source framework for automating design operations](https://mechanic.design/), and we use this to free up time for design teams and make their decision and progress transparent to everyone else. ([View Highlight](https://read.readwise.io/read/01hmrtabvcqm00ka88azt8htex)) ### 5. Plan like a farmer > In the book [Reinventing Organizations](https://www.reinventingorganizations.com/), which I highly recommend for anyone interested in these ideas around collaboration, Frederic LaLoux introduces the idea that organizations should think like farmers. It makes no sense for a farmer to plan the harvest date at the beginning of the season, so they often end up having a years-long perspective but planning only for the next day. Organizations can learn from this by letting go of this obsession over fixed delivery dates and instead build a capacity to sense and respond, which will steer them towards much healthier outcomes. ([View Highlight](https://read.readwise.io/read/01hmrtb899zsma69v97j7azhat))