In addition to problem-domain concepts, most software calls for elements that belong to the system domain. Files and saving are good examples of what once seemed essential to force the user to think about but which isn't essential to the problem domain the user would rather think about.

Bad software leaks system concepts unthinkingly which forces users to learn too much about how the software solves the problem on a computer. No user really wants to think about creating or saving a configuration although some synthetic system domain stuff might be inevitable. How can a user make use of a potentially valuable feature to do with changing how the software works rather than about a "General Ledger"? Alternatives to are not always apparent or better and cognitive load is a cost but it may be worth the benefit.

Worst of all are system domain pollutants unique to this one system. Users can and do learn about computers as well as their problem domain and they carry this knowledge from one system to the next. Expert users have traditionally criticised Apple for "dumbing down" the computing experience; some domain experts also become very competent with sophisticated software and choose to bear "cognitive load" in exchange for capability.

The core skill here is empathy, understanding things from your users' point of view and designing accordingly. Users are not stupid, they're busy, but they also have wants, needs prior knowledge and individual differences.

The way "intuitive" is used these days (perhaps always) seems not to be much different than the word "familiar". The distinction is critical if your goal is making systems learnable and for reducing assumed knowledge to optimise for beginners who are often not the ones in contact with support asking for more complex capability.