The word "intuitive" as applied to design is a bad word; it is just shorthand for "I like it" or "I find it easy or familiar." As such, it has no place in design critiques and discussions, unless it is heavily qualified. For instance, "our primary audience of professional statisticians will find it intuitive if we represent the normal distribution using this chart." But even in this case, it is just shorthand for "familiar," and it'd be better to just use the more accurate and meaningful word.
So why is calling something "intuitive" so bad? Well, because it provides no useful information on how to improve a design. It provides no groundwork to have an intelligent discussion of design alternatives. Because for it to be true, someone has to share some significant part of your life experiences.
In short, it is bad because you are falling into the old, lazy trap of imagining that the rest of the world is like you, that what you find intuitive, compelling, etc. is what others find intuitive, compelling, etc. That assumption is an enchanting lie; it leads to all sorts of bad design decisions. Even if it happens to be true in some qualified sense, you need to understand why that would be true. And that requires going beyond simplistic, squishy statements like, "this is intuitive."
Intuitive for whom?
What shared experiences, learning, skills, tools, background, etc. would others need to have for them to find it intuitive?
For whom would it be not intuitive?
Write your answers down. These are assumptions you're making about your users. Next, ensure that at least the vast majority/your primary audience will share the things you identified. By the way, are you sure you know your users so well? Did you actually research them? Or are you piling assumptions on top of assumptions?
Precious little of human understanding is truly intuitive. The vast majority of what we understand is based on observing, trying, failing, learning. Wash. Rinse. Repeat.
Walking is intuitive, right? Tell that to your six-month-old. I'm not a child psychologist, but I do have five kids, ranging from ten months to twelve years. I've had the opportunity to watch each of them slowly, painstakingly learn a whole bunch of simple, "intuitive" things. And that's the basic stuff of life; the stuff that really should be intuitive, if anything is.
On the other hand, if you're talking about software, there are layers upon layers of learning for people. I remember back in '96, when I worked for a geophysical logging corporation, watching one of the field guys struggle with a mouse. You think the fact that links are usually underlined meant anything to him? You think he'd find it intuitive that he can click on that underlined bit of text, much less have any expectation of what would happen afterwards if he did? Hopefully you get the idea. What people don't know but that you think is obvious can shock you--because you have these layers upon layers of learning that you're starting from. Problem is that it's basically guaranteed your layers are different from theirs.
We can even zoom up the shared knowledge stack to software professionals. You'd think this group, by and large, would have a lot more common ground (and you'd be right). But when's the last time you tried to learn a new technology or tool and just found everything "intuitive"? Did you perhaps think, "why can't this be just like <insert name of thing I already learned>? Everybody does it that way." Really? Have you done the research to justify that assumption, or are you just basing it on your own experience?
Chances are, there's probably a wide variety of solutions for similar problems, even in our rarified atmosphere. None of them is always the right way or always the wrong way. Certainly, none of them is definitively "intuitive." And until you dig in to analyze the alternatives, to understand their rationales, there's very little ground to be offering a critique, much less to be making sweeping generalizations about something being "intuitive."
The good news is that there are much better, more useful and productive ways to critique and evaluate designs. There are whole branches of knowledge around perception and cognition, much of which has been distilled and applied to software design for you. People have been designing things for many years, learning from those experiences, and have built up good, common design principles and heuristics. You can often leverage well established patterns (and not so well established ones)--but you need to understand them and make sure they apply in your context. You can't and shouldn't start from scratch with every design problem, but you need to be rigorous in the selection of patterns and the application of principles, especially when you diverge from patterns. And last, but certainly not least, test--test as much as you can, as early as you can, with people who are as close as you can get to your actual target users.
So the next time you are tempted to call a design "intuitive" or "not intuitive," just stop. Analyze your assumptions. Discover why, and instead of using that word, just say all the reasons why you find it that way, leveraging the knowledge, principles, patterns, and test results mentioned above. And if you can't find good reasons to justify your feelings, then just say "I don't like it. I don't know why; I just don't." It's okay to say that, because it is honest, and maybe someone with more Design/UX background can help you to tease out the underlying reasons. But whatever you do, don't say "intuitive"; it's a useless, lazy word when discussing design.
P.S. For much of the above, you could swap in "usable" or "user friendly" or "easy to use" for "intuitive." In this context, they are nearly synonymous and all boil down to basically the same thing--you need to be more thoughtful and rigorous in your design critiques.