A computer is… the most remarkable tool that we’ve ever come up with. – Steve Jobs

Beware brand-new time-sucking beta-rollout crap. – Bruce Sterling

Tools save us time. They make us more efficient. We use them to make new things, including more tools. Tools are made to be used. That’s why they exist. A paintbrush will sit for a long time doing nothing before it helps to spread paint on a wall. At their very best, tools can augment, amplify and take us “far beyond our inherent abilities.”¹

Just because it’s a tool, doesn’t mean it’s good at its job. We’re all guilty of accumulating things that don’t work very well. It only takes a few minutes looking through a kitchen drawer to find an item that’s either broken, or doesn’t perform its function efficiently. A drink bottle that leaks when spun upside down or a paring knife that’s gone blunt. Tools can be ineffective for other reasons; too complicated, dangerous or simply the wrong thing for the job.

The right skill for the job

Right now everyone I know at my job at a software company is building things, including tools. A few years ago, a designer might have found some spare time to code up a plugin that helped to speed up a manual workflow. Now they are pushing code to production and creating bespoke apps. All you need are some agents and some agency.

One type of tool I’ve noticed a lot of people using and creating are “skills”. Skills don’t really take any technical skill to make. But they are useful. They “teach Claude how to complete specific tasks in a repeatable way, whether that’s creating documents with your company’s brand guidelines, analyzing data using your organization’s specific workflows, or automating personal tasks.”

Some skills are developed and used privately. For example, another designer told me about a skill they made to turn any text into something that sounds like something they would say. Other skills are shared out publicly, so that lots of people can use them, like a whole marketing team or the entire company.

It’s not rocket surgery

Skills that are designed for many face the same usability issues that any type of software has. The developer simply can’t know everything about the “user”, or how they will end up using their program.

In most cases this mismatch or misunderstanding of mental models results in sub-par user experiences, wasted time and general confusion. Users might send emails, stop using it, or worst, suffer in silence. But by talking to users, testing, making smart assumptions and iterating, many of these issues can be resolved and avoided. It’s not easy, but it’s not rocket science either.

With the skills and other new tools we make, we must do the same. Even if there’s only one user. It’s the users who are the ones who are needed to actually use, test, stress and push the builders to make improvements that meet their needs.

Are you building something? Consider:

• The whole world might not need access to your tool straight away. Roll it out slowly, or test with small, private groups of people.
• Make it as easy as possible to get feedback. Better yet, sit down with someone who’s actually using your tool and listen and watch how they use it.
• Allow healthy competition. Great software wouldn’t exist if we stopped after building one messaging app, to-do list or browser.
• Sometimes it’s better to buy. Even a company like Google, filled with some of the best internal tools (and tool builders) still relies on software built by other professionals.

There’s nothing worse than doing “the same job 5 times because your tools are inferior.”² We shouldn’t put up with our own broken or shoddy tools. So let’s make sure we’re not creating shoddy tools for other people to put up with too.

1. Steve Jobs, “A bicycle for the mind” (YouTube) ↩︎
2. Bruce Sterling, Reboot 11, 2009. ↩︎