The hidden cost of new tools

Today, I’m going to teach you about the hidden costs and impacts of new tools, and how to avoid the tools that will waste your time.

Why do you need to know this? Because you care about what you do and you want to improve your craft and your productivity.

And you live in a world where you’re bombarded constantly by new tools, processes, and apps that promise to elevate your work, make you more productive, make life easier, and even make you rich.

Smart designers know before they hit that “Sign up” button:

• What is the realistic value of a new tool or process for them?
• How much does it actually cost? (far more than the subscription cost!)
• What are the resulting short-term and long-term impacts?

Unfortunately, most designers dive right in, and find that the promised value doesn’t pan out. Instead, they waste tons of time tinkering with tools instead of actually getting work done, causing productivity to massively suffer. In a team context, this impact becomes greatly magnified.

It took me years to learn the hidden costs and impacts of new tools and processes. Let me save you those years of learning.

The hidden costs

We know that the best tools usually aren’t free. But aside from the normal operating costs or subscriptions, there are a number of hidden costs and impacts that you need to know, or risk harming your business.

Here are some often-hidden impacts of adopting new tools that you need to consider:

Training and onboarding

Training yourself or team members on how to use a tool is time-consuming. Especially in a team context, you can’t rely on everyone being self-taught: your team should have a process that’s shared in your team. These processes require someone to develop them and to train others.

File/Data migration

A new tool usually means you’re moving from an old tool. Which also means existing work needs to be brought into the new environment.

When I helped our team migrate from Sketch to Figma, we had to port over our extensive application UI Kit. That was in 2018, and Figma’s migration tools for pulling in Sketch files wasn’t great. There was a lot of rebuilding and refactoring that ended up having to be done.

Downtime

If a process or tool is critical for your work or business, changing it is going to cause some level of downtime. This will directly impact productivity and revenue.

Productivity losses

Any promised productivity gains for a new app are almost never seen right out of the gate. Even after you get up and running and you know your way around the tool, there’s still a learning period where you’ve got to get comfortable working in the tool in order to see the same level of productivity you had from the previous tool.

Resistance to change

This doesn’t apply to solo workers, but you’ll run into it in organizations: team members will have varying levels of resistance to change. Everyone may agree that the changes are good, and still some struggle with full adoption. This impacts productivity, and can be a drain on the DesignOps leads doing the training and implementing the changes.

Impact on communication

Some tools bring new communication processes. These can even be good features, but the impacts to the existing communication processes need to be understood.

When a team I work with adopted Figma, we were excited about the built-in commenting and feedback features, and happily dived in to use them daily. However, we didn’t anticipate how this would cause a lot more fragmentation of our project conversations, which were already spread out between a few other tools like Slack and Jira. We had to develop and implement new processes to manage how and where we documented conversations and project decisions.

Impact on culture

Some apps and tools are critical to a team’s workflow; and almost all work revolves around or goes through it. Or, maybe a tool can change a relational touchpoint in your company.

For example, in one team, we started using the amazing screen recording app, Loom. This really improved our asynchronous communication, but with fewer review meetings, we lost a key connection point with other teams, and the relationships between teams began to suffer a bit.

Impact on structure

Sometimes larger systems, such as project management systems, bring their own paradigms of team structures. This can be confusing and disrupting, and lead to changes in your teams’ structures.

How do you know if a new tool is worth it?

In my opinion, a tool is “worth it” when it brings you more value than it costs to adopt the tool.

Tools only have value in how they solve our problems.

This promise of value is going to be different for every person or team, becaause your work style, needs, and problems are unique to you.

To decide whether a tool or process is worth investing your time and resources in adopting it, you should consider three things:

• Your specific problems
• The direct impacts
• The indirect impacts

Step 1: Know your specific problems

There are many tools I’ve used for design work. But I use Figma because it solves a a few specific problems for me:

• Easy real-time collaboration with my team
• It’s flexible enough to be a centralized location for all design documentation for a project
• It’s fast and responsive

Of course, there are other features and benefits of using Figma (and they continue to improve the tool). But these three features mapped to three specific pain points I was having:

• It was difficult to share work out to my team. It required exporting mockups, hosting them somewhere I could share them, emailing notices, etc.
• We were having a big problem with “Information fragmentation”: the “live” design work was in a proprietary app (Illustrator, Sketch) that wasn’t accessible by the larger team. And any documentation was kept in another tool.
• We continuously had memory issues, huge file sizes, and slooooow, unresponsive apps, which really slowed down the work

These were daily struggles for my team. Figma’s features showed the potential to solve these pain points in one tool, which was a huge upside for us.

You need to know what pain points you have, and how a new tool or process might solve them. If there’s not one or more specific, known pain points you are experiencing that you can imagine this tool solving, don’t put the effort towards it.

