I think it depends a lot on your team. Every organization is different, especially small ones. Your question of how abstract should your guidance be is a good one, but has nothing to do with diagrams, and is literally "how abstract should my guidance be". You could theoretically micromanage every class and line of code. But typically someone leading from the top would simply provide a list of business requirements and the more technical people below you will figure out how to implement those. In a case like that you might provide your requirements as a a bullet point list, or UML Use-Case diagrams, or something else. If there was a manager between you and the coders, maybe that manager would flesh out technical details and produce lower-level design artifacts like swim lane diagrams etc.
So, are there other more skilled developers working under you? If it's basically you, a "mediocre developer", and a handful of underlings who are even less skilled than you, to the point that you feel like you can't trust them to design things better than you can, your business is going to be in trouble. Software businesses cannot succeed with a single "mediocre" mind. You need really smart people who have good skills. Either that's you, or you have to hire someone to delegate that thinking to. I don't want to beat you up, but to say "I'm a mediocre developer, so I decided to read some about architecture and do that", rings to me like someone saying "I made a birdhouse that was ok-ish, so I'm trying my hand at making blueprints for a water treatment plant".
Architecture is Hard, it is the culmination of abstract, hard-knock lessons gained over the years by very weathered developers. It involves:
- forseeing the technical snags a lesser programmer would not see, and handling them ahead of time in the design
- having a broad knowledge/experience with different patterns of structuring code and system components that preclude problems of scale/maintenance/coupling/reliability/deployment
- having wisdom (from experience) of making compromises in the otherwise "rules of design" and being confident in your Judgement of the balance of those compromises (what are they weighing against, what are the risks, etc)
Bad architecture means that the product will always be on fire, requiring constant shenanigans to keep it running, new code won't "fit" and will require papering over the intended architecture to get things done, devolving into chaos with the whole thing gradually becoming a structure of bandaids. It must be completely re-architected soon, once it crashes into the realities that an experienced developer/architect would have been an guard against. Rather than thinking architecture-first, you might consider a less formal approach of rapid prototyping each small functionality, and then stitching it all together after the fact. Creating a defacto architecture at the end. This is better than investing a bunch of personal resources into a (no offense) doomed-from-the-start dunning-kruger architecture. Excuse me for presuming your architecture will be Bad from the start (I don't know you so it's not personal), but that is my expectation from what you have said that you are taking this on yourself rather than delegating it (what a CEO does) to more skilled people I'm guessing you don't have on your team. In which case you would be better off having no pre-ordained architecture to fight against until you have some functional pieces in place, which you can then look at and determine how best to build some scaffolding for.
In fact I would advocate generally to be as flexible as possible, give your developers the requirements and let them test their mettle. They need to go through the crucible and develop skills. Let them fail at first and iterate on what they come up with. Have design meetings (you can participate), and a code review process, track the progress of component creation so it doesn't drag on forever and re-assess the roadmap frequently.
All of that said, I think UML can be great and is under used. There was a time when it was used very formally and that has fallen away, but it still stands as a pre-considered way of making many types of visual aids that are relatively easy to understand. These are helpful for having everyone on the same mental page about the target you are aiming at. My point is to say if you do go the UML route, don't be overly obsessed with "proper" UML. Just use whichever diagram types are useful to you for communicating a particular idea that needs clarity. And if you use the wrong type of arrow don't worry about it. It's just better than starting from scratch in terms of "how do I make a diagram that shows this".