What does it mean to design for SaaS?
In our Design all-hands last month, one of the questions for me was “What is the top priority for us as designers to enable the shift towards SaaS?” My immediate answer was that everyone should take the internal training that had been developed to familiarize themselves with SaaS. But then I got feedback that that wasn’t a great answer.
That’s fair. I’ve been working exclusively on SaaS and PaaS apps for the last 10 years: first at Oracle, then at Veracode, then here, at CloudHealth in VMware. And as a result, I think that a lot of what it means to design SaaS services has just become tacit knowledge for me, so it was hard to articulate in the moment. But I’ve given it a lot of thought since that all-hands, and here are some things that came to mind. My only note is that I’m not telling you how to build anything, just listing off some of the design and product implications that are different from the ones that we need to consider when designing on-premise applications. It’s likely not a complete list, so I’m happy to have you add your thoughts to this list and to continue the conversation.
Consumption is king
SaaS services are billed at contracted rates, but we only get to recognize revenue based on consumption/utilization. You’ll hear consumption metrics expressed as “monthly recurring revenue” (MRR) and/or “annual recurring revenue” (ARR), such as $30k MRR or $1M ARR. Consumption models and terms are tied to contracts, like your utility bills. Your utility companies have set rates at which they charge you, but you only get billed for the electricity or gas that you actually consume.
Product and design impacts:
“Shelfware” rates are a new KPI to track — Shelfware is the inverse of consumption. The percentage of our customers who are not using the service that they purchased = the shelfware rate. For example, if we can only demonstrate that 40% of our users are actually using our service, then our shelfware rate would be 60%.
“Consumability” is the new “usability” — Just like usability, consumability means reducing friction in our products so they are easier to consume. Through user research, we can validate that we are removing friction and that the services and features we are offering have real value to our customers.
High-value use cases are more important than ever — More than ever, we need to ensure that we are building the right thing. If not, our users won’t consume our services. Our products need to deliver value to our users, so they can achieve their business outcomes.
Friction is the enemy — In a similar vein, you’ll hear engineering, PM, and everyone else on the cross-functional team want to remove friction for the user. One manifestation of that for us is “fast time to value”, so understanding how long it takes a new user to realize value from the system is something that you’re likely being asked to measure, to ensure that we are building the thing right.
Analytics can be built in
SaaS services are managed and maintained by the vendor, and that vendor can instrument their services to collect data on user behavior and engagement, NPS, and feature adoption. There are several great products on the market that simply require a line or two of JavaScript be inserted in one or more places in your app, and voila! Analytics!
Product and design impacts:
Pattern recognition— Rather than asking our users what they have done, and hope that they recall correctly, we can observe patterns of behavior in real-time, without having to recruit test participants.
More accurate data — Rather than use small samples to find usability problems, we can see where large number of users drop off or fall out of our workflows.
In-product feedback — Whereas we used to have to survey our users to gather NPS, sentiment analysis, and validate personas, we can ask our users to give us that feedback in context of the application as they are using it.
Big data can provide new insight
Because SaaS providers can view all of their customers’ aggregated data, we have the ability to offer new insights in the form of industry trend reports or sharing with our customer how they compare to other customers with similar characteristics, such as number of security vulnerabilities per application or cloud spend per dev team.
Product and design impacts:
Unlocking new value — The value that comes from this aggregated insight can be a feature of the service that provides competitive advantage, or a new offering that customers would pay for.
Machine learning and artificial intelligence can spot trends — SaaS services that leverage ML and AI can offer insight into when a breakpoint is likely to occur, can identify anomalous behaviors, can recommend fixes, and take actions to remediate problems.
Documentation and support in real-time
SaaS services can offer contextual documentation and chat functions in the service itself, and the value of not calling support is tremendous. A 2018 report from Gartner said that customer service interactions drive more disloyalty than loyalty. In a 2018 report, CXI today reported that 96% of customers are likely to exhibit disloyalty after a high-effort service experience.
Product and design impacts:
Contextual help and documentation — Rather than redirect users to help sites that open in another tab or window, we can more easily provide contextual help that is surfaced through a side panel or other mechanism that leaves the user in the context of their task. This ability reduces friction, enables our doc teams to write content that is germane to the user and to serve it up exactly where and when it’s needed, and can obviate the need to call support. In addition, if the service is architected well, the documentation and support articles can be decoupled from the platform for faster, asynchronous updates.
Chat — Support functions such as live or automated chat that are accessible directly from the SaaS service enable live support people to help more people more quickly and help prevent calls to Customer Support.
Versioning
Many born-in-the-cloud SaaS services only have one version. The version that is “live” at any given time is the only version. As a result, a bug that is fixed for one customer is fixed for all customers, there’s no need for the customer to upgrade from one version to the next, nor to document and support multiple versions of the software.
However, some SaaS services need to be versioned because they have a GovCloud instance or because they have an on-prem offering that is served by the same codebase.
Product and design impacts:
FedRamp and GovCloud — Your SaaS service in GovCloud might be exactly the same as what you sell to your commercial customers. However, there are times when your service might need to remove some of its functionality to get FedRamp certified. In those cases, you’ll need to ensure that that the user experience still hangs together without those component parts.
Feature switches/flags — So when you only have one version of the product, how do you roll out a Beta of a feature to just a few customers, or turn features on/off as needed? Feature switches and flags enable the right customers to have the right set of features at any given time.
Frequency of release — Because there is only one version of the codebase and the live instance, you might have 80 or 100 features, patches, or fixes released a week. Continuous integration/continuous delivery (CI/CD) environments allows for more frequent release of new features, which means that your customers can benefit from that new value more quickly.
Service architecture
Many SaaS services started as a SaaS “monolith” — a single codebase that is built, updated, and released all at once. Over the last 6 or 7 years, many SaaS services have either started out as or moved to micro-services, an architecture that allows a federation of single-page apps to be developed, released, and maintained independently of one another, while providing a single, integrated user experience to the customer.
Product and design impacts:
Moving to micro-services — If the SaaS product you are working on is moving to micro-services, it’s possible that they will take a “lift and shift” approach, by just duplicating the customer experience page by page, bug for bug. More likely, while they are carving micro-services out of the monolith, they’ll be changing the language of the front end to something more modern and scalable. That’s a great opportunity to refactor and redesign workflows to be more efficient and to ensure that bugs don’t just get ported from the old to the new instance.
Partial failures — On the flip side, you will encounter the joy of needing or designing partial failure messages, which happen when one micro-service has failed, but the user can still log in and interact with part of the UI.
Onboarding
There are two primary ways that I’ve seen product teams design and architect the customer onboarding experience — self-service and Customer Success-led. Customer Success is usually a team that sits next to inside sales, to ensure that the users at companies that have signed contracts can effectively consume the SaaS offering.
Product and design impacts:
Self-service onboarding should be built in from the beginning — If you want your customers to move from trial to paid or upgrade their service terms using a freemium model, this is best to know when you are building the service. If not, retrofitting it can be hugely time-consuming and costly. In addition, if you are assuming that a user needs a trial version without being an expert in your product, you are building in reasonable defaults, usability, and consumability. If I can start a trial in 5 minutes, I’ll know whether I want to pay for the service within a few days or weeks. And if the subsequent purchase process is self-service, there is no time (and no revenue) lost waiting for days, weeks, or months for people to talk to one another.
Customer success-led onboarding doesn’t scale — If your product requires an expert to configure it, that’s a signal that you shouldn’t ignore. It will slow down the time between the time that the customer expresses interest in the product and when they can try it and/or buy it. That time is revenue. Revenue you are losing because your product is too hard to configure by novices. Likewise, if you need people on your team to enable your users for a trial or purchase, that’s a cost — a cost that will only increase as you add more customers.
There’s still more to talk about
There are more considerations, of course. Some of them include data protection and privacy, data sovereignty, “upgradability” of private cloud SaaS offerings, multi-tenancy considerations, uptime, frequency of doc releases, and support SLAs, to name a few. But you’ll figure them out along the way, and you’ll have the rest of us who are working in a SaaS world to support you.
