I think (one of) the biggest difficulties is that it's not as simple as
Make your apps, websites and tools as simple as possible
There are two targets that could be aimed for- (a) some kind of inherent intuitiveness/simplicity (as in the calendar example), and (b) something the most similar to past experience (as exemplified by the "Reply" button example).
One of my lab partners in grad school didn't believe there was such a thing as inherent intuitiveness. Back when I had more free time for such things, I remember having lengthy arguments with PC-to-Mac switchers explaining how the implementation of feature X was inherently more intuitive or ergonomic on the mac although it seemed a stupid way to do it to them. Some might argue that even in the calendar example, clicking the date is not more intuitive but similar to the past experience of writing on a physical calendar.
However, I'd argue there is definitely such a thing as an interface that is inherently non-intuitive, so by contrast, there must be things that make an interface inherently more intuitive.
So, I think of (a) and (b) as competing trade-offs that must be compromised. Going too radical towards (a), especially on a product that people already have formed associations with, and you end up an awesome, but fringe, product with a small community of fanatic followers (see NeXT). If you create a radically new something, or the impression thereof, you have a lot more leeway, since people are not psychologically attached to previous experiences.
Go too radically towards (b) and you aren't adding anything different with your product.
If you're making something new to go into battle against existing, well-established products, the best approach is to start with (b) and then slowly "fix" things, one at a time, over time, starting with features that give the biggest bang for the smallest change in user behavior. This applies to user-facing front ends, only of course.
Make your apps, websites and tools as simple as possible
There are two targets that could be aimed for- (a) some kind of inherent intuitiveness/simplicity (as in the calendar example), and (b) something the most similar to past experience (as exemplified by the "Reply" button example).
One of my lab partners in grad school didn't believe there was such a thing as inherent intuitiveness. Back when I had more free time for such things, I remember having lengthy arguments with PC-to-Mac switchers explaining how the implementation of feature X was inherently more intuitive or ergonomic on the mac although it seemed a stupid way to do it to them. Some might argue that even in the calendar example, clicking the date is not more intuitive but similar to the past experience of writing on a physical calendar.
However, I'd argue there is definitely such a thing as an interface that is inherently non-intuitive, so by contrast, there must be things that make an interface inherently more intuitive.
So, I think of (a) and (b) as competing trade-offs that must be compromised. Going too radical towards (a), especially on a product that people already have formed associations with, and you end up an awesome, but fringe, product with a small community of fanatic followers (see NeXT). If you create a radically new something, or the impression thereof, you have a lot more leeway, since people are not psychologically attached to previous experiences.
Go too radically towards (b) and you aren't adding anything different with your product.
If you're making something new to go into battle against existing, well-established products, the best approach is to start with (b) and then slowly "fix" things, one at a time, over time, starting with features that give the biggest bang for the smallest change in user behavior. This applies to user-facing front ends, only of course.