As with the last mid-year update, this Low End Theory update also falls on July 4th. Even though Hypermatic is based in Australia, and not the United States (or Japan, as some seem to think, based on the design of this website), I do like the idea of doing these mid-year updates on Independence Day, and re-focusing it on continuing to declare our independence from legacy design/development workflows.

Plugin update highlights in 2024 (so far)

There are multiple updates and small fixes shipped to multiple Figma plugins on a daily basis, but here are some cool highlights from the first half of 2024:

• Added Superscript & Subscript support to Emailify
• Added Lottie support for Google Ads to Bannerify
• Added Custom Image Hosting to Emailify
• Added Insider integration to Emailify
• Added Blend Modes support to Bannerify
• Added Image → Vector imports to Convertify
• Added Icon Buttons to Emailify
• Added PowerPoint File Importer to Pitchdeck
• Added Markdown support for Content Syncing to CopyDoc
• Added Scale Mode presets to Commentful
• Added Airtable Sync support to CopyDoc
• Added iOS Splash Screens to Favvy
• Added Auto-Repeat for Spreadsheet Syncing to CopyDoc
• Added Transparent GIF Detection to Emailify
• Added Toolbar Toggle to Pitchdeck
• Added GIF support to Commentful
• Added Larger Window Size option to Commentful
• Added improved Image Compression to Bannerify
• Added Outlook support for Gradient Buttons to Emailify
• Added Image Scale Overrides to Bannerify
• Added CSS Drop Shadow support for Buttons to Emailify
• Added CSS Gradient Buttons to Emailify
• Added copy/pasteable Email Signature exports to Emailify
• Added Approval Statuses to Commentful
• Added grouped text Localizations to CopyDoc
• Added HTML size optimizations to Emailify
• Added Auto-Layout linting to Emailify
• Added Plain Text exports to Emailify

Overhauling the Documentation Site

The biggest project for the first half of 2024 was completely updating the Hypermatic documentation site, which had been gradually getting out of date, as it was being updated ad-hoc over time whenever a new feature was introduced into any of the plugins, which meant that all the videos had slightly (or largely) different looking UI in them.

It’s always sad and disappointing to me whenever I come across documentation for software that’s totally out of date or has been neglected to the point where the content in the documentation doesn’t match up with the current reality of the product it’s trying to provide context or help around.

To avoid falling into this trap, I decided it would be a good time to completely restructure, refactor and add to the documentation site for all of our products, including re-recording every single video screencap for each page and subheading throughout the docs site; this meant recording and editing hundreds of short forms videos across the 12 different Figma plugins.

The update started with migrating the underlying docs platform from VuePress to Mintlify, which offers a better way to organize content and make it easy to find, and was a great opportunity to re-think how the documentation for each plugin was structured.

The project started at the start of January 2024, and finished up with the last plugin’s docs and video screencaps being completed at the end of June 2024. The end of the project was bitter-sweet, as 2 weeks after completing the overhaul and having all of the video screencaps up to date, Figma announced that the app’s user interface had just been completely re-designed, and would be rolled out to all users over the coming months.

The good news is that most of the content in the documentation videos are centered around the UI of the Figma plugins, rather than the Figma app UI itself; although, the Figma UI is prominent in all of the videos and does often get referenced as part of the instructions for completing a certain task or using a certain feature. At this point, I think we will leave the new videos “as-is”, until the new UI is completely rolled out and finalized in the Figma app, and then we can re-assess and decide if it’s worth re-recording some or all the video screencaps again to reflect those changes.

Either way, the documentation content itself and the way it’s structured is way better than the previous version, so I think it was great to get it all updated in one big marathon to have a totally up to date and consistent place to find information about any feature in any plugin.

Avoiding “Enshittification”

There’s always a fine line between shipping new features or software updates that deliver real value to customers, and shipping updates that end up making the product overcomplicated or worse over time. One trendy (the American Dialect Society selected “enshittification” as its 2023 Word of the Year) term for this that has been coming up lately is Enshittification, and while a lot of the discussion is around products doing what’s best for themselves at the expense of their customers, I think similar outcomes can happen just due to a lack of care or intentionality about keeping the software useful for the customers that use it regularly to solve some problem that they find your product useful for.

