Without fail, in spring of every year, the discussion around low fidelity vs high fidelity design makes a comeback. Both sides make very good points: low fidelity allows the designers to make more quick, rough sketches and test them more rapidly, therefore it's higher up the value chain, meanwhile high fidelity is easier to test because it looks like a real interface so when you prototype you can suspend disbelief and pretend this is a real product.

Arguably, both sides are right. As someone who works in a distributed team, where not just our stakeholders and users but also our teams are spread around the world, I lived through this argument over and over again and realized that the question isn't "low fidelity" vs "high fidelity" – rather, it's a balancing exercise.

How fast can you learn?

Sometimes it's easier to get all possible ideas and iterations on paper, sometimes on a whiteboard, and sometimes in a FigJam board. The question isn't which one is the best – the question is which one will allow you to learn the most in the shortest possible time span?

The questions to answer are:

1. What is the most efficient way to get ideas out of my head and onto something that I can get feedback on?
2. What is the easiest way for the audience to understand and provide feedback on those ideas?

In our case, we generally don't do traditional wireframing at all – we found that the cost outweighs the value, especially in the age of mature design systems. Our Figma Library is custom-built in a way that optimizes for speed and usability – once you get used to using it, the goal is to be able to churn lots of ideas relatively quickly, even if they're mid- or high fidelity. We still do and share very rough sketches, photos of whiteboards, and other low fidelity artifacts of the process – and then, we generally jump into Figma and Origami, because this allows us to test the work with distributed users and stakeholders while allowing us to still move relatively fast.

Every larger internal share – e.g. to the entirety of the Product Team, or even people who are hanging out in our public Product Team channel – tends to come with a long description and a Loom video in which the designer goes through the prototype explaining how it could work, limitations, framing, and questions we're looking to answer. For user testing, we use Maze. Or Figma. Or we sit on a call with the user using the live, mocked version. The goal is to get to value as quickly as possible. What you're doing in this situation as a designer is designing the feedback process, remembering who your audience is, and figuring out the tools to learn as much as you can as quickly as possible.

The tools don't matter. The methods don't matter. Outcomes do.