Rich Internet Applications (RIAs) are about a lot more than dazzling interfaces for consumer web sites. Don’t get me wrong - consumer sites that offer purchase recommendations, dynamic shopping carts, streaming video,  photo editing, etc.  are great - amazing actually!

But what excites me is when RIAs are used in the enterprise space. When designed and applied appropriately, they become synonymous with improved business processes. 

By RIAs, I mean web applications with the features, functionality and responsiveness of traditional desktop software.  These can be implemented using a variety of asynchronous technologies including JavaScript/AJAX, Flex, Java and Silverlight. Clearly, Software-as-a-Service (SaaS) applications would be hard-pressed to exist without some form of RIA.

For enterprise SaaS, RIAs can offer role-based and process-oriented front ends to the internal business systems and workflows of a complex organization. They close the gap between the native performance / look & feel of on-premise enterprise software and SaaS deployments that can be accessed anytime and anywhere. 

‘Enterprise RIAs’ typically need to handle very large data sets, scale to service thousands of users, and deal with complex business logic that encompasses many functional elements and scores to hundreds of screens. This is the scale and complexity you’d expect to find in large, transactional applications, such as credit card services, logistics processing, payroll, or large commerce sites.

Designing an enterprise RIA is of course, significantly different then designing a consumer RIA. It is not necessarily a matter of better engineering or more innovation (although that is what we strive for!). But consumer applications generally do not pull data from multiple applications, do not require development of hundreds of inter-related screens, nor so thoroughly encapsulate improved business processes.  Because of this complexity, any strategy for implementing enterprise RIAs in a SaaS, needs to focus on real business goals, cover the full SaaS life cycle,  and clearly outline how existing back-end systems and RIAs will work together to make it easier and more intuitive for users to accomplish high value tasks. 

By now, most enterprises are exploring some sort of move to an on-demand delivery model that will supplement or replace their on-premise applications.  But given security and reliability concerns, many are not ready to make a wholesale commitment of their most sensitive systems to the cloud.

Instead they are replacing components of on-premise applications with SaaS, often as a hybrid deployment or in a pilot project.  SaaS acts as a supplement - not an immediate substitute - for existing applications.

Pilot projects seem like they should be easier to implement than a full SaaS. However, the same missteps that can doom a full SaaS implementation, are often amplified in a SaaS pilot project.  It is not uncommon for Catalyst Resources to be called in after a company has already invested significant resources into a SaaS pilot and are now struggling to “make it work.”

The fundamental problem is that the pilot project is addressed as a traditional software engineering challenge focused on developing core application features (vs the set of user experiences that define the service) and use of top-down engineering practices (vs agile, iterative development)  The result is internal conflicts, missed deadlines, frustrated senior management, and a web app that is no one is going to use.

With SaaS, whether creating a full implementation, hybrid components, or pilot project, there must be a very tight coupling between product design, development, business strategy, marketing, training & support, adoption campaigns, and online operations. The pilot project needs to address the organizational changes at the same time as the software changes.  The approach can be particularly challenging for companies that are engineering-driven.  But with SaaS, where the product is a service and user experience is the key to adoption/retention, it is essential to look beyond piloting just the product features, and instead, pilot the full software-as-a-service life cycle.

For most organizations, the writing is already on the wall - business applications are moving to the web as Software-as-a-Service (SaaS), enabling companies to accommodate a distributed and mobile workforce. Typically mobile has meant laptops. But as users become accustomed to web-based business applications, companies will will increasing adapt their mission-critical SaaS applications for handheld devices such as the iPhone and Blackberry, or smartphones that use Microsoft, Symbian, Palm or Android mobile OSs.

In a previous post, I wrote about best practices for designing enterprise SaaS applications for a diverse set of devices with variable screen real-estate, input devices, processor speeds and server access speeds. Tracking on these principals ensures that a SaaS implementation delivers an optimized business solution no matter whether the user is at their desk, at home, in a hotel, or waiting in line at Starbucks.

Below I have catalogued some of the recent SaaS offerings on mobile devices. End users will be the ultimate judge of their utility.

This list is not intended as a comprehensive cataloging by any means. But it does make it clear that mobile SaaS has established a beachhead, across a range of horizontal and vertical markets. It is an area in which we are actively working as a company and something I find particularly engaging.

