We spend so much of our time learning and using tools. Whether it’s file storage and project management or text editors and chat, tools can make or break our workflows.
If they’re not well-suited to your team, tools can cause a host of issues: draft conflicts, inconsistent designs, and a general breakdown in collaboration. While they exist to simplify the way we work, the wrong tools can end up making things messy and complex.
To find the right fit, it’s not just about reading countless articles and reviews to identify the “best in class” option. Rather, there are a number of considerations—team size, distribution, workflow—that should inform the decision. Below we’ve outlined a framework, based on what we’ve heard from our users.
Here’s a quick look at what we'll cover:
While it can be tempting to start comparing features right away, remember that this is something you and your team will be using on a daily basis; doing the upfront work to thoughtfully evaluate different tools will save you time and money down the line.
Try to treat it as you would a product launch or design sprint, and build it into the team’s quarterly plan. The Intercom team shared their philosophy: “Depending on the size of your design team, you may not be able to flip a switch and head over to new software immediately. The more complex your org is, the more important it is to pick the right approach. We tackled the problem in the same way as any other work project, which helped to ensure everything is thought through well.”
Make space for the process in whichever project management tool you use, and build a workback schedule based on your team’s other priorities. It may depend on the size of your organization, but prepare for it to take roughly a month (two weeks of prep and a two-week sprint to try it out on a couple short-term projects). The Intercom team also found that it’s helpful to set a hard deadline—if it’s clear that one tool rises above the rest within a month, then you don’t need to complete the rest of the evaluation process.
Before you start, it’s important to chat with your team, cross-functional partners, and project approvers about the process. Of course you want to find the right tool for your immediate group, but there are other partner teams to consider as well. Think about the different projects that your team’s involved with, write down a list of others who might be impacted, and make sure to connect with them before kicking off the process.
Lyft put together an Advocates Program, made up of a cross-functional team to help with both the selection and implementation of their design tool. The group had a 30-minute, bi-weekly check-in and a dedicated channel in Slack, and encouraged people across teams to get in touch if they had feedback or questions about the design tools they were evaluating.
While it’s important to have an evaluation criteria—more on that below!—a large part of the decision will come down to how it plugs into your team’s workflow. Beyond keeping track of milestones and formal feedback from other groups, create a shared document where team members can write their off-the-cuff thoughts on what it’s like to use the tool in practice. Kick things off with this Figma file, which has some prompts to get the conversation going.
Keep in mind that implementing a new tool often requires an adjustment period. Communicate with your stakeholders and let them know that once you’re in the implementation phase, your team may need a few weeks of ramp time before they’re operating at full speed again.
If you’re considering a new tool, you likely have some contenders in mind. Before you throw around names of specific tools, sit down with your team and make sure you’re clear on what you’re really solving for.
Think about the characteristics of your immediate group. How big is the team? Is it growing quickly? Are they all in one office, or do some work remotely? Based on the answers to the above, you’ll be able to figure out what matters most to you. For example, large teams may care more about consistency and scale (think shared libraries and design systems) than their smaller counterparts; if your team is growing quickly, remember that you’ll constantly be onboarding new people; in a remote workforce, collaboration and communication will likely be top of mind.
At this point, you already have a tool, and you have a good idea of what’s working and where there’s room for improvement. Have your team think about the painpoints they experience and ask them to write down the specific moments (e.g. developer handoff) where something breaks down. Get input from people outside of your direct group as well—product managers, developers, and marketers may all provide context that you otherwise wouldn’t consider. This Figma file is a good jumping off point.
Based on what you came up with above, decide on a handful of themes that are most important to you and your team. Here are some we’ve seen come up in conversations with our users:
Evaluating even one tool can take time, so it likely won’t make sense to test every solution on your radar. Try to keep the evaluation to 2-3 different tools that you think will each tell you something different.
Some features will be must-haves for your team, and that’s ok. If you’re looking to see how different tools stack up, the comparison charts from UX tools might be helpful. Beyond those non-negotiables, try not to prioritize sheer functionality. The decision should rarely come down to whether a tool does or does not offer a specific feature.
To get more context on the tools themselves, it’s often helpful to learn more about the companies that build them. Teresa Man, a designer at Superhuman, says that they looked out for a tool that “echoes how we think of product, design, and culture.” You can also read through company blogs and try to get a sense of their development strategy. Look for signs that the company ships features quickly and takes customer feedback to heart. Carousell, a recent Figma-convert, describes how they decided to make the switch only after Figma launched Auto Layout. In the decision-making process, the future roadmap of the tool can be more important than its current functionality.
You can read countless reviews, but the main thing is testing how it works for your team. You already have a list of painpoints that your current tool doesn’t solve (or maybe even causes). The goal with testing is to get as much signal as possible on whether the new solution addresses those painpoints, and to document any new points of friction that get introduced.
Based on the criteria you prioritize, it may be helpful to create a framework around it. Lyft broke theirs out into four areas: designing the work (i.e. design quality and extensibility), organizing the work (i.e. clarity and searchability), connecting the work (i.e. collaboration and portability), and quality of the tool (i.e. reliable and performant). From there, they created a table comparing the the tools they considered, marking each with red (no), yellow (not always), and green (yes).
When the Intercom team was considering a switch to Figma, two designers decided to test the tool on a few projects before getting feedback from other members of the team. Doing so allowed them to screen for any problems that would significantly impact the group’s collective workflow. They clarified that any new tool results in “inevitable moments of frustration,” but anything beyond the initial learning curve should be noted.
Once the designers at Intercom decided that there weren’t any major disruptions, they rolled it out to the broader design team and asked that each team member try it out on at least one project. If you can, get varied feedback: have a few members of the team work remotely, collaborate with some of your cross-functional partners, and switch up the types of projects you’re working on.
After you’ve run a test with each of the contenders, revisit the evaluation criteria and ask your team to grade each tool. You’ve already chosen your top three criteria (e.g. collaboration, productivity, security & reliability), so narrow down the list based on that. If you’re still stuck between two vendors, broaden the criteria to include the whole list. Try to be open—it’s entirely possible that your initial hypothesis is wrong, or that your old tool is actually the best fit.
Once you’ve arrived on a winner within your immediate team, go back to your stakeholders and approvers and get their input. If they feel similarly, that’s the best path forward.
No tool is perfect, but you can certainly find one that fits your team’s unique structure, style, and workflow. The right tool will allow them all to work the way they want—whatever that looks like for them.
To learn more about how to evaluate design tools, get in touch with a product expert at firstname.lastname@example.org. You can check out more about our customers here.