Documenting, developing or simulating solutions?

Yesterday I went to Aalborg University’s Institute of Architecture & Design to spend a few hours with associate professor Nicola Morelli discussing the state of Product/Service System Design in Denmark. Among others we discussed the PSS model in the previous post and different ways to further develop it as well as alternative models for representing more complex flows – which is one of the main limitations of this model. I’ll make a post concerning this as soon as possible.

What’s interesting is, however, how do the different models relate to documenting vs. developing models. Can they be used for both? Morelli’s answer is yes. Just by working with the models and setting up the action-flows the designer simulates the use case or action-flow thus filling out the gabs which were (possibly) not explicitly presented in just a text description of the problem.

Conclusion is: the model (and other flow models) should be used actively in the design process – as framework or similar – and support the concept development in detail. It’s important to understand the model as a “zoomed in view” and use more general models for describing the whole system from a more general view, e.g. presenting the actors and main actions’ relations.

Designing Product Service Systems, part 1

Being an industrial designer who focuses on the intangible parts of the design in different contexts often requires collaboration with people very different skills. E.g. marketing, programming, strategic design, ergonomics, engineering and of course “real” industrial design – the people designing the tangible parts.

Setting the stage for such a team work requires multiple tools and the ability to communicate across disciplines. Recently I had the experience of participating in such a project with a danish client who needed an “in-shop system” for both a customer-number-system and a video/information broadcast system. Combined – and for a setup of about 80 shops around Denmark. The system would consist of four interfaces:

• The pull number device for the customers
• The check-out counter controlled by the sales staff
• Multiple screens around the shop showing broadcast video commercials and queue numbers
• One central administration for all shops for setting up the independent shops and scheduling broadcast material

These four interfaces would be part of the system. Helping the cross-disciplinary communication we used a model which I was fortunately taught during my studies at Aalborg University:

Here the customer and sales-staff interactions (without the system) would be placed in the upper left corner: physical frontend. And the onscreen interactions in the upper right corner: virtual frontend. Interactions with the virtual backend (e.g. pulling next number from the queue) would be lower right, and lower left is the physical backend. From the customers point of view this would be if the sales man leaves out of sight. E.g. when going to the stock. But in this case we used a “sales man point of view” resulting in the physical backend to be when the customer is out of sight (e.g. being outside the shop – at home shopping on the web etc.).

 I just tried to visualize a simplified flow to make the use a bit clearer. I’ve added arrows which make the model more complex. However, a major part of most systems involves something to be “transported” or carried across the areas’ borders.