“Power of Ten” – this weeks method focuses on the reframing technique. It is based on the short film of the same name from 1977. The movie shows a picnic scene in Chicago with different magnitudes of distance from 1 meter up to 1024 meters and then down to 10-16 meters. Goal of this was to shocase exponential growth. Humans are used to think linearly although many things actually grow exponentially.
Task: Team members start by choosing a scale. Although the original movie works with magnitudes of distance, they can choose another scale which fits their purpose (distance, size, time or more various like cost, complexity or even abstract like rewarding points). After they will focus on their problem of choice by zooming in and out of it. By moving in powers of ten (adding or removing a zero at the end) they will try to really understand the problem. This moving through magnitudes should enable patterns which repeat at different scales.
Goal: In design thinking, this method helps changing our point of view. By looking at a problem from different magnitudes, basically by zooming in and out of your current situation, you will find the right framing for the different issues of your problem.
When working on virtual and design problems, you need to construct a whole model in your mind to be able to work on it. “Powers of Ten” helps you in this complex process to find and develop different patterns with different magnitudes.
Most of the team members liked the fact that this method forced them from the start to clearly lay out the structure/method/functionality of what they were working on.
“Being forced to define and put down the scale in writing, allows you to think about all possible levels beforehand and also seeing it written down makes it likely to revisit a level that you already analysed and ask what is about this level that hasn’t been considered yet.”
Others raised issues regarding the scaling choice. They think it’s hard to apply it consciously and in many cases won’t help to solve the problem. They think it would be better suited to create new functionalities and not so wells suited for problem solving.
Although team members were not very convinced of this idea and of their scaling at first, they all agreed on the fact that it’s nice to start understanding the general idea and then work their way down to the deeper levels when there is a doubt on a problem.