We all use heuristics to narrow the scope of information to make decisions. Sometimes we are not aware of the assumptions our brain is making about a decision. That is part of framing a problem or situation. Reframing changes the structure of our bias to see information as newly relevant. If your customers aren't connecting with your product in the way you thought or it isn't offering the value that it should. You might have incorrectly framed the problem and solution. Reframing can be subtle or major depending on the previous outcome in your desired future outcome.
I would like you to test your memory with an example. I'm going to give you eight numbers to remember. 2 - 8 - 4 - 6 - 3 - 9 - 1 - 5. Now look away and see how many you can remember.
So how did that go? It's possible but not very easy. If you didn't remember don't worry it doesn't mean anything lol.
Ok. Do you think you can remember 4 numbers? That sounds easier right? Ok here are your four numbers. 28 - 46 - 39 - 15.
How'd that go? It's still eight individual numbers but when paired together to create four numbers it is much easier. This is a simple example of how changing the framing of a problem can make the task easier. Our brain recategorized the information.
You might be thinking yeah great I remembered more numbers but how is this concept relevant to product design? Here's a real-world example: When Apple was designing the iPhone there was a debate on if the display should be covered with plastic or glass. The team evaluated both materials and decided on plastic since it was less likely to break when dropped. It was an investment to buy the device and creating a fragile phone didn't seem like the right choice. The impact resistance of plastic was better than the trade off of the abrasion resistance of glass.
When the iPhone was revealed, the tech world was surprised that the display was plastic. Overall, they were disappointed that it wasn't going to be a premium feeling device. During some real world testing, scratches started appearing on the plastic displays. Jobs told the team it was unacceptable for the phone to have scratches from normal use. If the phone had scratches from being in the consumer's pocket, that's Apple's fault. The vision for the iPhone was a premium entertainment device. This experience with the plastic display didn't match the vision. The glass changed how the device felt in the hand. The rigidity, the weight, and the smoothness reinforced the perception of premium. If the consumer dropped it and the glass broke it's their fault. Of course, the consumer would be upset but they shared the responsibility of breaking the device.
This example was from the book Build by Tony Fedall. It's one of my favorite books and it is filled with wisdom for people in the product development world or anyone coming out of college about to get their first job. Buy it, read it, gift it, it's great.
By having clarity on the product vision, Steve reframed the problem and changed what was important. You can do the same thing with your projects.
This conversation came up with one of our clients. Part costs came in high on one of their products due to large parts, deep draws, and low production numbers. The assumption was that a large product was necessary for a high price point. The project team questioned that assumption and believed that other attributes also affect the consumer's perception. Premium touch points and improved human-machine interactions moved up the hierarchy while size moved down. Our hypothesis was that this would do a better job of creating value than the size of the product. This completely changed the design and outcome of the project.
To recap, Question your assumptions by revisiting the "product vision" and the "desired product attributes". Are they aligned with each other? Are you missing contextual information? Are the elements organized properly? How does it affect the user's perception? Does their perception align with the product vision? If not, identify attributes and functions that should be eliminated. Reinforce the product vision. There will be times when consensus cannot be reached. That is okay. Create a second hierarchy list, start designing, and evaluate both designs with consumers. If you don't have the resources for both then the decision maker needs to make the call. Test it with your users to validate. Do this throughout the development cycle.
I hope this inspires you to question your assumptions, reframe your project if necessary, and find the best path to success!
Comments