The design and development of apps has in many ways become easier over the years. Today there are tools and development kits that make it possible to fairly easy put an app together that actually works. The app can also easily be released on a market (if accepted by the 'platforms') . An app does not have to be manufactured, packaged and shipped.
At the same time, it seems as if many of today's most influential interactive products are actual products, that is, they are made of materials, have a shape and form and have to be manufactured. It is of course possible to see software design and product design as similar in the same way as we can see similarities between many design fields. But the similarity is usually on a more abstract level than seems to be usually understood. Software design is, even though to some extent similar, it is radically different from product design.
In a great article about Silicon Valley industrial designers, Bill Webb (at Huge Design), is interviewed and gives his very insightful view of how and why product design is not understood and valued among those who live in the world of software 'products' and one of the reasons he mentions is the difference in working with material products versus software products.
One of the most distinct differences is that software is possible to change, add to, and remove from over time without having to bring it back to a factory. New updates can be released while it is being used. This is the basic idea behind a lot of modern design and development approaches within interaction design, create a barely functioning version, send it out to users and keep working on it.
When it comes to 'real' products, this is of course not possible. When you are dealing with manufacturing, products have to be defined in detail and when manufacturing has started no changes can be made without exceptional effort and cost. Product design, in any form, is a process of irreversibility. It is not possible to go back, to iterate, in the way as with software products. In the article with Bill Webb, he nicely explains this simple point and what consequences it has.
One of the consequences, and the one I see as detrimental to the larger field of designing, of this difference between software and product design is the inability to understand each others design process. This inability leads to serious management and leadership issues that have become harmful to many startups.
To me, a bigger problem lurking behind this more practical level is that the inability to understand that there is always a 'material' reality in each design area that in a distinct and crucial way not only influences the design process but in some ways determines it. When design thinkers and practitioner talk about designing as a generic process and advocate their own design approach, there is almost never any disclaimers about what kind of designing they are addressing or to what extent their approach is relevant for other areas. In many cases the proposed approach is based on or shaped by the 'material' foundation in the specific area and will not easily be transfered to other design areas.
This becomes a major problem for the whole field of 'design thinking' since it leads to many less insightful recommendations about designing that may be tried by others and found not only useless but not at all suitable for their particular design process. In the next step this can (or have already) lead to a backlash to a, otherwise growing understanding of designing.
At the same time, it seems as if many of today's most influential interactive products are actual products, that is, they are made of materials, have a shape and form and have to be manufactured. It is of course possible to see software design and product design as similar in the same way as we can see similarities between many design fields. But the similarity is usually on a more abstract level than seems to be usually understood. Software design is, even though to some extent similar, it is radically different from product design.
In a great article about Silicon Valley industrial designers, Bill Webb (at Huge Design), is interviewed and gives his very insightful view of how and why product design is not understood and valued among those who live in the world of software 'products' and one of the reasons he mentions is the difference in working with material products versus software products.
One of the most distinct differences is that software is possible to change, add to, and remove from over time without having to bring it back to a factory. New updates can be released while it is being used. This is the basic idea behind a lot of modern design and development approaches within interaction design, create a barely functioning version, send it out to users and keep working on it.
When it comes to 'real' products, this is of course not possible. When you are dealing with manufacturing, products have to be defined in detail and when manufacturing has started no changes can be made without exceptional effort and cost. Product design, in any form, is a process of irreversibility. It is not possible to go back, to iterate, in the way as with software products. In the article with Bill Webb, he nicely explains this simple point and what consequences it has.
One of the consequences, and the one I see as detrimental to the larger field of designing, of this difference between software and product design is the inability to understand each others design process. This inability leads to serious management and leadership issues that have become harmful to many startups.
To me, a bigger problem lurking behind this more practical level is that the inability to understand that there is always a 'material' reality in each design area that in a distinct and crucial way not only influences the design process but in some ways determines it. When design thinkers and practitioner talk about designing as a generic process and advocate their own design approach, there is almost never any disclaimers about what kind of designing they are addressing or to what extent their approach is relevant for other areas. In many cases the proposed approach is based on or shaped by the 'material' foundation in the specific area and will not easily be transfered to other design areas.
This becomes a major problem for the whole field of 'design thinking' since it leads to many less insightful recommendations about designing that may be tried by others and found not only useless but not at all suitable for their particular design process. In the next step this can (or have already) lead to a backlash to a, otherwise growing understanding of designing.
Comments