Indeed. And writing out a design is actually a good method for thinking through the design. It helps uncover assumptions, including those that are flawed. It allows you to weigh various design options explicitly. It provides a place for identifying and resolving ambiguity and lack of clarity in the requirements. Contracts can be distilled in the process. Such design docs can also focus and direct implementation; you have a clearer picture of the parts and contours of your system. In a way, it is like programming, but at a conceptually higher, architectural level, where you work through and chew on the thing to flesh out and validate it in the very act of specifying.

And by doing this sort of exercise, you can avoid wasting time on dead ends, bad design, and directionless implementation. It's okay if requirements change or you discover something later on that requires rethinking. The point is to make your thinking more robust. You can always amend a design document and fill in relevant details later.

Furthermore, a mature design begins with the assumption that requirements (whether actual requirements or knowledge of them) may change. That will inform a design where you don't paint yourself into a corner, that is flexible enough to be adapted (naturally, if requirements change too dramatically, then we're not really talking about adaptation of a product, but a whole new product).

How much upfront design work you should do will depend on the project, of course. So there's a middle way between the caricature of waterfall and the caricature of agile.