While some problems undoubtedly require more up-front architecting, I find that most are better approached by doing as little of that as possible. Rather than thinking about designing a data model for the entire application your planning to build, start writing the simplest code you can to get your first feature working. Start with an acceptance test and drive everything else you need to do from there. Repeat for additional features, refactoring your previously completed features as necessary.
I’ve been in situations where I was forced to do what is known as “Big Up-Front Design” (BUFD) - drawing massive entity relationship diagrams, documenting all requirements - and it has always turned out to be a waste of time. The features you are assuming you want you end up not wanting, or you get into implementing a feature and realize the design is totally busted.
I can’t put a ratio out there for you other than to say, “as little as possible.” I often struggle with this as well - when I start an application my mind goes immediately to the database tables that will back it. When I step back and let the features drive the model, I generally end up happier with the result. It’s important not to lose sight of how the whole thing fits together (that’s the ‘refactor’ in ‘red/green/refactor’) but don’t spend a ton of time sweating it up front.