User experience is voguish to talk about, but the meaning is often poorly defined and consequently undervalued. Many development teams equate it with application ease-of-use or branding/visual design and marginalize it relative to the functionality of the core application - nice to have - but not a key business driver. "It would be great if we could provide a better user experience, but we really need to get the product out the door." This perception however, could not be further from the truth. When it comes to SaaS, user experience IS the product. The alternative is commoditization.
So what is user experience?
From Wikipedia:
User experience is a term used to describe all aspects of the user's experience when interacting with the product, service, environment or facility. It most commonly refers to a combination of software and business topics.
Ease-of-use or "usability" is a required component of good user experience, but it is not sufficient. A system can be easy-to-use, and still create a poor user experience. MP3 players are a simple but relevant example. If basic functionality and ease-of-use (i.e. an easy way to select and play MP3 files) were all that mattered, then the iPod and iTunes would not have achieved market dominance. But reality is that the MP3 playing part is a commodity. What makes the iPod a high value and differentiated product is the user experience.
Visual page design and branding, while also contributing to user experience, are again not sufficient. While I've always assumed this is totally obvious, we've had several clients come to us to "fix" their SaaS applications after they already invested heavily in a new visual design. The site looked good, it had a bunch of RIA functionality (e.g. AJAX or Flex), but it did not provide a user experience that could retain customers or scale with growth. In today's competitive landscape, a SaaS with a pleasing visual design that uses AJAX or Flex widgets is also a commodity.
SaaS as commodity
With SaaS, it is rare that you have a killer idea that revolutionizes the industry and that cannot be readily copied by another team of developers. You may indeed have developed great product functionally and that product might even be easy to use or look great. But if you are not providing that revolutionary, one-in-a-million grand innovation, then you end up delivering a commodity - something that can eventually be duplicated by the competition. This ends up forcing commodity pricing, and worse, no customer loyalty.
SaaS as value
So the question becomes, how do you transform your core application from a product, into a great user experience? How do you move your SaaS out of the commodity space and differentiate it from would-be competitors?
A few points to consider:
- Focus on what your customers actually want or need to perform in doing business with you (high value scenarios) and design your application around these.
- Don't get enamoured and side-tracked by the technology. Good user experience is not about adding AJAX or Flex widgets, or individual tools designed to make a page "sticky", or even great visual design. These tools can add value and be part of the formula but only when they actually assist a user in accomplishing their high value tasks.
- Don't maximize growth at the expense of profitability - design your SaaS with scalability in mind from the start.
- Plan rapid development cycles of no more than 90-180 days to enable quick incorporation of user feedback and behavior tracking.
- Use the techniques of interaction design, information architecture, accessibility, user interface design and user-centered design that are typically applied to the design of the core application, and extend them beyond the product to all of the application touch points - marketing, sales, provisioning, training, support, billing, etc.
Commoditization is a focus on product; differentiation and value are a focus on user experience.
Over the past few months,there has been a lot of news stories and articles about hosted services over the internet. The various terms that describes these offerings -
SaaS, PaaS, Cloud Computing, On-Demand - are often used interchangeably and the meanings can be confusing.
So I thought it might be useful to briefly describe each term from my own perspective of enterprise software application strategy and design.
Cloud Computing
Cloud computing refers to the virtualization of the data center (i.e. compute, storage and network). It is relatively generic big-picture concept, and in some ways, more a marketing term than a defined set of attributes (who wouldn't want their application "in the clouds").
The real appeal to cloud computing is that it is massively scalable using this virtual infrastructure, available pay-as-you-go. Need more server resources because of an exceptionally high demand? Cloud computing delivers this transparently without you having to invest in any more hardware or even know about a specific physical machine.
SaaS (Software-as-a-Service)
SaaS refers to internet-based applications that are available on an as-needed basis. It falls under the cloud computing umbrella of massively scalable, and available anytime and anywhere over the internet. Its special defining characteristics are:
- SaaS are applications delivered over the internet on a subscription or pay-for-use basis.
- SaaS is delivered as a multi-tenant * solution - meaning many customers access one copy of the application installed on multiple servers.
*Multi-tenancy reduces operational complexity and cost in managing the software to deliver the service. For example, updates can be easily rolled out to all customers by updating a single instance instead of many. Multi-tenancy is transparent to the SaaS customer; they just see no upfront investment in servers or software licensing. On the provider side, there is just one application to maintain so operations costs will be lower due to economies of scale in hardware. Support costs can also be reduced through the use of automation and self-service in the application design.
PaaS (Platform-as-a-Service)
PaaS is an integrated platform available over the internet, to build, test, and deploy custom applications. It is delivered on-demand typically on a subscription basis. Depending on the vendor, it can range from a programming environment with a RIA front end (think MS Visual Studio) to a solution intended to mash-up SaaS's. A PaaS may include online development tools, databases, ready-made components (e.g. single log-in widgets), project management tools, mashup-able services and storage.
PaaS can be used to deliver custom applications (client-server style but where the enterprise does not actually invest in the IT staff or infrastructure to run the servers) or as multi-tenant SaaS.
PaaS can also be used as a way to integrate SaaS applications with other SaaS applications and with applications and data behind the corporate firewall.
But does any of this really matter?
Yes - this all represents a fundamental paradigm shift with the enterprise moving away from developing complex, expensive and risky on-premise applications, and instead moving to more virtualized and accessible anywhere/anytime solutions. The real question at the end of the day is well the solution can provide the needed features and functionality, and how this can be delivered with an optimized total cost of ownership.
It is my understanding that the point of running a software or services business is to make money. But very few companies have done so yet in the SaaS space. Several recent articles have taken note of this “missing” profitability and pointed to the the costs of doing business using the Software as a Service (SaaS) model.
In SaaS and the Elusive Path to Profitability, the author looks at financial reports from some of the major SaaS players such as salesforce.com, RightNow Technologies, and NetSuite. He notes that these SaaS companies are pouring resources into sales and marketing and losing the battle for profitability. He speculates that they are essentially following a loss-leader strategy - lose money acquiring new business in hopes of becoming profitable over the life of the customer relationship through long-term subscriptions or up-sell.
Oracle’s Larry Ellison also recently dissed the SaaS industry with his now infamous quote “it’s hard to point to any Software-as-a-Service provider that’s doing a good job of improving its profitability.”
Admittedly, SaaS is still at a relatively early stage of market development and acceptance, and these big industry players have spent a lot of resources educating a market about a paradigm shift. But relying on long-term customer retention or up-sell to make a profit some time in the distant future seems a fragile strategy at best. On top of this, SaaS companies must contend with accelerating competition as more companies jump on the SaaS bandwagon.
Given these concerns, it is reasonable to ask: for businesses that are providing SaaS solutions to enterprises and SMBs, how can they be profitable? What is the secret sauce?
In a previous post I described a measure for SaaS profitability using a simple (and obvious) equation:
Average cost structure per customer
< Average subscription revenue stream per customer
However many SaaS companies seem to ignore this equation - throttling for maximum growth not maximum profitability. They build the core SaaS application well enough, but they conduct sales, marketing, and support using the same resources as they would with traditional on-premise applications (e.g. direct marketing, print ads, sales staff and SEs visiting companies, trade shows, etc). Sales do scale with these efforts, but so do the costs and expenses.
One of the often-promoted virtues/goals of SaaS is to achieve economies of scale so that the cost of acquiring and supporting 100 customers is just marginally higher than for 1 customer. Depending on your hosting solution, you can typically meet this scalability goal for the hardware and software infrastructures costs. But this is where most SaaS consultants or service providers stop. It is the cost of human resources - the staffing - that does not scale well.
Since staffing is typically the most expensive item in any budget, incorporate automation and self-service at every possible point in the SaaS application that would otherwise require a team to handle.
While you can’t and don’t want to replace all human interaction, you can identify all of the points in a SaaS application where support staff would traditionally need to interact with the customer (e.g. early sales, marketing, demos, provisioning, configuration, billing, monitoring, renewals, etc). Then evaluate which of these “touch-points” can be handled as part of the SaaS application design. Where possible, let the technology (automation) or enable the customer (self-service) to do the tasks that would otherwise require support staff to handle.
This is the secret sauce for SaaS - design the application so that it can scale incrementally up to very large numbers without adding additional sales, support or back-end staff. This approach should be a key component of your strategic blueprint. Model the work flows, high value scenarios, and application touch-points and then design the SaaS application to incorporate and then take over selected services that would otherwise be handled by marketing, sales and support staff.
My post is already way to long, so I will stop here. But in a future series of posts I will take a prototypical SaaS application, examine several phases in the customer life cycle that are traditionally a source of non-scalable costs, and then give examples as to how these services can be incorporated into the SaaS application and become scalable.
I’ve been arguing for a while now, that creating a Web-based version of a desktop or server-based product is only part of the battle if you plan to deploy SaaS in the enterprise space. This core application is just one component from the array of user experiences that need to be addressed when deploying or selling any enterprise application. These “other” experiences include marketing, evaluation, configuration, support, monitoring, and feedback.
Just how important are these other user experiences? While I usually try to write things from the point of view of our enterprise clients, this time I thought I would share some personal anecdotal evidence in the consumer space.
I have accounts with two large financial institutions (no names since both have divisions that are clients). Both have web applications that offer comparable services, but Firm #2 seems to offer better pricing for comparable funds.
Since both institutions deliver a very similar web application for trading, you would think that pricing would automatically determine which service I choose. But the reality is that I almost consistently use the web application for Firm #1. Why? It offers a better user experience for all of those things that are outside of the core application of buying and selling funds.
For example, Firm #1’s web app lets me configure my screen so that I can view information that I use most frequently, including monitoring my activities and the fees I have paid. I can get at the same information with Firm #2, but it requires me to use their menu structure and go through several steps for this high value task.
Firm #1 makes it easy for me to get support - both with an electronic help desk, and via email support. Firm #2 offers these things as well, but they are not integral components of every screen - they are like separate applications.
On top of this, for the life of me, I could not figure out how to change my password for Firm #2. I had to contact tech support via phone!
So to come back to the main point: the core application (in this case, fund investing) is only one component from the array of user experiences that need to be addressed by any web application. The other components help maximize the business value of the application. When they are not addressed, you get customer churn.
The iPhone 3G and 2.0 software were released last week. As I perused the new App Store it struck me how much the iPhone and what it represents, will impact the strategy and design of web and SaaS applications at the enterprise level.
The iPhone is just the very visible beginning to an infinite variety of future form factors for internet-connected devices and applications. There will be gesture-based iPhone clones of various sizes, tablets with or without keyboards, multi-screen large displays, MS “surfaces”, as well as new laptops and desktops. What this means for enterprise application design is that you cannot count on the guaranteed luxury of known screen real-estate, input devices, processor speed or server access speed.
Diverse form factors mandate particular strategies for the design of Rich Internet Applications (RIAs) and SaaS. The principals are not new. But they are worth re-stating. Each point would be worthy of a dedicated blog entry, but in this post, I am only going to briefly point out a few.
Identify the high value scenarios, simplify business process and validate this with users
It is more critical than ever to identify and model the scenarios that are of highest value to the widest set users. Then ensure that these scenarios/workflows are prominent in the software, easily understood, and require the fewest number of steps to complete. This likely also involves analyzing your business processes and streamlining them. The result is not a stripped down application - but rather one that is more refined, prioritized and elicits greater productivity. On smaller, low powered devices, the UI design should enable users to accomplish the high-value tasks in very short time. On larger devices you have the luxury to add in more options - but only when it makes sense.
Salesforce CRM for iPhone - high value tasks, integrated with email, phone and maps
Develop componentized, contextual interfaces
On-premise applications are typically dominated by the Windows OS desktop metaphor with drop-down menus, tabs, tables, combo boxes, modal windows, etc. They require a lot of screen real estate and cram in a large number of options and settings to accommodate every imaginable choice and feature. Applications on the web or mobile (where performance is constrained) need to surface just the components and data that are necessary for that device, at the moment.
Use agile design techniques to produce meaningful prototypes in a very short time
Internet-connected devices need to adapt to user feedback, new technology and real-time monitoring of user behavior (i.e. you can track what works and what doesn’t). Agile development processes let you iterate quickly. By using componentized design and user experience elements, you iterate prototypes with little wasted effort and are able to adapt to change throughout the development process.
Get your conceptual models right
Because you don’t have the real estate for sophisticated online help, or guaranteed ability of the mobile user to contact support, you need to make sure that users have the right conceptual models or previous experience models that users relate to high-frequency or high-value tasks. This will minimize training and support, and maximize adoption. Validate with representative users.
Plan for information sharing and social media (aka Web 2.0)
Users on an iPhone are by definition, working on a communication device. More broadly stated, user working on the web are likely involved in or familiar with some form of social interaction. Design SaaS and web applications to take advantage of the easy ability to share information.
Design for accessibility
People usually think of designing for accessibility as something for the visually or aurally impaired. But when you design for accessibility, you are by necessity also designing for devices that are resource constrained. Design for accessibility and you achieve several goals at once.
There are certainly many more strategic and design principals that I could cover. These are just a few that immediately jumped out at me when looking through the App Store. What is clear, is that any enterprise developing a new web application or SaaS solution, must have a strategy to accommodate a wide range of dispersed users using a diverse range of devices.
Having worked with a significant number of organizations on SaaS strategy and design, I see a pretty clear picture emerging of factors that define the winners and the losers.
It is rare that a company comes up with a completely new and inventive SaaS product that drastically changes the market landscape. On these rare occasions, the new SaaS product wins because the product or service is so revolutionary in an of itself.
For the rest of us, SaaS applications are primarily either an extension of existing products to the web or pure-play SaaS applications developed from the ground up for the web. For these clients, when I talk about winning, I am talking about profitability. (Note: for enterprises launching SaaS for internal use, usability and performance are key success metrics rather than profitability.)
Designing for profitability is related to, but not a requirement of, designing for good user experience. Many of our SaaS portfolio clients choose Catalyst simply to design a SaaS application with the best possible user experience for the service. We do a workflow analysis to determine the functional requirements, we analyze user behavior to simplify workflows, we refine the visual appearance, and we develop an interaction design systems with reusable visual and UI components. This is all well and good and these clients are very satisfied.
But our more sophisticated clients ask us to take things to the next level. Not only do they want great user experience, they want to know how to make their SaaS have real business value.
So what makes a winning vs losing SaaS when it comes to profitability?
The basics are pretty simple: you need a stable cost structure that is below the subscription revenue stream. You achieve this in two ways:
1) Provide a set of services that can’t be duplicated using on-premise software so you can charge premium pricing and avoid commoditization. This comes from the ability to use the internet to link together data, services, and people, all in real time and from the ability to monitor customer behavior in your application to rapidly adapt services.
2) Lower the cost of sales by automating the marketing, trial, purchasing, configuration, support and social referral processes and integrating it thoroughly into the product itself . This is the life cycle approach - taking all of the costs that are typically handled by people to support the core application, and building them as an integral part of the SaaS design.
The SaaS that is less likely to achieve profitability is the one that simply offers an on-line application as an alternative to on-premise software. It may indeed be a good on-line alternative (presumably at least RIA-enhanced). But offering an application on the web without offering a value-add that takes advantage of the real-time data/services integration or without using automation to lower cost structures, means it will be difficult to make substantial profit through a subscription revenue stream.
In late spring of this year, I received an email from M.T. Hoogvliet, a student of Interaction Design in the Netherlands. He was writing a thesis on SaaS Interface Design with a goal to develop a set of user interface guidelines for Software-as-Service web applications. He was proposing to answer some interesting questions:
- How to define a SaaS application?
- What are the key elements in designing general web-based software?
- How does a SaaS application differ from general web-based software?
- On what points does a SaaS application typically need to appeal to a user?
Hoogvliet noted that “SaaS and web application design falls somewhere in between existing guidelines for designing interfaces because two previously separate disciplines (desktop and web) are merging together in SaaS.” He also lamented the dearth of articles or literature on the topic. He contacted Catalyst Resources to ask us to identify the best practices we use for designing SaaS applications.
We shared some of our initial work around the customer life cycle approach to SaaS strategy and design. Hoogvliet integrated this with his other research to produce a comprehensive thesis offering a set of web-based design principles along with specific guidelines for designing a profitable SaaS. As a real world case study, he also developed a SaaS application to design, develop and use a CMS.
Mr. Hoogvliet has given Catalyst Resources permission to make the thesis available for download. I strongly encourage user experience and interaction designers, as well as ISVs and enterprise application developers, to review this work. The thesis will be a valuable component for a strategic analysis of your own SaaS applications plans. (Note: I recommend that anyone with an MTV-generation attention span, should jump straight to chapter 4.5 - around page 35 - to begin).
Download SaaS Interface Design - Designing web-based software for business purposes (336 KB pdf).
Feel free to comment about the ideas in the thesis or offer extensions to Hoogvliet’s analysis.
