Ground for Ground -Reflection

The Product Service System (PSS) project was a major design challenge.  The project demanded a very thoughtful approach in order provide a useful product, a beneficial service and a realistic system.  In addition, it was critical that the PSS engaged the community, and encourage positive behaviour.

I have previously noted that, as my design process develops, I have become more aware of the need to ensure that the product/concept that I design has a utility that warrants it's development.  In a time when resources are increasingly scarce, it is no good to design for the sake of design. The PSS project made this awareness all the greater owing to the 3 elements, Product, Service and System.  Not only did the product need to be sustainable, but the service must prove to provide a significant benefit to the community.  Such systems require on-going involvement so there is the continuing added resource of time as the service operates.

The design process for this projcet highlighted the need for initial research, as well as continuing research through the development stages.  It has been generally noted, that innovation does not occur in a vacuum.  This project made the truth of that sentiment painfully apparent.  A great deal of research was undertaken to first identify potential existing problems.  Further research was required to ensure that best-practice solutions did not already exist (but may not have simply been adopted).  Finally, the soultion development required continuing research into related fields, as well as seemingly unrelated fields.  Our research included related fields such as cafes, espresso equipment, but also spanned cash register mechanisms, slot-machines, potato chip packaging and plumbing.

The project was undertaken in groups.  Designing in groups highlighted the need for clearly set roles and responsibilites.  Concept generation and development is a dynamic process, and trying to keep track of the progress can become very challenging.  During the course of the project, we started keeping formal records of the roles and responsibilities of each member, as well as the latest iteration of the design.  This helped to ensure that each member was accountable for their work, as well as ensuring that we were all 'on the same page' with regard to the design.

I think I am likely to adapt some of this formal documentation, even in my individual work in the future.  I currently keep track of idea generation through a visual diary, but I think I would benefit from keeping a simple list of requirements and outputs.  This way, I might easily refer back to these lists fring the design process to ensure that I have not overlooked an element.