In the late 1980's one the biggest centers of object technology was the research labs of Tektronix in Portland Oregon. These labs were one of the main users of Smalltalk, and many key ideas in object technology were developed there. Two renowned Smalltalk programmers there were Ward Cunningham and Kent Beck. They were, and are, very concerned about how to teach people that same deep knowledge of how to use Smalltalk that they had gained. From this question of how to teach objects came the simple technique of CRC (Class-Responsibility-Collaboration) cards.
Rather than using diagrams to develop models, as most methodologists were doing, they represented classes on cards, using 4 X 6 index cards. Rather than indicating attributes and methods on the cards they write responsibilities. So what is a responsibility? It is really a high level description of the purpose of the class, the idea is to try to get away from a description of bits of data and process but instead to capture the purpose of the class in a few sentences. The choice of a card is deliberate - you are not allowed to write more than what will fit on the card.
The last letter refers to collaborators. With each responsibility you indicate which other classes you need to work with to fulfill it. This gives you some idea of the links between classes, but still at a high level.
CRC cards are an aggressively informal technique, they also encourage discussion. In a CRC session the developers will crowd around a table each person picking up a card as they describe how the class participates in some use case. By giving the developers something to touch that represents the class, you make it easier talk through the designs. By accenting responsibilities instead of data and methods you help them get away from dumb data holders and ease them towards understanding the higher level behavior of the class.
Some people find CRC cards to be wonderful, others find CRC leave them cold. I certainly think you should try them out, to see if the team likes working with them. Use them particularly if you find teams are getting bogged down in two many details too early, or seem be identifying classes which seem cluttered and don't have clear definitions.
Use class diagrams and interaction diagrams to capture and formalize the results of CRC modeling. If you are using class diagrams ensure each class has a statement of its responsibilities.
Beware of long lists of responsibilities: if it doesn't fit on a 4X6 card you are missing the point.
The best book that describes this technique, and indeed the whole notion of using responsibilities, is [Wirfs-Brock]. It is an old book, but it has aged well. You can get hold of Beck and Cunningham's original paper online.