One of the cornerstones of agile development is striking a balance between planning, design and execution. The idea is that you don’t really know what you will be doing 6 months from now, and that users don’t use a design, they use your product. Spending as little time as necessary on Big Design Up Front (BFUD) shortens the feedback loop until you get confirmation that the requirements and design you thought were valid actually are valid.
To be fair, it can be easy to paint yourself into a corner by not doing enough upfront design. However, it’s important to remain aware of the intersection between “we have a future-resistant design that meets customers’ needs” and “you ain’t gonna need it” (YAGNI). At the point where you start speculating on user stories, especially those that will convoke significant cost (and waste if unnecessarily implemented), stop and consider whether the cost of designing for possible futures now outweighs the cost of fixing a problem later.
Designs, like plans, should be expected to change. Building software is not like building a house. Studs can be moved around and foundations can be adjusted later. We must plan and design with change in mind, because the requirements are going to change whether we like it or not.