You seem to be approaching this from the perspective of an abstract belief that Communication is Good and to be frustrated because in your impression for these members "communication is not valued as much as actions."
The key would thus seem to be to set the belief in communication for its own sake aside, and instead focus on specifically how a given communication is necessary to enable appropriate action.
"Let's quickly talk through task x and make sure we're on the same page about what is to be done" If there's resistance to this, ("Of course I will implement what is in the spec, stop bothering me") you can turn it around and ask them to describe to you in their words their impression of what is to be done. If key things seem to be missing, or different from your own interpretation, you can ask questions. It may actually be better to start right out with asking for their interpretation, rather than using that as a fallback.
"Customer Y has a problem with Z, let's talk through some ideas for how to fix this and pick one"
"Fred can't seem to understand how to use that project you did last week, could you come show he and I together how to work it?"
One thing implicit in this is less formally scheduled "meeting" format communication, and more impromptu as-needed communication. However, in doing this you need to exercise some care about the frequency and timing of interruptions - if you are dealing with, say, software developers who needs large blocks of interruption-free time to concentrate on particularly thorny problems, you'll need to be tuned into when is and is not a good time to interrupt, possibly to the point of literally asking or leveraging times when they get up from their desks. Beware also of scheduling interruptions - "when can we talk about x?" can be a very problematic question, if the person is in the midst of a no-end-yet-in-sight quest to solve pressing problem Y.