I’ve always tried to be vigilant with keeping our Figma plugins as simple as possible and keeping them focused on the core problems it was originally designed to help solve. This has meant saying “no” to a lot of good (and not so good) ideas or suggestions/wishes from customers. It’s really easy to say “yes” to everything, but things ends up with software becoming “all things to all people”, and loses some of what made it what it was originally.

There’s a common saying that “software is never finished”, which is true, because the dependencies of that software often have to be updated and maintained in order to continue functioning properly. However, lots of this work usually happens behind the scenes, so from that perspective I do think you can have something closer to “finished software” from a users perspective, in the sense that there aren’t many big interface updates that would be noticeable for a regular user of it.

Maybe these updates happen gradually, or are appended to existing parts of the user interface (for example, adding more “Export” options to an existing drop down selector menu), where the functionality is still being enhanced, but not at the cost of resetting the users muscle memory for using the product by redesigning or cluttering the interface with brand new elements.

There are some examples of software that I use, where I only use the core features that haven’t really changed much over the last decade (from a user facing perspective), and I would be fine with them basically staying the same for the next decade, where the functionality remains mostly stable, with most of the work going into the performance behind the scenes:

• Google Docs/Sheets
• Gmail
• Slack
• Git
• Handbrake
• FileZilla

While the examples above can’t be considered “done”, and have lots of open and closed source designers and developers working on them, I think there is something to be said for products that try to do a couple of things really well, without splitting it off into a bunch of other directions, or adding in new features that maybe 1% of the customer base might find useful for the sake of it.

Another one I came across is Wordstar, a word processor from the 1980s that George R.R. Martin used to write “A Song of Ice and Fire”:

It does everything I want a word processing program to do and it doesn’t do anything else. I don’t want any help. I hate some of these modern systems where you type up a lowercase letter and it becomes a capital. I don’t want a capital, if I’d wanted a capital, I would have typed the capital.

- George R.R. Martin

The reason I’ve been thinking about this is partly related to the documentation overhaul I mentioned above, where there were so many interface updates for all of the products over the first 3-4 years (because there was so much to build) that the “real time” documentation led to most videos having a slightly different interface than the ones before it.

Now that I’m really happy with where the Figma plugins are in terms of functionality and usability, I think the instinct needs to shift from shipping new features like crazy (including any UI updates that brings), to trying to be more mindful about how to add value without degrading the consistency of the experience for the thousands of designers who are already used to them.

To me, this feels like the right balance; for example, our Convertify Figma plugin already has a user interface that allows you to click on drop down selector, choose the import or export format you need, and then click one button to start the conversion process. This interface has already been designed to handle more formats and conversion options, without needing to altar the entire interface to add that value to the user; all of the extra functionality can be shipped behind the scenes, and the only additional visual “clutter” is one more dropdown option inside an interface that the user is already familiar with.

Platform Risk

There are some great benefits that come with building on top of an existing platform, especially as a small team, but there are also inherent risks that come along for the ride.

Back in the early 2010s, Zynga was a social game developer that was highly dependent on Facebook for its user acquisition and revenue. In 2012, Facebook changed its platform policies, which reduced Zynga’s visibility and access to user data. This led to a significant decline in Zynga’s user base and revenue, where they lost nearly half of their daily active users in one year.

Another example was TweetDeck, which was a popular social media dashboard application that relied heavily on Twitter’s API. When Twitter decided to change its API terms and conditions, limiting third-party clients’ capabilities, TweetDeck’s functionality was severely impacted (Twitter eventually acquired TweetDeck to control its development and integration).

Closer to home, we built a Figma plugin called Pitchdeck, which helps designers create, export and present slide decks from their Figma designs. Last week, at Config 2024, Figma announced a brand new product called “Figma Slides”, which takes some of the additional features that Pitchdeck offered (eg. slide notes, animations, Figma Prototype embeds etc) and delivers them in a really nicely designed new product under the main Figma app (similar to the previous “FigJam” product released a couple of years ago).

