One of the things I enjoy doing and lecturing in my classes is about how designers can positively help their organizations change. I think at times some new designers working at organizations think they can only help through their design skills (visual, interaction, prototyping, etc.) but there are a lot of other ways designers can help make an impact at their organizations other than just designing things. One of the things a designer can do is to help the team pick the right design tool which has several different impacts to the organization.
A previous student emailed me today and asked for advice on how they can get their company to stop using a very outdated design tool and to help them to start using Figma. They mentioned how their director wasn’t really open to that change and they asked for advice on how they can address that situation. To me changing their main design tool isn’t just about the design tool or an impact to their designers. To me it’s a change to how the company collaborates across different disciplines, positive benefits through the improved productivity of the team, the consolidation of design tools thanks to Figma’s awesome features which could help save the company money, and other ways this can help the organization.
I have experience moving design teams to use different tools at various companies I have worked at so I have some thoughts here. At Google I moved our team from Adobe Illustrator to Sketch. At Sunrun I moved our team from Sketch to Figma. At Pivotal I moved our team from Sketch to Figma so I have some experience on how to handle the situation my student asked me about. The following is what I would do to help this company adopt a new design tool.
Note: I am only speaking about how I helped my direct product teams move to different tools, some of the companies I worked at have several design teams which I had no direct impact on what other tools teams used.
Getting buy-in from the designers
Since this design tool would be primarily used by the designers, I would first demo the tool to other designers and explain how this tool can help them.
What I would do is pick your favorite and most used features and demo to the team on how you utilize Figma in your design work. I would also prepare and share a list of features you typically don’t use because these features might be utilized by other designers on your team.
I would also prepare a list of resources (articles, videos) and have this ready because chances are the designers on your team will be impressed by Figma and will want to learn more. It also could be helpful to get a list of things they want to learn more about and host another workshop to go over those things.
Getting buy-in from other disciplines
I would demo this tool to other disciplines such as product managers and software developers and explain to them how they could benefit from this tool. For example for product managers I might show them how they can easily attach a Figma link to their project management tool without having to export designs as a PNG. Perhaps your product managers want to mockup some wireframes or utilize the design system to ideate some hi-fidelity flows. For software developers I might show them how they can easily reference the production ready designs by going to Figma and inspect elements to start building instead of having to send messages or emails asking about the smaller details. Another thing that might interest software developers is to show them Figma’s plugin API and how potentially you can collaborate with them on building Figma plugins to help the team with your specific use cases.
Another way to approach this is to talk to other disciplines on your team and ask what types of needs, goals and use cases they have in their workflow and see how Figma can help.
Improving team productivity
I would also showcase an example journey on how the team can improve their productivity. Something I might show is how multiple designers can work from the same file through the collaboration features, then showing how different team members can view the designs and leave comments (this would make more sense during a structured design critique), and how developers can inspect production ready designs to start building things. Compared to the past where people would have to export designs, send an email with various attachments, have feedback in various emails and documents, having a lot of back and forth between questions around the visual design such as color and shadow properties, software engineers could potentially work from outdated designs, and other reasons.This alone can show the benefits of improving productivity of the team.
Consolidation of design tools
Historically before Figma, I noticed many teams would use a separate tool for designing, prototyping, a repository to host the designs for the team to reference, and other tools for specific use cases. In my opinion Figma handles all these things and more very well. You can even make the case that Figma can help save the company money and this goes back to the previous point where the consolidation of design tools can help the team’s productivity. Imagine having to go several different tools to see the iterations, the prototypes and the latest designs. To me it makes sense to consolidate these thing into one tool.
Share case studies on how other companies benefitted from changing tools
I would also share with the team on how other companies benefitted from using Figma as their primary design tool. I would take a look at case studies other companies have published and speak to other designers on those teams and ask about their experience moving over to Figma and ways they benefitted and lessons learned. I would bring these learnings back to your team.
These are just some ways I would help convince an organization to use a different design tool. What are some things you would do? I would love to learn more about how you would handle this. Please reach out to me on Twitter