3 ms·

This is an excellent example of the headwinds/tailswinds asymmetry; we often don’t notice when a rough edge gets sanded off the UX but we scream when one gets a

This is an excellent example of the headwinds/tailswinds asymmetry; we often don’t notice when a rough edge gets sanded off the UX but we scream when one gets added.

411111111111111 4y ago
I disagree that ui changes in general are an example of this. You'll be able to find examples such as that, sure. But that doesn't make it generally true.
jacobr1 4y ago
One of the keys to rapid iteration is having a good feedback-loop. So if there are UX regressions, they can be rapidly identified and rolled back.
- wizofaus 4y ago
  Short of having an army of testers whose job it is to continually retest the same UX sequences with every release, how is that possible? Rapid release to me implies releasing changes faster than they could possibly be manually tested. And automated tests are going to do a rotten job of detecting most UX regressions.
  - jacobr1 4y ago
    You need to instrument real user activity on the site, like tracking shopping cart completions for retail.
    - wizofaus 4y ago
      So you're saying that the way to maintain a stable UX...is to release changes directly to customers (or at least a subset of) to test, and if they react badly, roll it back?
      - jacobr1 4y ago
        It is one part of more wholistic UX/PM practice. Yes, you should have mechanisms to validate the impact of your changes on your customers. You should be having regular conversations with various subsets of your customers for qualitative feedback, both on specific changes and roadmap. You should be doing things like heuristics reviews and user-testing. You should have UX designers with experience designing interfaces with plans for gather feedback _before_ deployment and then validate that change _after_ the deployment with further analysis. During development you also need all the regular QA type testing as well. But yes, if you are regularly changing your UI in order to improve your system and roll out changes, you need to validate the impact. When I was last a PM, I spent a bunch of time monitoring the rollout of changes via Pendo to understand BOTH, if was getting the adoption of features I expected from certain cohorts and seeing if there where any shifts in user behavior (either organically, due to intentional or unintentional changes) And we did this for "beta" groups as well to really validate that feature were working with early adopters before broader rollout. I guess you might not consider the later "production" in sense, but these were real customers with real workloads.
- lazide 4y ago
  In my experience, that only happens when customer attrition is double digits. Otherwise, everyone has their head up their ass enough they’ll ignore or spin the feedback at 99% of organizations.

This is an excellent example of the headwinds/tailswinds asymmetry; we often don’t notice when a rough edge gets sanded off the UX but we scream when one gets added.

411111111111111 4y ago

I disagree that ui changes in general are an example of this. You'll be able to find examples such as that, sure. But that doesn't make it generally true.

jacobr1 4y ago

One of the keys to rapid iteration is having a good feedback-loop. So if there are UX regressions, they can be rapidly identified and rolled back.

wizofaus 4y ago
Short of having an army of testers whose job it is to continually retest the same UX sequences with every release, how is that possible? Rapid release to me implies releasing changes faster than they could possibly be manually tested. And automated tests are going to do a rotten job of detecting most UX regressions.
- jacobr1 4y ago
  You need to instrument real user activity on the site, like tracking shopping cart completions for retail.
  - wizofaus 4y ago
    So you're saying that the way to maintain a stable UX...is to release changes directly to customers (or at least a subset of) to test, and if they react badly, roll it back?
    - jacobr1 4y ago
      It is one part of more wholistic UX/PM practice. Yes, you should have mechanisms to validate the impact of your changes on your customers. You should be having regular conversations with various subsets of your customers for qualitative feedback, both on specific changes and roadmap. You should be doing things like heuristics reviews and user-testing. You should have UX designers with experience designing interfaces with plans for gather feedback _before_ deployment and then validate that change _after_ the deployment with further analysis. During development you also need all the regular QA type testing as well. But yes, if you are regularly changing your UI in order to improve your system and roll out changes, you need to validate the impact. When I was last a PM, I spent a bunch of time monitoring the rollout of changes via Pendo to understand BOTH, if was getting the adoption of features I expected from certain cohorts and seeing if there where any shifts in user behavior (either organically, due to intentional or unintentional changes) And we did this for "beta" groups as well to really validate that feature were working with early adopters before broader rollout. I guess you might not consider the later "production" in sense, but these were real customers with real workloads.
lazide 4y ago
In my experience, that only happens when customer attrition is double digits. Otherwise, everyone has their head up their ass enough they’ll ignore or spin the feedback at 99% of organizations.