"At any rate, when doing design, what are some of your processes around it? More specifically, how do you know when you've done enough, what processes do you follow?"
Actually, it starts before design.
Start with the inception of the project. You have two ways to define scope. All or Just Enough.
All is handy because it sets a broad, distant, probably unreachable goal. But, it also sets out a cost and schedule that's vast, huge and has a lot of zeros in the price.
Just Enough is uncomfortable because it looks like you've put the target laser dot on a single micro-problem and you'll never build something scalable, comprehensive and blah blah blah. Just Enough has the advantage of setting and achievable goal followed by a trail of potential future goals that will likely come into play.
Advice: The Scope should be the smallest thing you can do and solve someone's problem. This is followed by future goals that come into play, later.
When you gather requirements, you have two approaches: All and Just Enough.
All is handy because it allows you to cover your @$$ and start endless arguments over what and what's not required.
Just Enough is scary because you gather detailed requirements for the first goal only, and set the other requirements aside for later consideration. Some people feel that every little brain fart is "required". Other people are more enlightened and realize that there's a MoSCoW spectrum (Must, Should, Could, Won't).
Advice: Aggressively and constantly prioritize all requirements. Work with everyone involved to realize that "later" doesn't mean "never". Create a formal backlog, and prioritize it constantly. Meet with the users as often as they have a question, comment or brain fart and let the adjust the priorities. They love that stuff.
And it allows you to plan the high priority items. You can then draw some "done" lines through the backlog showing how much will be done by a given date and how much will be done for a given amount of money.
When you get to design, you can look at the future requirements for possible future growth directions. But you don't have to overdesign everything to meet all of the things called "requirements" (many of which aren't even required.)
By the time you get to design, the Agility of the project will already be in force.