Likewise. However, it’s worth remembering that the average user of a website that’s called “Hacker News” is almost certainly more tech-savvy than the average user of any app we create.
My solution is, just as the article suggests:
> Okay, so your service is immensely easier to navigate since you ran it past a battery of theoretical users. Now cut half of it out.
Perhaps that applies no matter how big the app gets, perhaps a simple UX that hides the power tools until they’re called for is the one true way. On the other hand, virtually every time I’ve faced a user saying “$App should perform $Task”, it already does. Sometimes the app doesn’t have a particular feature, but the virtual assistant of the OS does.
What’s the best way of helping those users discover those features?
It's more for the "onboarding" session that you'd cut half the app out, I could have made that more clear. The idea is that you're looking to sprint to value, to get the user's eyeballs on the most-important part of your service ASAP. Otherwise, they don't stick around to explore and find all the power tools. In normal usage, you should definitely have an easy way to find and use all features, but that's a broader product design question, not an onboarding one.
My solution is, just as the article suggests:
> Okay, so your service is immensely easier to navigate since you ran it past a battery of theoretical users. Now cut half of it out.
Perhaps that applies no matter how big the app gets, perhaps a simple UX that hides the power tools until they’re called for is the one true way. On the other hand, virtually every time I’ve faced a user saying “$App should perform $Task”, it already does. Sometimes the app doesn’t have a particular feature, but the virtual assistant of the OS does.
What’s the best way of helping those users discover those features?