In-product Messaging for Subscriptions

Design @ TechSmith

How to tell end users they're expiring when they aren't the admin

Identifying opportunities for customization

Originally, our subscriptions were only released to individual licenses, the person buying the software was also the one using it. I had written in-product messages based on that assumption, with language that spoke directly to the account owner and offered clear next steps for managing their subscription.

But with the addition of subscription-based business licenses, that model no longer applied. Now, the end user might have no access to account details or billing info, just a download link and a license key handed to them by IT. The messaging we had simply didn’t make sense anymore.

We couldn’t just copy and paste what we’d used for individuals. I stepped in to design a new messaging system that accounted for these layered roles and unclear ownership, making sure the right people got the right information without overwhelming them or creating unnecessary confusion.

What made this problem a tricky one

Due to technical limitations, we were not usually aware who the end user was. They could be a user who purchased themselves, an end user who knows the purchaser, or an end user who is far removed from the purchaser.

We couldn't rely on frequent product releases to update the solution if we got it wrong. Due to it being an installed product, and users who would be experiencing this on day one, we had to get it pretty close to right on the first try.

Collaborating to map out possible experiences

Once I had identified the key user types and possible subscription states, I knew I couldn’t design the messaging system in a vacuum. I needed to understand what was technically possible, what users needed, and how to support them effectively.


I reached out to collaborators across the company to fill in the gaps:


  • With developers, I worked through what signals the product could detect about a user’s subscription status. This helped define when and how we could responsibly surface a message.

  • With tech support, I explored the common issues users face in these scenarios and how they usually get resolved. Their insight helped shape messaging that would guide users to the fastest and most accurate resolution path.

  • With the licensing and product teams, I aligned on the logic behind the subscription model and ensured that messaging wouldn’t conflict with business needs or create unwanted friction.

Mocking up where and how the message should appear

I created a simple, non-blocking banner that appears in the Account window—where users already manage their license key. It can be collapsed and reopened, giving users control without making the message feel intrusive.

The banner only shows when needed, like when a subscription is about to expire, and it disappears once the issue is resolved. I also made sure it worked consistently across both Snagit and Camtasia, which simplified development and kept the experience unified.

By sharing detailed mockups early, I aligned with developers and QA to make sure the final experience matched the design exactly.

QA testing and stakeholder reviews

This messaging system was tested as part of a broader QA effort to prepare the new business subscription model for launch. Since subscriptions would begin expiring shortly after release, it was critical that these alerts worked as expected from day one.


I partnered with QA to make sure messages triggered under the right conditions and behaved correctly across different user scenarios. We tested timing, visibility, and the support flow to confirm that the experience was clear and useful.


This work also met key stakeholder goals around retention. By helping end users flag problems early—without relying entirely on admins—we gave teams a better chance to stay active and avoid unexpected lapses in access.

Takeaways

This project taught me how to advocate for design even in ambiguous ownership spaces, collaborate across technical and support functions, and build scalable systems that respect different user roles. Most importantly, it was a reminder that good UX doesn't always mean more information—it means the right information, at the right time, in the right way.

So far there haven't been complaints coming from technical support indicating that the messages are confusing or not appearing correctly and the customer success team has helped to re-onboard teams that had expired but changed their minds as a result of the messages. Future iterations, given more flexibility in the backend, would get more specific and highlight usage and user metrics to encourage retention and action during expiration.

Reach Out!

I would love to hear from you.

Reach Out!

I would love to hear from you.

Reach Out!

I would love to hear from you.

Reach Out!

I would love to hear from you.