A particular instance I recall was changes to the Calendar web page presentation. Mom initially struggled a fair amount with the controls in the left bar for selecting which calendars were displayed. This was in a Google Apps environment with 20-ish people participating.
I remember when screen presentations could be somewhat cryptic -- per your description as well as other instances. But, as you point out, there was usually a manual. Now? Often it seems to be down to guessing and poking around. Or asking friends. But if you are a bit older and not constantly talking over such things with your friends, that means of edification is somewhat starved.
P.S. Thanks for the response. And as I said, I'm curious about the perspective of someone on "the other side". I'm not trying to be unduly critical, here; just, this is an issue I've consistently bumped up against, from my own perspective.
Some of the most effective solutions to this I've seen require solutions beyond visual representation. They address the problem through dimensions independent of viewport size and space.
For example, LukeW's "Don't Divert the Train" http://www.lukew.com/ff/entry.asp?1798 moves content from behind navigation and into the user's already-occurring action stream. The button is removed entirely, as is the designer's need to consider how communicative icons are for representing actions.
This requires a broader view of how features relate to each other through a design process that discovers other paths to successful behavior. Approaches like the hamburger menu, in addition to the usability issues you note, solve functional goals but have fallen out of vogue for their ineffectiveness at encouraging specific actions. Label-less icons, while attractive and convenient, suffer similar problems. As getting users successful quickly is generally an important goal (before they've internalized your app's unique visual language), the current trend of putting core functionality behind opaque symbols seems counterproductive.
Some text is active, other is not. I don't see any visual cues that distinguish the two. I end up just poking at text, or thinking, "If I were designing this, I'd want more detail or a link to further controls." In the latter case, sometimes I find I was thinking the way the designer/programmer was, and that text does indeed lead somewhere.
For someone who doesn't "think that way", this is more of a challenge.
This also seems to have become more prevalent in desktop / full screen design. Stuff that doesn't look "clicky" is.
I think that was one of my mother's problems with changes to the Google Calendar web page UI.
That's driven by screen size - there's simply not enough screen real estate on a phone to label every button with words. It does have a legit discoverability problem, which most folks in UX acknowledge but don't know how to fix, given other constraints of the media. I've seen a bunch of mobile apps with help overlays or tour videos the first time you run them, which can help a lot. It gets back-ported to desktop apps because once people do learn the functionality, it leads to a cleaner, less cluttered UI.
I'll also point out that early PCs had the same problem. A typical PC from the early 1980s had 320x200 resolution, a little less than a smartwatch does today. For most of the 80s and early 90s, the standard was VGA (640x480), slightly smaller than most smartphones today. Icons were really common back then as well, they weren't all that discoverable, but at least people read manuals occasionally. Most folks don't bother now. Menus were another response to that problem, but they don't really work on mobile because the tap target is too small to efficiently hit it (the navigation drawer & hamburger menu is the modern-day equivalent of the menu).
The web - with its inherent discoverability and all of its space for explanatory text - didn't really become popular until 1280x1024 displays became widespread. I remember designing webapps for 800x600 screens; it was painful, and they had discoverability problems too.