‘The Figma’

What is Figma?

Just in case you don’t know. Or have been working with wonderful designers who build low-fi prototypes as a platform to collaborate deeply with development teams, iterating and experimenting to delight their customers. Figma is a web-based design tool that allows users to create, share, and test designs for websites, mobile apps, and other digital products. It’s a popular tool for designers, product managers, writers, and developers. You probably can delight your customers with it, I’ve just never seen that happen.

The Anti-Figma Brigade

Let’s be clear, I’m not anti-Figma. It’s an extremely rich platform for designing applications. In fact, the richer it becomes the worse the collaboration gets. This is from experience at the last few places I have worked, with masses of designs with no discernible starting point, causing development teams to freeze in horror and wonder how they are going to cope. However I don’t want this to be all doom and gloom, so here’s some unsolicited advice.

Do

  • Design as a team, just in time – seriously, the amount of Figma files in a resting state waiting to get built is enormous. Like any other backlog, clean it out, keep it lean, and focused on what you are about to build.
  • Create the key journey in Figma and let the whole team work out the rest, designers, product, developers etc. This is just like Card, Conversation, Confirmation right? We use a Figma design to start a conversation, then we work out how to test it.
  • Have a designer on the team – not Figma specific but teams should have everything they need to succeed. Poor designers need to context switch all the time, I feel for them.
  • Look at what’s been built, as well as ‘The Figma’ – maintain a link with the reality of the product as built, rather than finishing your input at ‘The Figma.’

Don’t

  • Give in to the temptation to run off and squirrel away with designs, trying to stay ahead of the development team. Repeat after me, designers are part of the team, not done to the team.
  • Figma designs look ‘done’ to some eyes – which means no estimate can ever be good enough. Just implement ‘The Figma.’ Stakeholders see ultra high fidelity designs and think it’s only a short hop to working software.
  • Copy and paste – It’s tempting to add more and more, once you have a first iteration. Then the designs start to fall behind as it’s hard to keep it all in sync for even minor changes.
  • It’s never the simplest thing that works – you have to reverse engineer the designs to find the simplest thing that works, which takes ages. I have had to do this so many times with teams that use Figma in unimplementable quantities.
  • Use them to completely replace user stories/examples/low fidelity prototypes. Designs are only one way of expressing customers needs and problems to be solved, don’t ignore other excellent ways of doing this.
  • Development teams believe they are complete too. Failure flows or (especially on mobile apps) partially completed journeys you have to endlessly argue for, as we know they will happen but ‘The Figma’ will struggle to express this.

If it was a requirements list or any other backlog everyone would be stroking their chins and saying thoughtful things like ‘we will never get to half this stuff’ and ‘there is too much work in progress.’ But instead, we sit in stunned silence for a while, then spend months picking a starting point.

Use Figma, but carefully, as you would any other tool. Start conversations with it, rather than ending them.

Links

https://www.figma.com/
https://nohandoff.org/why-i-dont-use-figma/