You don't need to just get better at game design. You need to get more efficient at it.
Gaming is an experience, and players/publishers can't experience it properly if it looks terrible.
The game should be neat. This means it's simple, clear, and not ugly.
Such a game also appears like a blank canvas to a publisher. It's not so bad it's off-putting, but not so good that you might want to force them to keep your design.
Your layout (of cards and other objects) should just be flat areas of muted colour, with text on top of it. It's simple and functional.
Don't use textures, bevels, gradients, realistic shadows, or other embellishments.
The best design is design done by a professional. The second-best design is no design at all, which is what you should do.
In the same way, icons should just be simple, flat-colour shapes. Just go and get free, basic icons from Noun Project. Make better ones later, if you're good with graphic design.
Spend some time trying out a few different fonts. Thoughtful font selection is a very easy way to make your game look good. Do not use standard body fonts like Arial.
Go watch a few videos about basic graphic design.
Absolutely do not commission or compose artwork. This is unusual for a prototype. A publisher will want to throw it all away, and assume that you might not agree to that. A design that looks too complete can easily be a negative. This is an extremely common beginner mistake.
Use art from DeviantArt or Google Images. If you're just playtesting, no one will ever know or care that you've used their art as a temporary placeholder. Freepik is great, as are A.I. image generators. Dall E is the easiest to use, in my experience.
Do not present people with text-only game components. They want to know which card the dragon is, without having to read each card.
The best way to make your artwork look terrible is to use inconsistent styles.
For fantasy or sci-fi, there's enough art available, but for almost anything real-world, I like to use vectors. These are simple, flat-colour illustrations. They give a consistent feel, they're easily editable, and they can be scaled infinitely. Even when using an A.I. art generator, I ask for this style.
All the above only applies to completed prototypes. For a first prototype, do not spend any more than the absolute minimum amount of time on the layout. It can be hard to resist, I know.
My first prototypes look very basic, and unappealing. They're usually just a bunch of pastel-coloured cards (so I can put black text on it), with a title, some quick text, and primitive artwork.
You're going to be playing this game for ten minutes.
If a game survives its first playtest, I begin gradually upgrading the visual appearance, with each revision. The game ends up neat and presentable, with nice icons, appropriate art, and good typography.
Always remember that your game will undergo more changes than you think, so never bother making things perfect. Your next revision will not be the last, and even some of the things you made nice designs for will eventually go.
I strongly suggest making your game cards in a word processor, rather than a graphics program like Photoshop. Dealing with positioning things, and hundreds of layers, is mind-boggling. One of the many little problems you'll run into is trying to put icons in the middle of text.
If you have a desktop publisher, that's far better. I use Affinity Publisher, and it's excellent for boards as well as cards. Each page can be a card, so you're not trying to cut up a larger image into cards, nor do you need dozens of separate files. I now put almost everything into one big file, except large boards. This means all tokens, cards, and resources. It's much easier.
Each time I do a revision, I make another copy of the entire game folder, and number it (001 etc.) I keep every revision of my games, as I often want to recover an old component, see how I did things, or even revert the whole game to a previous state. A publisher actually asked me to revert to a previous version of my game.
For a long time, I kept excellent notes, containing:
The results of my playtests, and my thoughts on the revision.
Changes to the rules.
Changes to components.
However, after many years of doing this, I've come to the conclusion that it's mostly not worthwhile.
Writing a changelog has been useful in the few projects I've done where other people have been involved. The rest of the time, I was writing notes that would be unlikely to ever be looked at again.
Changes to components are recorded anyway, as I retain a copy of every version of the game.
What has been useful has been keeping track of the rules. A simple rules card is ideal for playtesters, but it's also essential for when I take a break from a game, and return to it.
I do take notes as I playtest, both during the game, and when I discuss with the playtester afterwards. These are discarded as I enact them, later.
Do quick, small revisions. Just fix one thing at a time. Big revisions are a slog.
As with the design itself, you should upgrade your software and systems, as your game design career progresses.
If you're serious about game design, you should be aiming to do one revision a day. That means you'll need enough playtesters to support that. If you're busy some days, you should be doing one revision per free day. A game will likely take more than a hundred revisions. One revision a week means one game will take two years.
At the start of your career, you'll be plodding along, and wasting time in all kinds of ways. If/when you're successful, you'll be efficiently speeding through important work.