[…], there are some pairing behaviors that are interesting from a design perspective. A myth about Agile software development is that teams no longer spend time designing. Actually, I have found that Agile teams that I am part of design all the time. The designs may be more informal than traditional approaches, but they occur when people have more information and with the people who will implement the design. When a pair f team members get together, if there is a need for them to agree on a higher-level design, they should stop and do pair design. This can be done at a whiteboard or on a small piece of paper. If the resulting design is important enough to capture for sharing with other team members, the pair has a responsibility to capture it in an artifact, maybe onto their wiki or in a document.
The use of pairing has been shown in research to result in better design decisions. This makes sense because the collaboration on a design causes each person to provide a reason for his or her design choices. This forces a person to further explore the validity of the design.
Source: Managing Software Debt – Building for Inevitable Change, Chris Sterling, Addison-Wesley