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:
- Phase 0: The groundwork
- Phase 1: Discovery
- Phase 2: Evaluation criteria
- Phase 3: The shortlist
- Phase 4: Testing
- Phase 5: The decision
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.
Treat it like a project
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.”
Set a timeline
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.
Know your stakeholders
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.
Consider a formal working group
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.
Document everything
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.
Set expectations
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.
Define what matters to you
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.
Identify painpoints
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:
- Productivity: Whether it’s solo work, sprint planning, design critiques, or developer handoff, think about the workflows you have down, which could use some work, and how this tool might fit into to those considerations. The right tool can speed up slow processes and materially improve efficiency.
- Compatibility: While you may be looking to address a specific part of your workflow, it’s important to think about your team’s broader tool landscape, even beyond design tools. Take note of the whole ecosystem—file storage, project management, chat—and think about whether this design tool replaces or supplements your existing setup.
- Collaboration: Every team has a different way of working, and you want to make sure the tools fit into the rhythm your team is used to. This ties in to the specific characteristics that you outlined earlier. Whether you’re all in one office or managing teams across timezones, some tools will be a more natural fit for your particular structure.
- Security and reliability: Security is a crucial part of evaluating any tool, but larger organizations often require admin controls and visibility into team activity. If someone in the IT department is one of your approvers, make sure they’re able to weigh in on must-haves early in the process.
- Switching costs: It’s not just about monetary cost—you’ve likely spent a lot of time and energy implementing your existing tool, and your team may see a dip in productivity as they get up to speed on a new one. But try to think about long-term value, instead of adding up short-term spend. It’s possible that improved workflows down the line outweigh the initial, momentary drop in productivity. Don’t forget to factor in the cost of any tools that this new one might replace.
- Scale: Some tools are better suited for individuals or smaller teams, while others can more easily scale to fit larger organizations. Look for ones that support shared libraries and design systems—it’s usually a good signal that the tool will grow with you.
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.
Avoid the feature trap
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.
Think beyond the tool
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.
Build a framework
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).
Personal test
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.
Team trial
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. You can check out more about our customers here.
Related Content
