Design reviews work best when the author is explicit about the decision that needs feedback.

Useful review requests usually include:

• The system goal and the main constraints
• The block diagram or relevant schematic excerpt
• The interfaces, loads, rails, or timing targets involved
• The tradeoff you are unsure about
• The risk you are most worried about before tape-out, fab, or release

If you want broad reactions, say that. If you want a hard critique of one subsystem, say that instead. Review quality improves when the request is scoped honestly.