I use a great service called Headway to keep Preceden users informed about updates to the product.

Headway provides a widget I have installed on Preceden to let users know when there have been updates With it, users will see a bell with a count of unread items (which Headway keeps track of in local storage):

That bell, when clicked, expands into a list of updates:

And those snippets expand into longer posts:

I’m pretty good about sharing big product updates with users on Headway, but recently 90% of my day to day work is making small, incremental improvements to the site, or things that are not very interesting to users like marketing projects.

This causes a perception problem though, because often times weeks go by when users don’t see me sharing any updates, and they can interpret that to mean we’re not working. Especially when you combine that with inactivity on a public list of user requested features like Preceden has (most of which are low priority for me), and it’s easy to imagine Preceden is in maintenance mode.

A customer wrote in recently asking about this:

Hi, we’re a large organisation using Preceden and are considering shifting all activities away from the tool due to the slow pace of continuous improvement.

I’m interested to understand – is the tool still being improved, or is it just business as usual support now?

The publicly visible roadmap shows no work in progress.

I thanked the customer for the feedback and explained the situation and he was very understanding. We also jumped on a call and I got a lot of great suggestions from him and his team. But it was a wake-up call that I needed to do better about communicating what we’re working on, even if it’s not user-facing feature work. And also to ensure I’m rolling out a steady stream of product improvements, and not focusing on backend and marketing type work for long periods of time (which is funny, because for years I did focus almost entirely on product work, almost certainly too much).

A quick aside: I previously sent out monthly email updates to customers detailing the product improvements we shipped that month, but as my focus has shifted away from mainly feature work and more to the other type of work required to run and grow a SaaS business, the frequency and number of big feature updates I could share declined, making those monthly email updates harder to write, and I eventually abandoned it. Might be something to revisit down the road though.

Anyway, to address the immediate problem, going forward on the last weekday of each month I’m going to share an update listing the smaller projects we worked on that month. It doesn’t take much time to write, and I imagine a lot of users will find it interesting, even if the updates don’t necessarilly impact their usage of Preceden.

Here’s the first one that lists what we worked on in September:

Probably should have been doing this all along. Lesson learned.

There was a great discussion on Twitter recently that began with Daniel Vassallo calling out a SaaS for not refunding an accidental annual payment he made on their service. He intended to purchase the monthly plan, but due to an unclear UI and poor copy, he unintentionally purchased the annual plan, and the business refused to refund it.

One of the responses to his tweet which I loved was “monthly billed annually is cursed copy”:

To give some background on the issue here, let me tell a quick story…

A very profitable A/B test

I used to work at Automattic, where I was as a developer on the business and marketing side of WordPress.com. For many years, WordPress.com only offered annual plans and their pricing page displayed those annual prices:

In the spring of 2016 Catherine Stewart, Automattic’s savvy Chief Business Officer, suggested we test displaying those prices as their monthly equivalents and see how it impacted new revenue. For example, instead of displaying “$99 per year”, we would display “$8.25 per month, billed yearly”. We would still charge users the full $99 and give them access to that plan for a year, but our plans and pricing page would display the lower monthly equivalent:

I implemented and A/B test and we let it run for a few weeks. The results? About a 10% increase in $/visitor to the pricing page (which is a better metric that $/customer or conversion rate alone, since it takes into account what % of visitors go onto pay, and how much they pay, though not refunds).

At WordPress.com’s scale, making 10% more per person who saw that page translated into a ton of additional revenue for the business.

Why it works

When people see “$8.25 per month billed yearly” people tend to perceive it as cheaper than “$99 per year”, so more people wind up buying.

At least that’s the hope. If you’re not careful though, you’ll get a lot of people paying annually who think they’re paying monthly.

Design matters

The problem that’s easy to run into is if you don’t have a great UI with clear copy, you’re going to get a lot of very frustrated customers who mistakenly purchase the annual plan.

Done well, customers will understand they are paying the $99 (or whatever it is for your SaaS) for a full year. Done poorly though, people will think they’re paying $8.25 for a month of access, and feel tricked when they eventually realize they actually paid $99 for a full year.

Here’s what the pricing looked like Daniel accidentally made his annual purchase:

As he noted in his tweet, that “Annual” toggle is very easy to miss. And unlike WordPress.com, this just says “$59 per month”, not “$59 per month billed annually”.

It’s an easy mistake to make

