If test cases are time-consuming and not always relevant you could replace them with more flexible alternatives like session charters, risk catalogues, checklists, and the like.
That way you don’t have to try to make your wishes explicit in a communication document that may or may not be relevant now or in the future to another tester in the hope that their interpretation of the document is useful or accurate.
If you replace test steps with things like desired coverage, and give purpose and reasons in the documentation instead of instructions, then QAs can learn the product through exploration and experimentation, and their feedback can help adapt and improve your charters. They can formulate and ask questions to fill in the gaps in their individual knowledge, and the experience they gain can be used to better evaluate and test the product in the future.
That should deal with both questions - better allocation of time, and adaptive product learning. I’m happy to answer any questions you may have about my perspective on this.
More Reading
I’ve written about this before, in case you have a dull afternoon to fill.