Like many things, this can be a matter of preference, but here's the rules of thumb I try to follow when writing challenges, and the things I appreciate when playing challenges.
* Avoid intentional red herrings, full stop. Your players have a limited amount of time in their lives, and a limited amount of time in your game. If you've got a plausible-looking path of investigation which actually serves to intentionally waste their time, it's super frustrating.
* Keep your challenge as focused as is reasonable. This avoids wasting your participants' time, as above. This also gets across the flavor or educational content of your challenge more effectively. Also, this does a lot to help prevent unintentional shortcuts around the intended solution.
* Make it unambiguous and obvious when a challenge has been solved. While not appropriate for all types of CTF, in CTFs I've run, we try to use ascii-based keys that have content related to the theme/solution. For example, a session-hijacking challenge might reward you with the flag "c00kies_r_d3licous". That said, some CTFs use randomly generated hexadecimal strings of a specific length, for rotating flags. Whatever you do, it's important to remain _consistent_ across all your CTF's challenges.
* Avoid "guess what the author was thinking" in your challenges. For example, if you use a freely available but obscure steganography program to hide a message in an image, using a 1-word dictionary password, you might think it's a relatively simple challenge, but your participants won't even know where to start. If they guess that what you were thinking was "stenography with a simple password", they'll likely have no more direct course to solving it than "download a bunch of stego programs, and brute-force <program,password> combinations". And, they have no real _reason_ to believe that's the correct course, as opposed to all kinds of other avenues of investigation.
* As specific examples of the above, I'd recommend basically never doing a cryptography challenge, without giving the participants an implementation of the cryptosystem, whether in source code or binary format. Similarly, most exploitation challenges should give out either source, binary, or both.
* Similarly, if you do a multi-stage challenge, it's helpful to make it clear when one stage is solved. In some cases, I've given a separate flag to each stage of the multi-stage challenge, so lesser-skilled teams can still score partial credit.
* Have a clear idea of which skill or piece of knowledge the challenge is testing for or educating about. In my opinion, some of the most fun and memorable challenges are ones in which I independently rediscover a well-known class of vulnerability, or CS concept.
* Playtest! Get at least one team member to try out your challenge, give you commentary on what they're thinking and investigating, and see if they solve it, how long it takes, and what they run into. Try not to give hints, except where it's reasonable to unstick and expedite the playtest process.
* Play in CTFs! Pay attention to what creates joy or frustration in you while you play.
For context, the CTFs I've run have been more focused on creating an enjoyable experience for a wide range of skill levels, from newbie to pro, rather than high-level, cutting edge competition. Both are entirely valid realms, and there's likely other interesting focuses for CTFs as well - just understand what you want the emphasis of your CTF to be. Depending on your focus, you might want to do the _opposite_ of some of this advice. But, I'd recommend being aware of these points, and intentionally choosing which direction you want to go.
Hope that helps.