When I introduced monthly plans on Preceden (my SaaS timeline maker) a few years ago, I made the same mistake and it resulted in a lot of accidental annual purchases.

The plans default to annual pricing and displays monthly amounts billed annually:

All good here I think.

The problem was with the next step, the payment form, which looked something like this:

It did say “Subtotal: $120” but it was easy to miss, and a lot of people did, resulting in support requests like these:

I always gave refunds, but it was clear that a lot of people were accidentally purchasing the annual plan, thinking they were paying monthly.

I don’t remember exactly how I stumbled across it, but I saw a screenshot of some SaaS’s pricing form that inspired a few changes to Preceden’s payment form.

Here’s the current design with those changes:

Two things to highlight:

• There’s a toggle to switch between annual and monthly directly on the payment form, making it super clear they have chosen annual and giving them an easy way to switch to monthly.
• The prominent “Billed Today” line immediately before the CTA including the full amount they will be paying.

After I made this change, the number of refund requests for accidental annual purchases dropped to zero and I felt a lot more confident that the people who were purchasing annually were doing it intentionally.

As for the SaaS that Daniel purchased from, they redesigned their pricing and wound up in a very similar place (though unlike Preceden, they don’t offer refunds):

One area for improvement might be for Preceden to display the annual amount in the interval toggle. Currently it displays “$10/month” (consistent with the pricing displayed on the plans in the prior step, and making it easier to understand the savings IMO), whereas with this SaaS, they are displaying the full annual price there ($708/year). I think because Preceden displays the “Billed Today” line with the full annual price below it, the way I’ve done it is fine (also given no refund requests anymore due to accidental annual payments), but I’m also open to changing it if anyone wants to make an argument that displaying “$120/year” there is better than “$10/month”.

Regardless, whatever you do for your SaaS, make sure it’s abundantly clear to users what they’ll be paying, and lean towards generously refunding purchases unless there’s a strong reason not to. You definitely don’t want to be on the receiving end of a viral tweet about your SaaS’s deceptive pricing. And even if you manage to avoid that, you should always do right by your customers which includes making it abundantly clear to them what they’re paying for your service.

Milan (Preceden’s designer) and I recently wrapped up a project to redesign Preceden’s pricing page.

Here’s the previous above-the-fold content:

And here’s how the new design turned out:

Few things to highlight:

• Switched from radio buttons to this new UI (the previous design was inspired by Help Scout’s pricing page which uses radio buttons)
• Revamped many of the colors including the font colors, check marks, and buttons.
• Increased the font size a bit, which forced me to rework the feature descriptions to ensure they all fit on a single line. For example, “Create timelines with up to 10 events” became “Create unlimited timelines” and “Add 10 events per timeline”; “Export to PDF, PowerPoint, and more” became “Export to PDF, PPTX, and more” (hah).

Very happy with how it turned out.

Kudus to Milan for suggesting we work on it and for the fantastic design work.

The process

In the past, implementing a redesign like this would have gone something like this:

• Milan designs it in Figma
• We discuss over Slack and he iterates
• When it’s in good shape, either he implements it in Preceden or I do depending on what else we have on our plate

This time, at his suggestion, we tried a different approach since he prefers mostly doing mockup work in Figma (and not implementing his designs in the Rails app) and it’s not a great use of my time converting his Figma mockups to HTML/Tailwind either.

Here’s what we did instead:

After Milan designed the new pricing page in Figma and we iterated on that mockup in Slack, we hired Design2Tailwind, a small team that specializes in Figma to Tailwind conversion.

This initially required me filling out a form detailing the work we wanted done:

Vivian, the founder, sent me a few questions over email to understand the scope: would it require interactivity? Responsiveness? Can we provide the Tailwind config file?

In the end, she quoted me $150 for the project.

I invited her to our Slack group, where we discussed a few small things along the way, and they she shared their v1 implementation:

A few small tweaks later and we had the delivery for their piece of the project:

Integrating this into the Rails app took a few more days of work on my end since the pricing page (and in-app upgrade dialog which shares the same design) is dynamically generated based on the user’s current plan, the plans they can upgrade to, the features on those plans, etc:

Outsourcing the initial HTML/Tailwind implementation was a great decision though, and one we’ll surely do again for any non-trivial design projects. It let Milan focus on the mockup work which he really enjoys, and me focus on other projects that were better use of my time.