This is the third post in a series, preceded by Don’t call it a code handoff – user stories and Don’t call it a handoff – design styleguide. While preparing for my talk in a week or so, I’m breaking it down into parts and doing some thinking in public.
Figma can bring designers and developers together
With an iterative and cyclical process, designers and developers can design collectively. A designer understands code and how the system works, and the developer assists the designer with that understanding, and contributes functional ideas based on the user stories coming through.
Developers care just as much as designers.
Figma is the source of a lot of discussion and I want to make it clear that while it’s a great tool, I’m not married to it. With experience you start to realise that the latest and greatest soon becomes the also-ran. There are already cheaper tools that do what Figma does and more.
The important thing is the collaboration.
It starts with user stories
Craft user stories that are relatable, that way empathy and understanding can happen. Is the user highly technical? Then you can get away with a bit more than you can other user types. In any event, speak the language of the user. Are they a doctor or a retiree? Much different languages.
User stories determine the screen flow too. What is simple and understandable for a Doctor is probably not for a Retiree and vice a versa.
Use Figma comments for conversations
Often we’re working out of sync, so meetings are important, and also comments on designs are super important to give more context. It’s amazing how a small shift in mindset can alter the path of a design, and make it more understandable to everyone.
Cognitive bias cannot survive the onslaught of information and empathy.
Is Figma’s Dev mode up to the task?
Dev mode sounds amazing, and it is very promising, but I’ve yet to work on a project where it was implemented. I assume it’s most useful in a large project at a big company where keeping everything in sync is important.
For small teams, designers and developers work with a front end framework which usually comes with an accompanying Figma design system.
Ideally the design is the result of conversations
In this series I’ve been saying “don’t call it a handoff” to emphasise how important it is to have constant communication rather than one blast. One blast leaves a lot to chance, meaning a full stop until the designs can be better explained.
Some things to make sure you understand as a Designer when discussing designs:
- Is your application an SPA (Single Page Applicaiton)?
- How does validation work?
- How do the API’s work and have they been designed?
- Does everyone understand the goal?
- Does the design in Figma match the coded design system? Don’t make up new controls, colours, or interactions without discussing them first.