I strongly agree with this suggestion because it brings us back to the core of the principle of design: designing for the user. But this practice also faces some of the same constraints as conducting user interviews: people will not always give you the honest answers due to perceived barriers or wanting to come off a certain way in order to meet social expectations. One method I found interesting to try is to gather a group of users/stakeholders and a facilitator who might be the designer, but is undisclosed to the participants, therefore removing frictions for the participants giving critiques out of their fear of offending/hurting the designer.

I often find that the questions that are worth solving are the most complex to answer, but the problems that I'm most capable of solving are often very niche and specific usage scenarios (e.g. filtering emails into 3 separate buckets). So I think a big part of being creative is also knowing where to set your scopes & boundaries. Often times it's more effective to solve part of the problem than trying to tackle the whole (e.g. Tesla solved the entire EV infrastructure from production to charging & maintenance, but not all EV companies need to do that in order to be considered an effective solution).

This is harder than it sounds because people often fear critiques. A great way I've found that helps is to leverage AI to critique your ideas. There are caveats to this though: use the AI too much and it'll start brainstorming for you, plus a lot of the suggestions it makes could be irrelevant/generic. From my practice, I found it the most helpful in inspiring me to think about the aspects that I missed.

An interesting observation I made is that when I'm reading about the gradually more specific problem statements, my brain becomes more excited about the problem at hand and starts actively mapping the problem to potential solutions and trying to envision what else I don't see about the problem. The value in writing a detailed, data backed problem scenario/statement is that it not only captures a more accurate issue, but it also prompts us to dive deeper into figuring out the rest of the puzzle and encourages more solution brainstorming.

Agreed. I've once looked into developing a small widget tool on the phone to quickly convert currencies. While looking into potential usage cases, I quickly realized that it's just impossible to take into account everyone's consideration even for a feature that's so simple. With the cost of developing apps lowering everyday, I wonder if in the future, a lot more tools (at least on the software aspect) will become a lot more customizable to adapt to the user needs. Instead of logging into an app and being prompted with a list of options, the app asks you what you wish to accomplish and how you prefer to accomplish them, then provides you with a customized list of features. While this is also not a perfect solution due to technical complexity and potential learning curve, we might start to see a trend shift towards this direction.

Relatable. When I was designing a course planning tool, I noticed in my design review that I hadn't really considered the needs of administrators or academic advisors, which are also crucial in the loop. You also see this kind of problem in a lot of existing tools where individual function might be very nicely designed, but it doesn't fit into the larger system. An example is Microsoft Tay, which failed to install proper safeguards, leading to extensive harmful exploitation.

The comment about seeking multiple perspectives resonate with me deeply. When you envision a solution to a problem, it is easy to dive too deep into a single narrative and ignore the more wholistic perspective of the issue. When I have worked on projects, there were plenty of instances when I focused my energies on designing the wrong features simply because I failed to account for other perspectives. Had I talked to users more, I would've realized that some problems are simply annoyance that have no drastic impact to the actual user experience.