By now everyone has heard that Google has taken the wraps off of it's "GBrowser" project and released a public beta of Chrome. While many people speculate that Chrome is a rekindling of the browser wars, the reality is that Chrome is a move to accelerate the development of advanced Web applications, Cloud Computing and the SaaS market in particular.

Let's first acknowledge and then move beyond the "Google is reacting to XX" hypotheses:

1. Google is reacting to IE 8 - basically Google sees IE 8 as a threat to the open web and is releasing a browser that is secure, speedy and will adhere to web standards.
2. Google is reacting to Adobe Flex/Air - Adobe has been trying to position Flex as a more capable replacement for AJAX and Java. The Chrome browser promises uber-competitiveness with  AJAX super-responsiveness and it's own Air-like solutions. Moreover it uses open standards so it ends up leaving Flex and Air to be proprietary also-rans.

These are both very reasonable rationales for Chrome. But I believe Chrome is actually an aggressive/offensive and strategic move by Google to speed broader adoption of SaaS and Cloud Computing.

Chrome feature set is geared toward Web apps

Here are some of the more relevant Chrome technical specs:

• Web applications/sites run in tabs as their own process and can run in parallel (like modern desktop apps)
• New multi-threaded (i.e. process several JavaScripts at once) and fast (compiled) V8 JavaScript engine designed to run full applications rather than just tiny widgets
• Each tab is sandboxed so it is more secure and crash-resistant (e.g. a problem in one tab/web application won't bring down the whole browser)
• Gears toolkit, included in Chrome, lets developers create applications that can be used offline, synching data with the Web when an Internet connection is available - blurring the line between Web-based applications and desktop applications
• Designed with WebKit (same as used in Android Mobile OS, Safari on desktops and iPhone, Adobe Air, and several Nokia phones) so it is desktop and mobile savvy
• Memory management, garbage collection, etc.

An engine to speed broader adoption of SaaS and Cloud Computing

Essentially Google is upping the performance, security, stability, and sophistication ante. The ultimate goal of Chrome isn't to be a standard web browser, or as some have speculated, a Web operating system. Rather it is intended to be an engine for the next generation of enterprise Web applications.

Chrome will not displace IE or FireFox as a browser for displaying pages - most consumers cannot even be bothered with updating from IE 6 to IE 7, let alone downloading a new browser to read their favorite blogs! But for Google the browser has been the weak link between the user and it's powerful data centers. By retooling with Chrome, they create a multi-tasking web application engine for professional users, that can make Web apps virtually indistinguishable from desktop apps. And it can also do double duty as your everyday browser.

The lure of web applications that are high performance, cross-platform, cross-device, and secure (process separation and filters for malware) will be sufficient to move many more corporate or SMB applications "into the cloud". And since Chrome is still using JavaScript, applications developed with Chrome in mind, will still perform well with "traditional" browsers.

Google is not alone

I should point out that Google is not alone in this move to high performance JavaScript. Apple is upgrading WebKit with the SquirrelFish bytecode JavaScript interpreter. FireFox 3.1 will incorporate the Tamarin JIT-compiling JavaScript virtual machine. Both will increase JavaScript performance by an order of magnitude to enable complex applications that were previously impractical over the web. With Chrome available as open source, I would not be surprised to see both Apple, FireFox and even IE, embrace and extend Chrome capabilities into their own platforms.

Regardless of Chrome's ultimate market penetration, the release signals a compelling shift away from thinking about the Web as a collection of pages, to a cloud platform for running enterprise-level web applications and SaaS.

I recently updated my laptop to a top-of-the-line system with an Intel Core 2 Duo running at 2.5+ GHz. This is technically five times faster than my laptop a few generations back. But while it is certainly zippier, it doesn't feel five times faster.

This type of mismatch between raw technical performance and perceived responsiveness is actually very common in the computer world. While the processor and bus speeds increase, there are many other factors that go in to how we perceive actual performance.

One of the most significant factors affecting perceived performance is how responsive the computer is to our actions. A system seems to grind to a halt when an application doesn't respond to our mouse clicks. With two applications, both taking the same amount of time to complete, the one that blocks user input or displays a blank screen reloading will definitely be perceived as having poorer performance and be less usable.

The discrepancy between technical performance and perceived performance can be especially notable with web applications, and SaaS applications in particular. Perceived performance is not a linear function of the speed of the CPU, the power of the software architectures/hardware, or the speed of the internet connection. Rather perceived performance is dependent on how effectively a SaaS enables users to complete high value tasks.

The study 'The Truth About Download Times' clearly supports this tenant. It found that users do not rate the download speeds of Web pages based on the actual stopwatch-clocked download speeds. "There was no correlation between these (the actual speeds) and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds)." The authors noted that perceived speed was dependent on how well "users successfully completed their tasks on a site."

Even if you get the technical parts right

In the case of designing for SaaS, the perception of performance can be controlled by several factors beyond getting the technical platform right. For example (in no particular order):

• streamling the work flow (not just making it efficient, but actually finding out what users want to do, and making that efficient)
• using AJAX or Flex RIAs (Rich Internet Applications) to minimize the need for complete page refreshes and reloads
• using RIAs to incrementally add information and functionality to a page, based on an analysis of how users process the information
• using RIAs to progressively download data locally to avoid round-tripping to the database
• validating designs (visual, information, interaction and architectural) to determine where users perceive performance vs. where they get slowed down and wait
• enabling queries or actions to be canceled
• adding reliable indicators of progress on activities (i.e. don't let users get frustrated in front of a screen not knowing how long something will take)

More than a magician's sleight of hand

These are not just "tricks" to create the illusion that the system is running faster. A well designed SaaS application truly enables the user to perform real work more productively. For SaaS, where customers can easily switch to another provider, user satisfaction is critically important. Low perceived performance can lead to low satisfaction and high customer churn. High perceived performance can result in high customer satisfaction and stability.

Optimizing perceived performance also brings another benefit to SaaS. SaaS applications designed to deliver high perceived performance can scale (i.e. add more users) without necessarily increasing infrastructure costs. As described in a previous post, scalability is the key to SaaS profitability.

I was recently asked an interesting question from a prospective new client. They wanted to know how we could successfully design mission critical software across such a tremendously diverse range of applications - from detecting cancer cells, to completing bond trades to, to generating payroll to notifying college students of emergencies. The answer is deceptively simple - we focus on what we call “high value scenarios” and systematic user validation.

In previous posts I’ve written about about high value scenarios as a key component to profitable SaaS application design.  Working with high value scenarios not only minimizes time to market, it also helps to manage risk and maximize business value. So what do I mean with the term “high value scenarios”?

From 1000’s of use cases, there are typically less than 10 key user scenarios

High value scenarios are the primary centers of mission critical activity within a software application. They represent the core value that the software offers to the user and to the organization.  While most applications are based on hundreds or even thousands of use cases, there are typically less than ten key user scenarios, from which users gain the most value.

A good example is at a modern ATM. Even though most ATM’s enable a variety of functions such as get cash, make deposits, transfer funds, print account statements, and buy stamps,  the high value user scenario is simply “Get Cash”. The user experience for a quick and easy cash withdrawal is the “make or break”  activity that defines the success of the ATM.

Identifying “Get Cash” as a high value scenario at the ATM seems obvious.  But such easy identification is not always the case. It is certainly not usual for an organization to be unaware of their own high value scenarios.  Organizations are pulled in multiple and often competing directions by IT, marketing, sales, and upper management. This makes it challenging to objectively distinguish between high value scenarios and departmental feature wish lists.

So how do you identify high value scenarios?

Discover, optimize, & re-validate

We follow a formal and systematic approach to identify high value scenarios by working with real users, studying their use context, objectives, and how they carry out tasks. Our initial focus is to identify high value scenarios and validate these with users.  Then we define a work flow and optimize the experience for that scenario. Finally we re-validate the optimized application design for that scenario.

For example, for a recently completed trading application, we modeled the core experience around submitting the “trade ticket”.  Users understood and were focused on this time-sensitive activity.  All of the other services could then be “tucked” in and made accessible around this principal high value scenario.

High value scenarios and systematic user validation can be applied with equal efficacy across any industry, for any particular application. The benefit to the organization is actionable information that can be used to make better business decisions in both product development & marketing.  The benefit to the user is that the application becomes inherently engaging and tuned for the real work.

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.