Two basic strategies: Design for the median user or the least common denominator. At web scale we are often driven to least common denominator out of self defense, because lower power users squawk more about confusion than median power users do about efficiency.
> Your standard users never become high power users on your platform
This is considered good, because if they become power users and get their stuff done faster they'll "engage" less and we can't have that.
Remember that today's career incentives in tech companies means tech is primarily there to drive "engagement" and is not there to solve the user's problem.
If your design is very dense, then a new user will be scared away. If you NEED growth, you can't afford to scare away users. You need to cater to them as much as possible. You need them to tell their friends "yes its very easy to get started with".
It leaves no room for a learning curve.
And this is also something we have come to expect. So anything with a learning curve feels like a massive investment, and we feel dumb whilst using it and not knowing how, because everything else is so dumbed down that it is instantly intuitive. This has made computers and software very popular and widely used. And I am happy for my (grand) parents that they can use these things now.
But it has come at a great cost of productivity for everyone. Because even the designs where we would have invested the learning time to get faster, can't invest that time, because the interface is so simple it becomes limiting.
>Design for the median user or the least common denominator.
Design for the least, compare against average, and don't cap the best, use those agents as immediate beta-user -> quality/dev feedbook loop, dog-fooding user requirements as a fundamental base, and don't let perfection impede progress.