RFPs, Requirements documents and even Project specifications occasionally come into my inbox with loaded phrases that always cause me concern.
"Easy-to-use", and "Intuitive" are warning signs, and I always try to rephrase them down into something more specific.
I *know* what the writer is asking for. The problem is that at the time of writing, they don't.
See, with big projects, these requirements get converted into a set of deliverables, and if a strong project methodology is in place (by either the client or the solution provider), each deliverable becomes a checklist item during UAT, and someone needs to tick a box that says "Yes, this feature is intuitive".
And that's not just a yes/no answer, and has so many hidden variables. Intuitive to who? In practice that can mean one individual in the organization who thinks it should "just work" in exactly the way that some other system they have used before did. Or should provide big buttons, or read their mind.
They may expect it to use terminology they are familiar with (which sounds reasonable) even if the terminology is incorrect if applied to a new system.
In Microsoft Word, when I want to make a new file, I go to the file menu. When I want to make a new file on the blog, the menu should say "file"
A large number of assumptions folk make about what is "intuitive" is not that at all, it is learned behavior. If you'd never used MS Word before, then going to "File" to create a new page would be unlikely. Until you learned it.
It is inevitable that doing a new thing may involve a little learning (or re-learning) to do it right.
These weasel words hide in the background of a requirements document until the end, where a supplier can produce a suitable, working, sensible and standards-compliant product or interface, but then be taken to task because it doesn't meet the right level of expectation from someone who can't voice what they really expect.
Of course, developers should work closely with a client and their stakeholders to draw out the actual expectations, and try to meet them on a point-by-point basis. By doing this, the requirements can be nailed down into actual features "A link or button to create a new page will be available in the administration area" and this dangerous vagueness can be avoided, and the UAT checkbox can be ticked.
"Easy to use" has the same loaded vagueness in it. Of course the developers and designers should be doing anything reasonable to make their systems easier or more usable. But when "easy" comes to mean "can be used by someone who doesn't read instructions", this can severely limit their ability to add features. Features that are being requested by those same users.
There is a place for tools that can "just work" or be used without instructions. Those are triumphs of design.
Should be usable without training
A number of high-level managers seem to view staff training as an optional extra. We've sometimes spent dozens of hours trying to make a certain complex feature have the right number of buttons in just the way a customer wants because it was not 'easy' enough ... when the manager who raised the change request wasn't ever going to be the one to actually use it, and the end user (often there are only actually one or two content managers who ever do everything anyway) could have handled it after a little training.