I always begin system design interviews by repeating and clarifying the framing of the question. Some simple ones: "what kind of service/website is this? what's our expected peak load today? 2 years from now? 5 years from now? [regarding data structures] what's the biggest value we'd reasonably want to store?"

You're backing into things like QPS, size of the data you're responsible for hosting, uptime requirements, real-time requirements, write load vs read load.

Often the natural walk is "let's assume it's a low load, design for that, and then we'll get to higher load at the end". Other times, it's an actual systems-y problem they're facing as a company, and that they have a putative solution to compare your knowledge against.

But yeah it is generally really important to codify and at least state (if not explicitly clarify) your assumptions before recommending a solution.