The cliché quote of “if Henry Ford has asked people what they wanted, they’d have said a faster horse” is a cliché for a reason. Most people don’t know what they want - that’s why good product designers who can identify, synthesize, and execute products are worth big money.
There are 2 things to differentiate - product vision, and learning how to listen to feedback.
The former, designing new products that solve people’s problems, is a craft that has no silver bullet. It requires a mix of experience, intuition, technical know how, observing the landscape of existing alternatives, knowing how to anticipate technical/economic/sociological evolutions, etc.
The latter is about making sure that what you designed does what you intend it to, identifying what confuses your users, what gets in their way, etc. This is where all the classical methods of user observation/testing/surveys/etc can be useful. This sounds easy and obvious, but it is anything but - i have met my fair share of designers who stick to their principles and are unwilling to budge when reality conflicts with their ideology, companies that inexplicably never fix bugs that most of their users encounter and rage about on the support forums/social media, etc.
The two are very different skillsets, and it’s hard enough to be good at one, let alone both.
The article uses Intuit as a case study; the dynamics of how to do genuinely great work when your business involves selling an antidote to a poison you lobby for is an exercise left to the reader.
And yet there is still a significant global industry for breeding faster horses. It's much smaller than the auto industry, but still a profitable niche.
There are 2 things to differentiate - product vision, and learning how to listen to feedback.
The former, designing new products that solve people’s problems, is a craft that has no silver bullet. It requires a mix of experience, intuition, technical know how, observing the landscape of existing alternatives, knowing how to anticipate technical/economic/sociological evolutions, etc.
The latter is about making sure that what you designed does what you intend it to, identifying what confuses your users, what gets in their way, etc. This is where all the classical methods of user observation/testing/surveys/etc can be useful. This sounds easy and obvious, but it is anything but - i have met my fair share of designers who stick to their principles and are unwilling to budge when reality conflicts with their ideology, companies that inexplicably never fix bugs that most of their users encounter and rage about on the support forums/social media, etc.
The two are very different skillsets, and it’s hard enough to be good at one, let alone both.
The article uses Intuit as a case study; the dynamics of how to do genuinely great work when your business involves selling an antidote to a poison you lobby for is an exercise left to the reader.