3 ms·

The best model I've read about this is to separate feedback loops into two categories: Problem Discovery - listen to users to understand where they struggle, b

The best model I've read about this is to separate feedback loops into two categories: Problem Discovery - listen to users to understand where they struggle, but ignore their proposed solution and desires (except to the point it helps you understand the problem they are attempting to communicate). Solution Discovery - design a solution that addresses the problem, and validate it with real usage. Importantly not just talking, but users need to actually try it out.

rapnie 5y ago
Do you have a resource that explains this is more detail?
- jacobr1 5y ago
  Ash Maurya - Running Lean Cooper and Vlaskovits - The Entrepreneur’s Guide to Customer Development
- chefandy 5y ago
  While not a direct response to the two-lane idea, if you're interested in exploring these processes in general, searching for "design process" will get you a ton of info. In much of the design world, though especially in UX, design process navel gazing is somewhat akin to tech stack navel gazing among web developers.
ehnto 5y ago
Someone using your product probably does have a decent grasp on what a good solution would be, at least from the point of view of the user interface. We built a product that's broken for their use case in the first place, what makes us think we'll get it right the second time without their input? You don't have to do exactly what they suggest, but following that advice I'd expect to see a lot of solutions that miss the mark in subtle ways that would be really frustrating as a user. Sometimes people don't fully understand why "Do thing Y instead" would make it better, so it's not in their "Problems" section, but they for sure know that having the button do Y instead would solve it. It's probably worth thinking about and not ignoring.
- jacobr1 5y ago
  Oh sure, you always need to listen to the requests - especially for existing systems. I had one set of legacy workflows I once replaced that rough went like: 1) Export data from system A to a CSV. 2) Remove/reorder a few columns manually in excel 3) Get manual approval from a manager 4) Email to different department 5) Upload to system B via their import function The request was to just give us an "export with the right format," thus replacing step 1 & 2. But we also heard complaints from the team doing step #5 that it was pointless and could be automated, and from the managers in #3 that really they used a simple rule that if X < Y approve otherwise deny. So we thought we could build a workflow automation that connected the two systems via API, with an automated approval and flag those that didn't meet the rule for manual review. So we propose this, everyone agrees. We build a pilot, test it, everyone likes it. Then go to release it and find out that this ignores any number of cases where in #2 there where hidden workflows like "any time you see scenario W, send it to Jenny and she runs a formula on these columns to adjust" or "actually the manager never approves anything from this department related to an acquisition because of factor x, and it needs to go to this different group." There was about a dozen similar requirements. Could we have identified these sooner? On other projects we usually did, but this project went further than most before they were detected. We ended up temporarily building that export button requested by the users originally and were planning to fix the API based workflow ... but then there was a reorg and priorities shifted. We never came back to project and AFAIK those groups still work via email. But they don't do nearly as much excel busywork as before ¯\_(ツ)_/¯

rapnie 5y ago

Do you have a resource that explains this is more detail?

jacobr1 5y ago
Ash Maurya - Running Lean Cooper and Vlaskovits - The Entrepreneur’s Guide to Customer Development
chefandy 5y ago
While not a direct response to the two-lane idea, if you're interested in exploring these processes in general, searching for "design process" will get you a ton of info. In much of the design world, though especially in UX, design process navel gazing is somewhat akin to tech stack navel gazing among web developers.

ehnto 5y ago

Someone using your product probably does have a decent grasp on what a good solution would be, at least from the point of view of the user interface. We built a product that's broken for their use case in the first place, what makes us think we'll get it right the second time without their input? You don't have to do exactly what they suggest, but following that advice I'd expect to see a lot of solutions that miss the mark in subtle ways that would be really frustrating as a user. Sometimes people don't fully understand why "Do thing Y instead" would make it better, so it's not in their "Problems" section, but they for sure know that having the button do Y instead would solve it. It's probably worth thinking about and not ignoring.

jacobr1 5y ago
Oh sure, you always need to listen to the requests - especially for existing systems. I had one set of legacy workflows I once replaced that rough went like: 1) Export data from system A to a CSV. 2) Remove/reorder a few columns manually in excel 3) Get manual approval from a manager 4) Email to different department 5) Upload to system B via their import function The request was to just give us an "export with the right format," thus replacing step 1 & 2. But we also heard complaints from the team doing step #5 that it was pointless and could be automated, and from the managers in #3 that really they used a simple rule that if X < Y approve otherwise deny. So we thought we could build a workflow automation that connected the two systems via API, with an automated approval and flag those that didn't meet the rule for manual review. So we propose this, everyone agrees. We build a pilot, test it, everyone likes it. Then go to release it and find out that this ignores any number of cases where in #2 there where hidden workflows like "any time you see scenario W, send it to Jenny and she runs a formula on these columns to adjust" or "actually the manager never approves anything from this department related to an acquisition because of factor x, and it needs to go to this different group." There was about a dozen similar requirements. Could we have identified these sooner? On other projects we usually did, but this project went further than most before they were detected. We ended up temporarily building that export button requested by the users originally and were planning to fix the API based workflow ... but then there was a reorg and priorities shifted. We never came back to project and AFAIK those groups still work via email. But they don't do nearly as much excel busywork as before ¯\_(ツ)_/¯