Yesterday I ended with the question: Does it always make sense to do Lean UX, and implement straight from wireframes?

Day 3 of #NaBloPoMo

Because it's true, at one extreme, if you do too much Figma it can look like this:

I've worked on teams where the batch size was large, and the designs were polished to completion before developers even look at them. Usually these norms are ingrained in the company's work culture, and perpetuated through org chart, rituals, planning and hiring.

There's a big delusion behind this behaviour: that the correct design is knowable without building anything. Often, it's not. Delaying building is delaying design, because building helps you find the right design.

So what do we do instead?

Figma, when used the right way, can help you go faster, not slower. It's a question of batch size, polish, and paralellism.

  • Batch size: How much stuff you design before writing code
  • Polish: How much design detail you put into each thing before writing code
  • Parallelism: Whether development starts before or after the design is finished, and how early

So don't terminate your Figma licence just yet… An ideal way to use hi-fi Figma is on a just-in-time and just-enough basis:

  • Just in time: When a development question arises that can be most quickly explored and answered in Figma, now's the time, e.g. “What's the best layout of this section?”, “This page is starting to look messy”, “What are all the states of this button?”.
  • Just enough: Not trying to anticipate too many questions at once, especially if development could have got started already without this information.

That doesn't mean you'll never put together a holistic picture at a high fidelity. You'll do that just in time and just enough. Let's say you want to excite an investor by making a hi-fi mockup of a few screens? Go ahead! But do just enough for that purpose.

The path to recovery

So what makes it easier to break the Figma addiction?

  • Ensure the work is well-discovered and well-shaped — We're just talking avoiding polishing too much in Figma, not bypassing discovery and shaping. The sketches you do still need to be based on good research and a solid conceptual model, otherwise you're probably setting off in the wrong direction.

  • Ensure designers are working in sync with developers - Once discovery is done and it's time to get more detailed, ensure both a designer and developer are fully focussed on the same thing at the same time. This will help avoid developers feeling stuck. The designer is always available to pair, or to pick up some just-in-time Figma work. You could even take the Basecamp approach and hire designers who also write code so they can help out developers directly.

  • Stop developers fearing rework - If developers say they only want to start coding when the design is finished, help them see how much value they can add by starting to build and helping find the right design together.

  • Stop designers fearing low quality - It's common for designers to worry that if they don't give developers a perfect design, it won't look good and they'll have to live with a poor solution forever. Make sure you really do iterate on things to prove to designers that it's not the last chance. And make sure designers understand that quality is a tradeoff against speed, and not every experiment needs to be high quality in all directions.

When it's OK to invest in hi-fi

There are times when it makes sense to invest in hi-fi. If your prime uncertainty and risk is more about how it should look, rather than how it should work, then it makes sense to use Figma for what it's great at - fast exploration of many visual alternatives. For instance: The layout of a marketing page, or coming up with a new typographic hierarchy, or when there's a benefit to creating something exciting and pushing boundaries, as @helentran says well:

But still don't delay development

Even if you do that, don't use that as a reason to delay development. You can start development in parallel and evolve the two together, ending up with an even better design.

But if you're not pushing boundaries — and in many products it's not necessary, and may even be harmful — do yourself a favour and get to code as soon as possible.