The very concept of “waterfall” is unknown in the design community (industrial design, graphic design, architecture). The term originates from the business analysis/software engineering community. If you look at the core processes of industrial design and architecture there is a lot of iteration, collaboration, and reflection involved. They just don’t happen to be Agile software processes. I’m not for waterfall. I am for design first. Meaning LEAD with design. Create a lifecycle that puts design first.
Why in this age, are we even considering using any processes that are led from the engineering perspective to be used to permeate through the total lifecycle of a product.
I don’t mean to be dogmatic or even exclusionary. I just mean to put out what product companies have figured out that software companies are still raging far behind. Nokia and Apple get this pretty well. Their emphasis on a design led approach has had clear success and organizations from P&G to GE have also taken on these innovation & design methods to heart.
The very framework of Agile is a software engineering development framework. It’s core purpose is not efficiency but to create better code (from the early readings). Applying it beyond its original intent is like saying we use a taxi cab as a long-haul truck.
Yes, there are lessons to be learned, but asking design to move toward agile software methodologies has a feel of myopia to me.
So to summarize:
1. being anti-Agile for design processes is not being anti-Agile.
2. being anti-Agile is not being pro-waterfall
3. Agile methods are software methods
4. Design methods have their own toolkit for finding efficiencies
5. Design first is not only good, but in these times of shit software (much of which today IS being done in agile environments) is a necessity. And please don’t say that waterfall is the same as design first b/c it is not. WF is a business analysis/system analysis tool. Most software organizations doing software have never done design. They wrongly believe that design is about aesthetics.
6. The suggestion that design move towards Agile as this article does, while noble, puts engineering in front of design, in a time when design-led organizations are killing engineering-led organizations in the marketplace.
Nice overview! Thanks for promoting the discussion. For more ruminations on Agile Design, you might want to check out this presentation that Leslie Chicoine and I did at Web 2.0 Expo last year.
“Are Agile Projects Doomed To Half-Baked Design”:http://www.slideshare.net/theinfonaut/are-agile-projects-doomed-to-halfbaked-design ?
(We titled it as a question to be provocative; clearly we believe the answer is “No” :-))
One of our main insights is the need for what we call an “open design,” one where flexibility is built in from the beginning, thus making use of a professional designer’s sense of perfectionism and directing it towards an Agile purpose. Since an Agile project must be ready to launch at any time, the underlying design (graphic, information, navigation) must be able to work well with only a subset of the eventual feature set, and also must be able to plug in as-yet-unimagined features in a clean way.
The slideshare link above has the slides, but I’ve also got an MP3 recording of the event, so maybe if there’s interest I’ll figure out how to do audio synchronization…
Copy & paste the code below to embed this comment.
William Ulrich
A lot of usability and design people seem to be freaking about agile methods.
From Nielsen:
http://www.useit.com/alertbox/agile-methods.html
It is as if Agile methods disempower work teams which is not the case. Who said that Agile is an engineering method at all? It is merely a way to empower work teams so that no one leads. Emphasis is put on self organization. So what comes first in a product lifecycle?
To use the architecture metaphor it is always design. But it is balanced with consultation from engineering design.
The two carry a converse relationship as the velocity of the project increases. !important I used the word “balanced”. If you are doing Agile correctly you are creating a balance between engineering design and architecture that respects the input of people allowing everyone to lead when it is appropriate to do so. After all architects don’t build buildings.
Some work environments already achieve this naturally they are smaller organizations. Larger places like Intuit use Scrum because they have 1200 people working on product lifecycle. BTW Dave GE has certified Scrum masters.
“It’s core purpose is not efficiency but to create better code”
It’s core purpose is to empower architects and engineers. You can apply Agile to the design development and usability of a product. If designers are supposed to be so liberal why is it that many design ideology when they should be designing product?
BTW Dave “shit software” being created by Agile methods? No “shit software” is being created by people that understand in the first place. This is not a he man contest.
But after all of this is said this is still not the issue. All these convention speaking types are trying to monetize what Agile is or is not. They are exploiting the pros and cons and pimping it out for all that it is worth. Me I just sit back smile and make it work for me.
To use the architecture metaphor it is always design. But it is balanced with consultation from engineering design. The two carry a converse relationship as the velocity of the project increases.
Drawing parallels back to the web, wouldn’t the person doing the design also have a good understanding of the ‘engineering’ (HTML, CSS, JS and back-end) seeing what’s possible and what would result in troubles?
Even so, I still don’t see how an agile method would benefit the design work in a project.
Copy & paste the code below to embed this comment.
William Ulrich
@ Tor Designers are not the know all to a project.
I see a pattern among designers that I like to call the Oracle personality. No one is an Oracle.
No one part of a lifecycle should play god.
Perhaps this reference to you and others might help. XP or extreme programming is one way of inducing Agile to a project.
@William — What I mean is web designers, experienced web designers, have knowledge in the fields you’re drawing parallels too in architecture (HTML, CSS, JS and some back end). By no means should the designer run the whole project or play god, I’m not implying that at all.
Copy & paste the code below to embed this comment.
Stephen Martin
In my experience, designers with front-end skills usually welcome Agile design. If you stop believing your design time exists only in Photoshop, you can really make a difference with this type of fast evolving design. Whether I’m using layers in Photoshop or manipulating Rails view files, I’m still a designer with a hand in usability and user experience.
I’m glad you like your agile process.
But please don’t assume too much about me. I don’t care about what people say Agile is, I care about how it works in reality and having been on MANY agile projects in many different environments, I have found them all to be failures. Maybe my 8 or so different attempts with it are all failures for other reasons than the agile process itself, but ya know 1x your learn 2x’s your a fool, 3x’s … well. ;-)
What is interesting is that you list a host of companies and maybe Intuit is the only one remarkable in their success around customer experience in terms of software. All the rest are well huge question marks. And for every organization that you can name doing successfully with agile I can name 10 doing successfully without it. So what’s the point. It just sounds like religion to me. I’m glad you found your god.
What really gets me about this conversation as I have been trying to dissect it and really understand the issues is not that agile is bad, or incompatible with design, or anything absolute like that, but rather that people try to assume that their success and ways of working are easily generalizable to infinite contexts. This is my issue with these movements (agile or even waterfall approaches like six sigma).
I have had better success trying to extrapolate from the idealized version and parsing it into the specific contexts where I have to live. But in the conversations we get very dogmatic and overly protective and downright silly.
Personally, I think there is still and will continue to be a strong need for upfront delivery in my world. I deal in hardware and you only get one shot at tooling. Software might do well to think about lessons from the hardware world about getting it right once. It does work in many scenarios and has for a lot longer than software ever existed.
Copy & paste the code below to embed this comment.
Johanna Kollmann
I’d like to add to the interesting discussion Dave started about agile and design:
For me, design innovation can happen for:
a) the big ideas (e.g. products, services)
b) the small details (e.g. interaction design solutions)
I agree with Dave that agile doesn’t allow enough room for coming up with big ideas. For most projects, Iteration Zero is not sufficient to develop a person-centric design vision. Especially when it comes to business strategy and design decisions, understanding the people you design for is important. I see methods that aim to establish this understanding happening prior to agile development. Agile is like running fast. While you don’t need to know what the goal you are running towards will be like, you should know the direction, where the goal is. Otherwise you end up running in circles.
I do think that Agile can support innovation, though. Design naturally is iterative and collaborative. Quick iterations, working as a team as well as the continuous sharing and testing of ideas means that, on the small detail level, I produce more designs. The more ideas the better the outcome will be. Less perfectionism support this: I spend less time on each idea and am more willing to throw stuff away. Agile makes people more open to light-weight tools like sketches, so supports my way of concept design better than waterfall, demanding specifications.
I agree with Cennydd that getting involved in Agile allows UX designers to shape their role and increase an understanding for design and its techniques. This, for me, is the main benefit of agile: by working together, with flexible mindsets and less dogma, we can understand and respect each others’ disciplines. Which could lead to a more people-centred approach.
(I admit being a bit of a romantic idealist here)
Personally, I think there is still and will continue to be a strong need for upfront delivery in my world. I deal in hardware and you only get one shot at tooling. Software might do well to think about lessons from the hardware world about getting it right once. It does work in many scenarios and has for a lot longer than software ever existed.
Isn’t that the whole point? Learning from other? I don’t think design can just take “Agile” and use it. But I am sure there things it can learn from it. Just like Software Development took the concept of Design Patterns from architecture.
On the other hand you also have to acknowledge differences between disciplines. Hardware and software are two very different environments. If you look at the technological standard of the satellites being launched today, you will see they are 10 years out of date. These things take years to build and perfect and you can’t keep on iterating and improving. You have to draw the line to get the thing launched. And once it’s launched, that’s it. You can’t make a quick hack to cover some missed aspect.
The same is not true for software. SW is infinitely more malleable. The truth is you can always modify SW and doing so costs little as it doesn’t mean re-building a $100m satellite or production chain. It simply means re-compiling.
Then you have to look at the clients. Clients commissioning satellites normally know very well what they want. Clients commissioning web sites usually have no idea. Hence Agile is far more useful to producers of websites than of satellites.
Then you need to take changing demands into account. Scientific satellites are going to be measuring something. The client isn’t going to turn round and say I want to measure X instead of Y. The requirements are relatively stable. Whereas if you look most SW, requirements are changing all the time. Often due to legal policy changes. Agile is an attempt to deal with this.
It is worth accepting that there are different ways of achieving a quality product. eg: TDD is often put forward as a way to minimise bugs in SW. TDD advocates to write your tests first. Others often write them afterwards. In fact it doesn’t matter when you write your tests. What matters is that they are written. TDD is one way of ensuring the tests are written. But there are other ways of ensuring this.
Finally, none of this should be taken as black and white. There are always exceptions. It is a shade of grey.
I think the “vision” question is the most compelling in the design v. agile discussion. However to use film making as an analogy doesn’t solve this problem for me. A film has a screenplay, a script, or sometimes even an entire book written before filming. Of course it’s revised constantly, but there is a whole picture there to start with.
Entirely different to design and build one, or a few, scenarios at a time, with little sense of the big picture beyond broad outlines.
Is an iteration 0 with time to map out, say, 20 key scenarios in one place and their relationships to one another really too much to ask? Is there a better solution?
I enjoyed your views on this…thanks! In particular, I look forward to reviewing some of the presentations you list at the end, and checking out some of the HTML prototyping software you mentioned.
I was curious about what you meant that ‘the web page is no longer the atomic unit of the web.’ I would have said that information is still listed on a page (even if it is dynamically generated). It seems to me the web still revolves around putting information about a resource at a particular, static URI. Are you saying that’s not how users view the web anymore?
@AudreyCrane I think the analogy with film making revolves around that fact that movies aren’t filmed in sequential scene order, similar to the way apps aren’t always developed top-down. Yet in both cases, someone has to be the ‘consistency, overall vision champion’ to make sure everything hangs together in the end.
Copy & paste the code below to embed this comment.
Shaun Bouckaert
There is no design/development model that will work perfectly for every project. It’s dangerous to assume a particular development model will work every time.
Agile development is the most popular model at the moment because of architectures like Ruby on Rails and Django (for Python). Both of these architectures have been developed towards Agile methods, and for web projects this method (and these platforms) work well a lot of the time.
However, there are other methods, some based on Agile ideals, but still following more classic development patterns that will suit perhaps larger projects better, especially when comprehensive documentation is required along with the product. Not to mention, Agile development doesn’t work very well if the client isn’t available to be involved in the ongoing project. Otherwise, you end up with a project that can easily go off on tangents and never have a finished product.
Methodologies go in and out of fashion just like any other part of the industry. Unfortunately, from a business point of view, Web Development, and other IT in general, is all about buzzwords, even to the detriment of a project.
There are certainly many options out there, and they all have their criticisms, defenders and champions. WaddleWorks in its own right is doing its best at succeeding in the “jacksonville web design”:http://www.waddleworks.net/web-design/community/jacksonville-organizational-and-nonprofit-web-development/ market. Nonprofits and social organizations are not the only ones cutting corners in these economic times, however they are the most dependent on strategic software that agile may or may not ensure. It truly is a case by case trial and error process.
Being able to deliver the capabilities of chatting from your mobile phone and/or your PC with the use of in depth agile software is easier said than done. Then advanced agility concept may be the best solution for you… Though, it does come at a learning curve. It allows interaction from most browsers and from various platforms. On their web site, they have a list of over 250 networking tools to which you can easily set-up and connect your interfaces to and utilize some useful features such as an online graphical, “free chat rooms”:http://rooms.aim2chat.com, monitoring and alerts that tell you how much of what is being used.
37 Reader Comments
Back to the ArticleDave Malouf
The very concept of “waterfall” is unknown in the design community (industrial design, graphic design, architecture). The term originates from the business analysis/software engineering community. If you look at the core processes of industrial design and architecture there is a lot of iteration, collaboration, and reflection involved. They just don’t happen to be Agile software processes. I’m not for waterfall. I am for design first. Meaning LEAD with design. Create a lifecycle that puts design first.
Why in this age, are we even considering using any processes that are led from the engineering perspective to be used to permeate through the total lifecycle of a product.
I don’t mean to be dogmatic or even exclusionary. I just mean to put out what product companies have figured out that software companies are still raging far behind. Nokia and Apple get this pretty well. Their emphasis on a design led approach has had clear success and organizations from P&G to GE have also taken on these innovation & design methods to heart.
The very framework of Agile is a software engineering development framework. It’s core purpose is not efficiency but to create better code (from the early readings). Applying it beyond its original intent is like saying we use a taxi cab as a long-haul truck.
Yes, there are lessons to be learned, but asking design to move toward agile software methodologies has a feel of myopia to me.
So to summarize:
1. being anti-Agile for design processes is not being anti-Agile.
2. being anti-Agile is not being pro-waterfall
3. Agile methods are software methods
4. Design methods have their own toolkit for finding efficiencies
5. Design first is not only good, but in these times of shit software (much of which today IS being done in agile environments) is a necessity. And please don’t say that waterfall is the same as design first b/c it is not. WF is a business analysis/system analysis tool. Most software organizations doing software have never done design. They wrongly believe that design is about aesthetics.
6. The suggestion that design move towards Agile as this article does, while noble, puts engineering in front of design, in a time when design-led organizations are killing engineering-led organizations in the marketplace.
—dave
Alex Chaffee
Nice overview! Thanks for promoting the discussion. For more ruminations on Agile Design, you might want to check out this presentation that Leslie Chicoine and I did at Web 2.0 Expo last year.
“Are Agile Projects Doomed To Half-Baked Design”:http://www.slideshare.net/theinfonaut/are-agile-projects-doomed-to-halfbaked-design ?
(We titled it as a question to be provocative; clearly we believe the answer is “No” :-))
One of our main insights is the need for what we call an “open design,” one where flexibility is built in from the beginning, thus making use of a professional designer’s sense of perfectionism and directing it towards an Agile purpose. Since an Agile project must be ready to launch at any time, the underlying design (graphic, information, navigation) must be able to work well with only a subset of the eventual feature set, and also must be able to plug in as-yet-unimagined features in a clean way.
The slideshare link above has the slides, but I’ve also got an MP3 recording of the event, so maybe if there’s interest I’ll figure out how to do audio synchronization…
Sander Aarts
Are we talking about visual design, interaction design or both?
William Ulrich
A lot of usability and design people seem to be freaking about agile methods.
From Nielsen:
http://www.useit.com/alertbox/agile-methods.html
It is as if Agile methods disempower work teams which is not the case. Who said that Agile is an engineering method at all? It is merely a way to empower work teams so that no one leads. Emphasis is put on self organization. So what comes first in a product lifecycle?
To use the architecture metaphor it is always design. But it is balanced with consultation from engineering design.
The two carry a converse relationship as the velocity of the project increases. !important I used the word “balanced”. If you are doing Agile correctly you are creating a balance between engineering design and architecture that respects the input of people allowing everyone to lead when it is appropriate to do so. After all architects don’t build buildings.
Some work environments already achieve this naturally they are smaller organizations. Larger places like Intuit use Scrum because they have 1200 people working on product lifecycle. BTW Dave GE has certified Scrum masters.
“It’s core purpose is not efficiency but to create better code”
It’s core purpose is to empower architects and engineers. You can apply Agile to the design development and usability of a product. If designers are supposed to be so liberal why is it that many design ideology when they should be designing product?
BTW Dave “shit software” being created by Agile methods? No “shit software” is being created by people that understand in the first place. This is not a he man contest.
But after all of this is said this is still not the issue. All these convention speaking types are trying to monetize what Agile is or is not. They are exploiting the pros and cons and pimping it out for all that it is worth. Me I just sit back smile and make it work for me.
Isn’t that the moral after all? Making it work.
Tor Løvskogen Bollingmo
Drawing parallels back to the web, wouldn’t the person doing the design also have a good understanding of the ‘engineering’ (HTML, CSS, JS and back-end) seeing what’s possible and what would result in troubles?
Even so, I still don’t see how an agile method would benefit the design work in a project.
William Ulrich
@ Tor Designers are not the know all to a project.
I see a pattern among designers that I like to call the Oracle personality. No one is an Oracle.
No one part of a lifecycle should play god.
Perhaps this reference to you and others might help. XP or extreme programming is one way of inducing Agile to a project.
http://www.martinfowler.com/articles/designDead.html
Tor Løvskogen Bollingmo
@William — What I mean is web designers, experienced web designers, have knowledge in the fields you’re drawing parallels too in architecture (HTML, CSS, JS and some back end). By no means should the designer run the whole project or play god, I’m not implying that at all.
Stephen Martin
In my experience, designers with front-end skills usually welcome Agile design. If you stop believing your design time exists only in Photoshop, you can really make a difference with this type of fast evolving design. Whether I’m using layers in Photoshop or manipulating Rails view files, I’m still a designer with a hand in usability and user experience.
Dave Malouf
I’m glad you like your agile process.
But please don’t assume too much about me. I don’t care about what people say Agile is, I care about how it works in reality and having been on MANY agile projects in many different environments, I have found them all to be failures. Maybe my 8 or so different attempts with it are all failures for other reasons than the agile process itself, but ya know 1x your learn 2x’s your a fool, 3x’s … well. ;-)
What is interesting is that you list a host of companies and maybe Intuit is the only one remarkable in their success around customer experience in terms of software. All the rest are well huge question marks. And for every organization that you can name doing successfully with agile I can name 10 doing successfully without it. So what’s the point. It just sounds like religion to me. I’m glad you found your god.
What really gets me about this conversation as I have been trying to dissect it and really understand the issues is not that agile is bad, or incompatible with design, or anything absolute like that, but rather that people try to assume that their success and ways of working are easily generalizable to infinite contexts. This is my issue with these movements (agile or even waterfall approaches like six sigma).
I have had better success trying to extrapolate from the idealized version and parsing it into the specific contexts where I have to live. But in the conversations we get very dogmatic and overly protective and downright silly.
Personally, I think there is still and will continue to be a strong need for upfront delivery in my world. I deal in hardware and you only get one shot at tooling. Software might do well to think about lessons from the hardware world about getting it right once. It does work in many scenarios and has for a lot longer than software ever existed.
—dave
Johanna Kollmann
I’d like to add to the interesting discussion Dave started about agile and design:
For me, design innovation can happen for:
a) the big ideas (e.g. products, services)
b) the small details (e.g. interaction design solutions)
I agree with Dave that agile doesn’t allow enough room for coming up with big ideas. For most projects, Iteration Zero is not sufficient to develop a person-centric design vision. Especially when it comes to business strategy and design decisions, understanding the people you design for is important. I see methods that aim to establish this understanding happening prior to agile development. Agile is like running fast. While you don’t need to know what the goal you are running towards will be like, you should know the direction, where the goal is. Otherwise you end up running in circles.
I do think that Agile can support innovation, though. Design naturally is iterative and collaborative. Quick iterations, working as a team as well as the continuous sharing and testing of ideas means that, on the small detail level, I produce more designs. The more ideas the better the outcome will be. Less perfectionism support this: I spend less time on each idea and am more willing to throw stuff away. Agile makes people more open to light-weight tools like sketches, so supports my way of concept design better than waterfall, demanding specifications.
I agree with Cennydd that getting involved in Agile allows UX designers to shape their role and increase an understanding for design and its techniques. This, for me, is the main benefit of agile: by working together, with flexible mindsets and less dogma, we can understand and respect each others’ disciplines. Which could lead to a more people-centred approach.
(I admit being a bit of a romantic idealist here)
Robin Massart
Isn’t that the whole point? Learning from other? I don’t think design can just take “Agile” and use it. But I am sure there things it can learn from it. Just like Software Development took the concept of Design Patterns from architecture.
On the other hand you also have to acknowledge differences between disciplines. Hardware and software are two very different environments. If you look at the technological standard of the satellites being launched today, you will see they are 10 years out of date. These things take years to build and perfect and you can’t keep on iterating and improving. You have to draw the line to get the thing launched. And once it’s launched, that’s it. You can’t make a quick hack to cover some missed aspect.
The same is not true for software. SW is infinitely more malleable. The truth is you can always modify SW and doing so costs little as it doesn’t mean re-building a $100m satellite or production chain. It simply means re-compiling.
Then you have to look at the clients. Clients commissioning satellites normally know very well what they want. Clients commissioning web sites usually have no idea. Hence Agile is far more useful to producers of websites than of satellites.
Then you need to take changing demands into account. Scientific satellites are going to be measuring something. The client isn’t going to turn round and say I want to measure X instead of Y. The requirements are relatively stable. Whereas if you look most SW, requirements are changing all the time. Often due to legal policy changes. Agile is an attempt to deal with this.
It is worth accepting that there are different ways of achieving a quality product. eg: TDD is often put forward as a way to minimise bugs in SW. TDD advocates to write your tests first. Others often write them afterwards. In fact it doesn’t matter when you write your tests. What matters is that they are written. TDD is one way of ensuring the tests are written. But there are other ways of ensuring this.
Finally, none of this should be taken as black and white. There are always exceptions. It is a shade of grey.
Audrey Crane
I think the “vision” question is the most compelling in the design v. agile discussion. However to use film making as an analogy doesn’t solve this problem for me. A film has a screenplay, a script, or sometimes even an entire book written before filming. Of course it’s revised constantly, but there is a whole picture there to start with.
Entirely different to design and build one, or a few, scenarios at a time, with little sense of the big picture beyond broad outlines.
Is an iteration 0 with time to map out, say, 20 key scenarios in one place and their relationships to one another really too much to ask? Is there a better solution?
Fitzgerald Steele
I enjoyed your views on this…thanks! In particular, I look forward to reviewing some of the presentations you list at the end, and checking out some of the HTML prototyping software you mentioned.
I was curious about what you meant that ‘the web page is no longer the atomic unit of the web.’ I would have said that information is still listed on a page (even if it is dynamically generated). It seems to me the web still revolves around putting information about a resource at a particular, static URI. Are you saying that’s not how users view the web anymore?
@AudreyCrane I think the analogy with film making revolves around that fact that movies aren’t filmed in sequential scene order, similar to the way apps aren’t always developed top-down. Yet in both cases, someone has to be the ‘consistency, overall vision champion’ to make sure everything hangs together in the end.
Shaun Bouckaert
There is no design/development model that will work perfectly for every project. It’s dangerous to assume a particular development model will work every time.
Agile development is the most popular model at the moment because of architectures like Ruby on Rails and Django (for Python). Both of these architectures have been developed towards Agile methods, and for web projects this method (and these platforms) work well a lot of the time.
However, there are other methods, some based on Agile ideals, but still following more classic development patterns that will suit perhaps larger projects better, especially when comprehensive documentation is required along with the product. Not to mention, Agile development doesn’t work very well if the client isn’t available to be involved in the ongoing project. Otherwise, you end up with a project that can easily go off on tangents and never have a finished product.
Methodologies go in and out of fashion just like any other part of the industry. Unfortunately, from a business point of view, Web Development, and other IT in general, is all about buzzwords, even to the detriment of a project.
904studios
There are certainly many options out there, and they all have their criticisms, defenders and champions. WaddleWorks in its own right is doing its best at succeeding in the “jacksonville web design”:http://www.waddleworks.net/web-design/community/jacksonville-organizational-and-nonprofit-web-development/ market. Nonprofits and social organizations are not the only ones cutting corners in these economic times, however they are the most dependent on strategic software that agile may or may not ensure. It truly is a case by case trial and error process.
904studios
Being able to deliver the capabilities of chatting from your mobile phone and/or your PC with the use of in depth agile software is easier said than done. Then advanced agility concept may be the best solution for you… Though, it does come at a learning curve. It allows interaction from most browsers and from various platforms. On their web site, they have a list of over 250 networking tools to which you can easily set-up and connect your interfaces to and utilize some useful features such as an online graphical, “free chat rooms”:http://rooms.aim2chat.com, monitoring and alerts that tell you how much of what is being used.
ScatolaEmozioni
As in “(blog cinema)La scatola delle emozioni(blog cinema)”:http://www.lascatoladelleemozioni.it Designer should not be considered actors.