While it doesn’t mean that Pitchdeck is irrelevant now, there’s surely a subset of current and potential Pitchdeck users who will find that Figma Slides has all of the features that they personally need, and will decide to use that instead.

The focus for Pitchdeck (and all of the other plugins), then, is to try and focus on the areas where it’s differentiated and continue to deliver the most value to our customers there, as an alternative for anyone who is after features that the Figma plugin offers over the native experience.

Antifragility

With the topic of platform risk fresh in mind, it has also made me think about Weblify, which is a Figma plugin currently in BETA that I’ve been working on to become more of a fully fledged website builder. Knowing that Figma’s mission is “going from idea to design to production”, it seems inevitable that (similar to “Figma Slides”), the future will contain something like “Figma Sites” where you can publish or deploy content designed for the web to a production server somewhere.

Similar to when Adobe XD went into maintenance mode, I don’t really want to be caught out trying to develop something that is going to be superseded or made irrelevant on a long enough timeline.

As I’ve written about multiple times in previous updates, this is also a key reason why I’ve actively avoided trying to cram AI features into any of our existing Figma plugins, because if you had worked on these features as part of a Figma plugin any time over the last 18 months, most of that AI functionality is now going to be native in the main Figma app, essentially wiping out the need for those third party plugins.

I don’t think it’s wrong to add AI features where they make sense, but they should be antifragile, where improvements in intelligence or native AI features should make them even more valuable, rather than redundant.

I think the same is true for creating any of website builder product, where it needs to be designed in a way that’s differentiated enough and solves real problems in a way that would still be useful even if Figma made a new baby that morphed it with Framer or Webflow in some way.

Ensuring sustainability over the long term

Based on the thoughts above on platform risk, AI and the importance of antifragility, I want to take a bit of time to rethink the direction I’ve been working on for Weblify. If I’m going to be dedicating a large amount of time over the coming years on a new product, I think it’s important to make sure the initial compass direction is pointing in the right way before charging full-steam ahead into building product again.

In a similar vein, after essentially working non-stop (not taking a full day off since December 2019) on Hypermatic for almost 5 years, and because I have a strong background in design/development, most of my work time has been super focused on building and shipping new product updates to keep up with the internal roadmap for all of the Figma plugins and solving real recurring problems that come up from talking to users every day.

Maybe it’s partly related to the bitter-sweet result of finishing 6 months of documentation videos only to have the user interface in them completely change shortly after (and feeling a bit low about the prospect of re-recording/editing hundreds of video screencaps again), but for the first time, I’m feeling the need to pause and reflect a bit more to gain some perspective on where best to spend my time on the business to ensure we’re delivering the most value to our customers over the long term.

Thankfully, I haven’t really felt properly burnt-out before, but I’ve heard enough horror stories from other founders of it creeping up on them to know that working 7 days per week for 5 years straight may not be the best strategy for the next 5 years; so I’m going to experiment with trying to give myself more time away from the screen on weekends (instead of just working both days over the weekends) while our customers are also enjoying their weekends (and don’t typically have as much need for support) and use that time to let my mind wander a bit more and provide some mental space for generating new ideas.

Along with this, I also think it’s time to adjust the ratio of time spent on development and marketing; like any developer, marketing is often riding along in the backseat compared to writing code and shipping new things, but I’m after working on the plugins for 5 years, I’m really happy with where they’re currently at, and I feel much more comfortable with marketing them more, especially talking to so many users who are finding value in for automating their real workflows them each day.

I’m looking forward to trying out some new ideas and marketing channels to see what works; but maybe more importantly, I’m excited to add more balance to my usual mode of being hyper product focused all of the time. Of course, I’ll still be coding and shipping new features and improvements to the Figma plugins, but I really want to try at least making this a 50/50 split with marketing.

I’ll report back with the results in my next update!