Unlike coding interviews which are much more common and you can somewhat practice/simulate interview conditions, it is much harder to practice for system design interviews.
Here's a list of common mistakes made by candidates when they are answering system design interview questions and many of them are not specific to front end system design interviews. Hopefully you will remember these points and avoid them for your own interviews.
Don't jump into answering the question immediately! Take the time to gather requirements and clarify assumptions by asking questions. Answering the wrong question well is worse than answering the right question poorly.
Because system design interviews are very open-ended with no explicit completion milestone (unlike coding interviews where you have to produce working code), some candidates might just talk about whatever that comes to their mind and the answer might end up appearing messy to the interviewer. Use the RADIO framework to help you.
Write down each step of the RADIO framework on the whiteboard at the start of the interview and ensure that by the end of the interview you have covered each section sufficiently. Note that you don't necessarily have to complete each section in order and you can always revisit previous sections if you've missed out on certain things.
Don't insist there's only one solution, especially if the interviewer prompts you for alternative approaches. More often than not, there are multiple ways to solve a problem, each with its own tradeoffs.
The interviewer wants to see you identify a solution with the right tradeoffs for the issue at hand, not you saying that there's only one right or best solution. The other solutions might be clearly bad and is very obvious to you, but the interviewer needs to hear you explain why they are bad.
On the opposite of the spectrum of answering too quickly, we have people who remain silent. Don't remain silent the entire time and thinking only in your head. Think out loud! System design interviews are meant to be collaborative exercises between you and the interviewer. Treat your interviewer as a coworker, bring up issues you've identified, bounce ideas, and discuss possible solutions with them.
Don't go down a rabbit hole of diving too deep into a particular component. Come up with the architecture/high-level design first, then proceed to the various parts of the system. Focus on the parts which are most important to the problem.
If you are unsure, ask the interviewer if you should dive deeper into a specific component. It'd be bad to spend too much time discussing about an unimportant component, wasting precious time without providing useful signal to the interviewer.
Don't use buzzwords or terms you can't explain well. It might be tempting to throw out some cool terms like "Virtual DOM", "DOM Reconciliation", "Partial Hydration", "Streaming Server-side Rendering" and you can if they're relevant to the current topic!
However, if you do, make sure you are able to explain the term you just used as your interviewer is likely going to probe for more information to test your knowledge. It's a red flag if you are unable to explain the term you just used.