I start with pen and paper or a whiteboard for the initial sketches. Review them with the team and when we get to something a bit more defined I'll use omnigraffle or sketch to turn it into a digital wireframe. Another designer on my team uses Balsamiq for his wireframes.

If the flow is simple then I print out these papers and start sketching. I don't really spend much time on it, Just enough to make the flow clear.

If the project is complex, First I sketch out the basic flow then I use Axure to create High Fidelity Wireframes.

I've switched to using Balsamiq for wireframes. Previously I used Axure or Sketch but I hated wasted time creating detailed throw away deliverables. Balsamiq is super quick and easily understood by the developers I work with.

Always start with pen & paper.

For digital wireframes, I created a little Sketch-Library with the most common elements (Boxes& Buttons mostly) that gets the job done in most cases. It forces you to use very rudimentary elements and not get lost in details. Also, when working in teams, a consitent style is maintained, which can be changed easily via the master symbols.

Happy to share it, if anyone is interested.

So, I used to not wireframe at all actually. I was so quick at iterating through ideas that I'd just build in Sketch / PS / whatever tool was necessary.

I've since made quite a shift to wireframing quite often. I used Balsamiq for a while, but I actually don't like it very much, and I'll tell you why, but first, here's a bit of a backstory:

The company I currently work for creates analytics and insights products for consumer packaged goods companies, so as I'm sure you can guess, the products themselves are incredibly complex. There are a number of components that are reused x amount of times, and there are continual changes. It's easiest for me to wireframe in Sketch so that I'm able to control my library of nested symbols — even though we're currently living in lo-fi/wireframe land. It's just so much quicker than Balsamiq, plus, I can quickly and iteratively move into hi-fidelity mockups if necessary. It's just so much more efficient in my workflow.

At my company UX designers use Axure to prototype, UI use Sketch (some use Photoshop).

starting with small sketches like 3-4 per a4. I sketch small to force myself not to dive into details. After the sketches i mostly use adobe XD for wireframing, also because it had build in prototyping so i can test my wireframes with users or the client

Personally I use either pen and paper (but then I don't really share them or refine them digitally) or Sketch for more hi-fi versions. I also tried tools like Balsamiq in the past but always felt uncomfortable.

Unfortunately, I also made the experience that showing/testing wireframes often leads to confusion because it looks distracting. In cases like these I prefer having a ready-to-use UI set which I can quickly build interfaces with.

That really depends on what and who your wireframes are for. If you're building websites and have stakeholders, like me, my team has fully switched over to Adobe XD. You can wireframe and get a clickable prototype in front of your stakeholders very quickly for your early phases, then you can iterate over that same wireframe with higher fidelity as the design comes together. You can even take a prototype and generate a public-facing URL that you can share with others, and they can drop comments on it. XD functionality is somewhat early days still; their commenting features are nowhere near as streamlined as InVision, but you can push changes up to the same URL for iteration. XD served us well rebuilding wpengine.com, and I'm sticking with it moving forward.

I'll agree with other suggestions, also. I interact with my stakeholders in person, and a whiteboard or piece of paper is irreplaceable for ideating together during those brainstorming sessions.

This is what I do for larger/more complex projects: I start on paper or more likely on Notes, notepad or similar software. I create lists, each list is a page with core features and necessary copy (based on conversation, research, or business requirements).

This super rough list of requirements sets the basis for my initial wireframes (which are just boxes with each list written inside them, but I use Axure or Sketch bc it's easy to copy, paste, and move things around) which also show hierarchy (usually lines to other boxes or another list that says where the box could lead to). This relationship wireframe shows the relationships between all the pages of the site—this sets the basis for a rough site architecture. I then take a look all the feature requirements that exist across the boxes, like search, navigation, directions & hours open, sitemap links, etc. which I group into other boxes that would exist across the wireframe boxes (these are essentially your components, and usually end up as header, footer, nav bar, etc.).

What I now have is groups of features and their relationships, and I would now have the confidence to create more detailed wireframes

Hope that helps

Pen and paper usually. Or if its a complex flow, some basic blockframing (much better than wireframing) in Sketch and click through in invision. If it s a complex interaction, same deal except in principle or Flinto. Share them early to give people an idea.