Framing

In this post I share the second of my top three learnings from art college.

Framing

Framing is the way you define the problem you are trying to solve. In industrial and product design the problem might be something like: how to remove pet hair from a carpet; or how to hold a single rose, beautifully.

How we frame the problem can unlock our imaginations. Conversely, framing can constrain and contaminate how we approach the solution. For example, if I ask you design a chair you will likely design something conservative and derivative. If I ask you to design a device for sitting, then your mind will open up.

Application to Business

In IT we often define the problem by describing business objectives (the why). That’s good. Then we write and approve a requirements document (the what). That is less good for two reasons:

  1. The sheer size and complexity of the requirements document can create a can’t-see-the-wood-for-trees effect. We become so distracted by or rigidly attached to the requirements that we forget the objectives.
  2. Too often the requirements aren’t actually requirements (the what). They are proposed solutions (the how).

To unlock the imaginations of our solution architects and software engineers we must frame the problem correctly. What problem are we really trying to solve? What is the why? What is the what? Let the engineers figure out the how.

More on reframing here, including the excellent “why they put mirrors in elevators” parable: https://hbr.org/2017/01/are-you-solving-the-right-problems

Leave a comment