More on how to use them.
Using the Cards Alone
Even if you have only one set of cards, you can use them in several ways.
The most obvious way for using the cards is just to read them. Essentially they are concentrated knowledge, something like little cheat sheets. So Instead of having to read dozens books with hundreds of pages, you can start by reading the cards. There is more content online, so you can dig deeper, if you like.
Using the cards in this way is especially helpful for junior developers. But it's also helpful for more experienced ones, who like to improve on how to communicate the reasons for their decisions.
Preparing a Design Decision
Sometimes you have to make an important design decision and it's not clear which solution is best. So you have to collect advantages and disadvantages to make up your mind or to prepare for a discussion with your colleagues or your architect. You can do that by using the cards.
Each card has references to related cards which might be helpful in the same situations. There are contrary and complementary cards. So if there are two possible solutions, A and B, and one card favors solution A, a contrary card would likely support solution B while a complementary card points to further aspects which might support solution A.
As a Reminder
If some aspect is very important in your project or if you keep forgetting a certain thing, tape the corresponding card to your screen. You will see it often so it will constantly remind you of that aspect.
Using the Cards with a Colleague
If you have one card set each, you can use the cards in even more ways.
When you discuss an important design decision, use the cards to describe your arguments. As a key rule, you should never play out more than one card at once. Find the card that you think is most convincing and explain why this argument supports your preferred solution. Then it's your colleague's turn.
This ensures that you both have an equal share on the discussion which is especially helpful if one of you is more talkative than the other. As a result it's not the loudest person who has the most impact, it's not the quantity of the arguments that counts but it's the quality.
In case none of you has a strong tendency to one of the solutions, just randomly assign positions so the different solutions are all discussed. Even if you both tend towards one solution, it can be helpful to have one of you play the devil's advocate and argument the other way. Important decisions should not be made based on feelings but they deserve a discussion that uncovers all the relevant aspects.
Alternatively you can both take five or ten minutes to prepare the top three arguments for your solution. Use the related cards section as explained above. Then each of you explains the respective three arguments and enter a discussion phase afterwards.
Using the Cards in the Whole Team
The Design Cards are all about communication and communication is probably the hardest and most crucial thing in software development. So discussing design decision is one thing but sometimes it is also a good idea to share knowledge in the team and to discuss software design in general.
Whether you do this in a brown bag session or using lean coffee, the Design Cards are an ideal conversation starter.
Some design decisions, normally those concerning public API and architecture, are so important that the whole team discusses them. Even more than discussions among two developers, these meetings tend to be dominated by one or two people while the others often do not get the chance to participate to the same degree.
Using the same core rule as describes above (never play more than one card at a time) the discussion can be evened out. Junior developers have a chance to follow the argumentation as you have to explain why your argument is an instance of the argument on the card. And the experienced, yet quiet ones get a chance to provide valuable input to the discussion.
In such cases it might also be helpful to appoint a kind of moderator. Ideally this is someone who is not a direct stakeholder in the decision, a scrum master or a developer from another team. This moderator then gets the orange moderation cards and takes care that the core rule is adhered to.