As an amateur designer, one of the early hurdles that I had to get over is to decide when to present my prototype for feedback. Fortunately, I've had quite a bit of practice in how to look at this problem elsewhere in life. You see, my day job is to build software for startups and getting products ready for early feedback and validation is everything.
In the tech startup world, the metaphoric line is called an MVP (minimal viable product). The idea is simple: you make something that is good enough to deliver the core values and user experience, and you showcase it to people as early as possible to make sure that your assumptions are still on the right track.
Once you have a list of all the features you want in a project, you can draw the MVP line by separating the "what is critical to build" items from the "what would be really nice to have" pile. I know I am oversimplifying things here, but I think you get the gist of the process.
With board games, this MVP concept is harder to achieve because board games focus more on delivering experiences than functional goals. That is not to say though, there isn't a way to come up with some sort of general guideline. Here's my checklist:
Check the Game Math
Before I show my game to anyone, I always first try to make sure that there isn't an easy way for the game to "blow up" in ways that winners can "run away from the rest" when they are winning. This is especially true if the game has significant probability or engine building elements. I will write a separate post on the different ways I check on this.
Complete Core Gameplay Loop
I go through, as much as possible, the different actions/options players have on their turn and make sure that I have the adequate UI elements on game components to clearly identify what those things are. Even at the prototype stage, I shouldn't have to make things up on the fly when players have questions. Of course, there will be exceptions as it is impossible to anticipate every outcome, but I try to be as prepared as possible.
Write The Rulebook
I have to admit that I don't always do this. But I feel much better whenever I do. I find that a lot of "debugging" happens when I have to teach the game rules. But if writing seems too tedious to you, you can also try to teach the game to imaginary players before you head out there. Better yet, you can rate yourself as if you are one of the players.
Find Key Aesthetic Anchors
This is optional, but I think is important unless your game is purely abstract in nature. I've often found players to be much more immersed if there is artwork to help carry them into my world. I often borrow (and never sell with) art that I find online as a player aid.
Like any product development, making a board game is a very iterative process. And once I have a base to work with, it'd be now much easier to tweak things and improve the game experience. But if I present the game before it's baked enough, I wouldn't know if playtesters are struggling with the mechanics/game economics or with unclear rules.
Just as important as getting games ready for feedback, it's critical to capture the right information from the playtesters. Knowing how to filter feedback is somewhat of an art form all on its own as not every opinion is going to weigh equally. But that's another topic for another post.