Saturday, October 25, 2014

Cross Learning from Software Design to Product Design

Every now and then we come across new products that completely redefine the way we look at that product category. Some prominent examples are in the categories of room temperature control (Nest), watches (Pebble), personal transport (Segway), etc. Though the process of those respective product innovation might have been different from each other, I started to think if there is a way to formalize such product innovation - so that the process by itself contributes to completely changing the design of the product.

This got me to start exploring the As-Is, about what goes into the product design process. I read about the Design Thinking process. I read through the CAD software tools and what they enable in the design process. 

What I came across was very different that I saw in my field - software. There was a lot of focus on physical representation of a concept, idea or design. Even ideating was encouraged in physical form - this I felt pushes the designer towards incremental thinking - he or she is going to always look at a car as having 4 wheels, front and back seats, etc. I had also tweeted about it

I couldn't find any reference in design process artefacts that deal with the abstract - I did come across Mind Maps but they weren't actually a way to represent an idea - they contributed more to exploring, empathizing and defining the problem. 

But, in my own field, we had process artefacts that we use as tools to look at ideas for a solution at an abstract level before we looked at it in the physical level (i.e. UI specifications/wireframes). One of that which gained a lot of ground in recent times is Solution Architecture - a diagrammatic representation of functional components that go into solving a particular problem - a way of representing a solution. This is supported by some more diagrammatic process artefacts/tools.

Now, solution doesn't necessarily have to be a software solution. Everyday physical products are also solutions to some or other everyday problems. That brought me to the thought that why can't product design process inculcate such abstract level ideation tools. Taking the design thought to this abstract level will let us look at the product as a solution - I felt this would encourage Lateral Thinking. I tweeted about this too

Imagine if we could relook at a commuting solution (i.e. Car) in terms of a solution architecture - with functional components like locomotion, passenger comfort, driver communication, etc. Or perhaps, we could re-lay the functional components in a different manner - instead of passenger comfort and driver communication as two different components, we might just call it human interactions (driver and passenger). Imagine what kind of design ideas would it present if we re-lay components like this. It would give us a chance to re-think the way we think about the function and association of the components. Such thought about re-looking at a car or any other product could be encouraged with abstract diagrams of solution.