A complete and detailed Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, a full DRD is too onerous for systematic industrial use as it is not cost-effective to write, maintain, or read. The key idea investigated in this paper is that DRD should be adopted only to the extent required to support activities particularly difficult to enact or in need of significant improvement in a particular context. The aim of this paper is to empirically investigate the possibility to customize the DRD by documenting only the information that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a DRD information item depends on its category (e.g. Assumptions, Related requirements, etc.) and on the activity it is meant to support. This hypothesis is investigated through two controlled experiments involving a total of seventy-five post-graduate master students as experimental subjects. The value of DRD information was shown to significantly depend on its category and, within the same category, on the activity it supports. Furthermore, our results show that, on average among activities, documenting only the information that has been required at least half of the time (i.e., the information that will probably be required in the future) generates a customized DRD containing about half the information of a full documentation. Such a significant reduction of information to document is expected to mitigate the effects of inhibitors that are currently preventing practitioners from documenting the rationale of their design decisions.