I think you’ve noticed that the consequentialism vs deontology debate happens in software design, just like everywhere else. My preferred solution is to recognize that you don’t always have the time (or the willing customers, or the knowledge of what dimensions to test) to be empirical about an approach, and having a set of heuristics (aka rules) to guide you is incredibly helpful.
Predict the results, and test your intuitions whenever you can, and especially when it’s a pivotal decision you can’t change later. Taking on dependencies and locking in to a language or platform fall into these categories—be careful, prototype, measure. The vast majority of things (factoring of your codebase, location and sharing mechanism for libraries, etc.) you can make lighter-weight choices, and test as you go—if it becomes annoying, then change it.
UI design contains both. By the time you’re getting to user testing, you’ve ALREADY committed to a small number of options, and you’ve done so by your own use of the product, and intuitions about what different customer personae will want. And even when doing user testing, there is usually NO WAY to resolve the “beginner vs expert” conundrum. You can only test on beginners, so you only get evidence of how easy it is to discover how to do a new thing. You lose out on understanding how cumbersome your design is for someone who spends hours each day in the product and just wants to get their work done efficiently.
The way to avoid that is to override the user research with your intuitions, AND put enough telemetry into the product that you can learn over time how the product is actually used, to figure out the right balance (or make the investment to serve both sets of users).
I think you’ve noticed that the consequentialism vs deontology debate happens in software design, just like everywhere else.
Y’know… funnily enough I actually didn’t make that consequentialism vs deontology connection even though my second to last post was about exactly that! Thanks for bringing it up though! I think you’re right!
The vast majority of things (factoring of your codebase, location and sharing mechanism for libraries, etc.) you can make lighter-weight choices, and test as you go—if it becomes annoying, then change it.
Yeah I agree here. And I think it’s a good point to bring up.
I think that in this situation, some form of what I was saying in this post regarding user research still applies. Say you make some lightweight decision. You’re then faced with the subsequent decision of whether you should change it. In making that subsequent decision, I think people probably err too strongly towards what the heuristics and acronyms say, and not strongly enough towards the user research of how easy to work with they find that the lightweight decision has made the code.
For example, maybe I see something duplicated once and DRY it up. I find that the abstraction I created is awkward to work with. But I keep it because I figure that DRY is good and is what I should do. Instead, it’d be better if I thought about user research moreso as the barometer, if that makes sense.
And even when doing user testing, there is usually NO WAY to resolve the “beginner vs expert” conundrum.
I agree that it is harder. Perhaps impractical in the majority of cases. But I’m thinking about a situation where, you have some design that has existed for a while, the users who have been using it have become experts, and you can do user testing on them at that point. Granted, you can’t compare two alternative designs this way (unless you do some sort of longitudinal A/B test).
I think you’ve noticed that the consequentialism vs deontology debate happens in software design, just like everywhere else. My preferred solution is to recognize that you don’t always have the time (or the willing customers, or the knowledge of what dimensions to test) to be empirical about an approach, and having a set of heuristics (aka rules) to guide you is incredibly helpful.
Predict the results, and test your intuitions whenever you can, and especially when it’s a pivotal decision you can’t change later. Taking on dependencies and locking in to a language or platform fall into these categories—be careful, prototype, measure. The vast majority of things (factoring of your codebase, location and sharing mechanism for libraries, etc.) you can make lighter-weight choices, and test as you go—if it becomes annoying, then change it.
UI design contains both. By the time you’re getting to user testing, you’ve ALREADY committed to a small number of options, and you’ve done so by your own use of the product, and intuitions about what different customer personae will want. And even when doing user testing, there is usually NO WAY to resolve the “beginner vs expert” conundrum. You can only test on beginners, so you only get evidence of how easy it is to discover how to do a new thing. You lose out on understanding how cumbersome your design is for someone who spends hours each day in the product and just wants to get their work done efficiently.
The way to avoid that is to override the user research with your intuitions, AND put enough telemetry into the product that you can learn over time how the product is actually used, to figure out the right balance (or make the investment to serve both sets of users).
Y’know… funnily enough I actually didn’t make that consequentialism vs deontology connection even though my second to last post was about exactly that! Thanks for bringing it up though! I think you’re right!
Yeah I agree here. And I think it’s a good point to bring up.
I think that in this situation, some form of what I was saying in this post regarding user research still applies. Say you make some lightweight decision. You’re then faced with the subsequent decision of whether you should change it. In making that subsequent decision, I think people probably err too strongly towards what the heuristics and acronyms say, and not strongly enough towards the user research of how easy to work with they find that the lightweight decision has made the code.
For example, maybe I see something duplicated once and DRY it up. I find that the abstraction I created is awkward to work with. But I keep it because I figure that DRY is good and is what I should do. Instead, it’d be better if I thought about user research moreso as the barometer, if that makes sense.
I agree that it is harder. Perhaps impractical in the majority of cases. But I’m thinking about a situation where, you have some design that has existed for a while, the users who have been using it have become experts, and you can do user testing on them at that point. Granted, you can’t compare two alternative designs this way (unless you do some sort of longitudinal A/B test).