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.

Pen & paper

I started, and now we do sketch the UI but only two scenes; the main screen with some notes on it about behavior and possible paths to other screens and a screen of choice. Showing them in a video session or onsite face-2-face to gather some meta feedback; meta feedback such as beautiful UI or huge feature list? Feature-set completeness or due dates? Time or money?

Together we write down a wishlist, a list of thoughts, expectations, and wishes. Getting answers the questions like "How will this software looks like in the year 3000?". It's an overthought massively overdrawn picture of something that will never come to live. But we try to remove all borders and limits to allow each developing ideas for the future ready to be used tomorrow. Our customers quickly jump on the bandwagon and sketch some ideas about how many users, how to access data, what shall be automated, etc. , etc.

Tools We put everything into Confluence and Jira by converting handwritings into digital paperwork. Yes, at the end we do software development the Atlassian way. But it turned out it is the simplest way to connect with all peoples involved into the process.

We tried Enterprise Architect for a couple of weeks but failed to get something out of it. A high price tag for this learning lesson.

Architecture We stripped down each point of the wishlist into a traceable item in Jira and Confluence. We meet with our customer and negotiate about prioritization of each item aka feature or feature set. After the prioritization, we talk about milestones, due dates, and costs. By talking about time (implementation and future usage) and costs, we decide about the tech stack. The customer decides indirectly by agreeing on our rough time and cost plan. With the tech stack given, we plan to draw a picture of data flows, state and state changes. We translate it into a Confluence diagram and share it with the team.

---

From UI over resources to the architecture. We do this because we can't tell our customers that something is impossible because the chosen tech stack or parts of it doesn't allow us to implement certain features.​

There's already great answers there from @JanVladimirMostert and @fibric , hence I'm not going to repeat everything. But I'm surprise the classic whiteboard is mentioned only once. Like Jna, most of the time it's a "in the head+paper" drafts, but it then very quickly move to the whiteboard, even before using it to share the ideas, but because of the ease of erase/redraw and how quick it is to setup things on a whiteboard. Usually, once we have a rough idea, we start talking with other engineers (no big meeting, just a dialog with another guy to challenge the ideas). And that's where the whiteboard is really helpful, because it's a great support to explore the different challenges.

For the second part of @sandeep 's original question: how to work remotely, in the past (as of today I'm no longer working with remote teams that much) we make intensive work of Confluence - for storing and text - and Visual Paradigm for the diagrams. Visual Paradigm - once you're used to it - make diagram creation really a quick task, so we had some screen-sharing conference with live discussions and edition of the diagram. If you want to give it a shot, I believe the Community edition (free for non-commercial purpose only) is still available, it could help you see how it could fit your need.
For simpler diagrams, Lucidchart was enough and does the job well.

For architecting, I don't use paper because it is not maintainable, but I use LucidChart and C4 models which I found more convenient. I wrote this post some days ago about that. It's easier to create, communicate, collaborate and maintain.

For business processes, I use Camunda BPMN modeler, which is pretty simple yet useful and free. For wireframes, I use Pencil Project.