I design the whole architecture in my head and then scramble to get it all written / drawn on paper before I lose it.
Once I've got rough notes / drawings on paper, I'll work through it trying to identify bottlenecks, and complex areas that requires deeper understanding, places where I'll need someone specific to work on something, places where things would be very business logic dependent, places where we might have many changes (usually in the business logic, so things needs to be very flexible there; if business doesn't know what they want, I'll take that into account and rather start dev-ing very flexible components in order to get feedback from them as the product is developed, this does however lead to wasted hours, but business gets to figure out what they want while you're showing them what can be done)
Then after several iterations of improvements, I'll start figuring out what the technical requirements would be to make the design work, write all of them down and start looking at which stack would be best for the job at hand based on my experience and based on the team's experience and start jotting these details on the notes. (example, we're expecting spikes of 200k requests per second, maybe Kafka would be a good candidate to handle that load or we could build our own, requirements are that we keep all logs outside the infrastructure, mmm, maybe writing logs directly to a queue and consuming them offline somewhere else could work, I think Kafka might be useful, we can use it in two places, we need to cater for so and so browser, meh, there goes Angular Dart for now, but maybe it's worth building a separate plain HTML UI with no JS just for the older browsers and a separate one for mobile / modern browsers .... etc)
Only after I've figured out most of the details will I present it - typically on a whiteboard. This is usually also a good time to work with the business side to run scenarios and make sure that you understood the business requirements correctly and this will also give them confidence that you're taking into account all the business requirements they want (although from experience, the business side hardly ever figures out what they want from the beginning, so having the business logic flexible is important - sometimes if the business requirements will be changing all the time, bringing BPMN in, is a good idea)
Then you start breaking the project up into smaller doable pieces, the very technical parts I do myself to make sure it's correct, the rest of the pieces can be farmed out to developers with requirements saying I'm sending you this via this channel in this format, this is what I'm expecting back with a user story so that they can figure out the rest of the use cases themselves.
The only tool I've used before was online diagram editors although paper just feels more natural to me and the few times I've had to deal with remote developers, I simply wrote the skeleton / blackbox of what I'm expecting and asked them to fill it in based on a list of requirements that they could write unit tests for and also tick off on a list.