Once Squishy was up and running on the server, we used Codex to create the WordPress plugin. The idea behind the plugin was no longer to compress images itself, but to connect WordPress with Squishy. The workflow became much clearer:
- the user uploads an image to WordPress,
- the plugin sends it to Squishy,
- Squishy optimises it
- and WordPress receives a lighter version.
This means the site can use AVIF or WebP images without placing too much of a strain on the server where WordPress is installed.
We also improved the workflow within the media library and Elementor, so that users would receive more feedback and wouldn’t be left staring at confusing statuses like ‘queued’ or ‘processing’ without understanding what was happening. We have to go through a series of iterations to refine the product step by step. Detail by detail.
Why This Approach Was Better
Because it separates responsibilities. WordPress handles the site, the content and the media library. Squishy handles the heavy-duty optimisation.
If we had left all the compression within the plugin, each site would depend on the quality of the hosting where it is installed. Some servers might handle it well, others might fail, and others might not support AVIF at all.
By running Squishy on our own server, we have better control over the environment. This allows for more consistent results, less load on WordPress, and a tool that can improve over time without relying so heavily on individual hosting providers.
The Interesting Thing About All This
The interesting thing is that Squishy didn’t start out as a brilliant product idea. It arose from a concern directly related to productivity in my work, namely how to automate a process that is currently done manually. (This is where that UX Law comes in—I can’t quite remember the name…).
And that is, having to deal with images that are far too large.
But in trying to solve that problem properly, the natural progression was to create:
- First, a local tool,
- then a web app,
- then an API
- and finally an integration with WordPress.
In other words, a small need ended up becoming a tool of our own with real potential. I think that as we’re in the midst of a revolution, the full picture isn’t yet clear, but by taking part in the process we’re creating value, albeit organically, based on our own needs.
If You Want to Create Your Own Apps Too
If you’re a designer, a freelancer or someone who builds websites, I think this path can open up a whole host of possibilities. It’s not about suddenly becoming a full-stack developer or knowing everything from the get-go, but you can deliver value by creating your own tools, and that shifts the paradigm of what designers have traditionally been.
It’s about identifying repetitive processes, time-consuming tasks or problems that your clients might also face. From there, you can start small: a simple app, an automation, an integration or an internal tool.
The important thing is to change the way you look at your work. Don’t just ask yourself “how do I design this?”, but also “what tool could I create to solve this better and thus deliver value to my clients?”
The New Era of the Designer-Toolmaker
For me, Squishy embodies an idea I want to continue exploring: designers no longer need to limit themselves to designing interfaces, brands or websites. They can also create their own tools.
Tools that arise from real-world experience, from specific problems and from a sensitive understanding of how people work. That blend of design, judgement, technology and craftsmanship is what I’d like to call The New Era of the Designer-Toolmaker.