I recommend tracking your pain points. This shouldn’t be complicated, keep it easy to do. I keep a “Snag Log” doc, which is a running note of things that go wrong or frustrate me. This helps me see patterns over time. These problem patterns help me evaluate things that might help fix issues.

If you work with a design team, I’d also suggest the team having regular post mortem meetings or workflow workshops where you discuss what is going well, and what isn’t. This will help you understand the common pain points shared across the team, and where improvements could bring the most “bang for your buck.”

The exercise: Discovering your pain points

Make a new document in your favorite docs tool.

Create two columns. Give the left column a heading of “Pain Points,” and the right column a heading of “Opportunities.”

Now, take a few minutes to think through your normal day’s work.

Ask yourself the following questions:

• What do I find challenging?
• What are my sources of continual frustration?
• What have I recently said, “I wish…” about?
• Is there anything I’ve had to research lately to fill gaps in your knowledge?
• What do I have to do over and over?
• Is there anything I’m avoiding doing?
• Is there anything that I find confusing?
• Do I feel stuck about anything?

Write down the answers that come to you.

You now have a list of potentially high-impact problems that you need solved somehow. This simple list makes these issues more in your mind. These are your specific pain points.

Now when you run across an enticing new tool, it should map directly to one or more of these specific pains in your list.

What about pain points we don’t know about?

Sometimes we have “unrealized” pain points; we can be so used to the status quo of how we work that we don’t realize just how much better a certain aspect might be. But I think this principle still stands in that case: a tool’s potential value should make you think of specific pain points it could solve. That includes pain points you previously didn’t realize existed.

However, if that’s the case, proceed with caution. You should do your research to make sure this is really an unrealized issue, and that the tool’s solution is a big enough upside.

Step 2: Know the direct and indirect impacts

Here, you should take some time to think through and list any impacts you foresee the software having on you and your team. There are two types we’re concerned about: Direct and indirect.

Direct impacts are usually short-term effects, meaning, you’ll see them almost immediately.

Indirect impacts often are seen in the long term, but represent the most potential value.

Some examples of direct impacts might be:

• A new workflow for designers that drastically reduces the time to create design-to-dev documentation
• A new doc template for product feature requirements that makes the design discovery phase so much smoother
• A new design system’s code component library that gives dev a single source of truth, and an efficient way to copy the commonly-used components into their code

And the related long-term, indirect impacts might be:

• Faster design-to-dev handoff gives mores time for better conversations between designers and developers, and improves both product shipping times and team culture over time
• More clear feature requirements helps the product team better understand what designers need to know, and designers to better understand high-level business goals. This improves the communication and knowledge of both teams over a period of time.
• A design system component library reduces the code maintenance load on the development team, and that effort savings multiplies with each new product that uses the library’s components.

Direct and indirect impacts aren’t always related. And, they’re not always positive. Negative impacts are usually related to the hidden costs we’ve already discussed:

• A new workflow process causes a lot of frustration in the design team because it’s too complex (training, productivity losses, impact on culture)
• The new doc template doubles the time previously spent on formulating the product requirements documentation (training, productivity losses, resistance to change, impact on communication)
• The design system’s code component library requires a significant amount of training in order for the design team to be able to contribute to it properly (training, resistance to change, impact on culture, productivity losses)

Sometimes, these negative impacts are simply part of the cost, and are outweighed by the longer-term benefits. They will improve over time.

You’ll need consider what are the potential impacts, both direct and indirect, and then judge whether the impact is worth paying as an investment towards the longer-term upside, or if it doesn’t make sense because the cost is too high and may never be outweighed.

The exercise: Tool evaluation

Make a new document, add the name of the tool at the top, and then copy in the specific pain points this tool solves from your first doc.

Under that, add a new section titled “Impacts”, and add two columns. Give the left column a heading of Direct impacts, and the right column a heading for Indirect impacts. Give each column two sub headings: Positive and Negative. Now, list out any impacts you can think of, and put them in the appropriate list.

These two simple exercise will help you think through the overall costs and impacts, and you’ll be able to make an educated decision on whether a particular tool or process would be worth the adoption effort.

Note, these exercises are helpful to build a qualitative “sense” of the potential impacts. For larger-impact tools or In an organization or team context, you’ll often have to get buy-in from management or stakeholders to green light bringing in a workflow change. In order to do that, you’ll have to build a qualitative proposal, which measures the potential ROI of a change.

We live in an incredible time for technology: the advances of AI, web technologies, and other innovations are pushing the rate of change like never before. My hope is that these simple exercises will help you build up a mental model of realistic needs and opportunities in your workflows that you can use as a filtering criteria for the influx of exciting new apps.

Defining these pain points and needs in concrete terms in your mind creates a sort of automatic filter set. You’ll find that you’re better able to understand how something may benefit you, rather than simply getting caught up in the excitement.