Principles of User Experience Design for Climate Change Energy Adaption Applications - Part II

We are going through a very unnerving financial crises in the US . Everything is in flux and the ramifications will be significant across the business world in general, and companies that deliver solutions via software, in particular. 

With credit scarce and future sales unpredictable, many companies are thinking about hunkering down and going on life-support. But a bunker mentality may not be the best approach, if,  at the end of this turmoil (and there will be an end), you want to end up ahead of your competition.

To the contrary, if you have been thinking about updating your software applications or moving to SaaS, now may actually be the time to invest and make your move - but do it wisely.

Even if the financial crises had never occurred, the rate of economic change requires a shift in how enterprises roll out new technologies and services. They can no longer afford the traditional sequential model of needs analysis,  requirements documents, design, code, debug, beta test, grand rollout.  By the time the new service, product or campaign is rolled out, the world has changed and the service no longer meets the current market demands or competition. 

Big software projects get the ax

But it’s not just time-to-market where traditional software development projects tend to get bogged down or fail.  As a rule, large, sequential software projects are not predictable, they come in late, they cost more than anticipated, the risky development stuff happens at the end (where it is harder to change), and the users are unhappy with any software that does get delivered.  In a time of economic crises, these projects get the ax (and they should).

Adaptive, agile development

But there is a better way - one that does not require a total cutback on all software development projects.  Instead of projects that follow the analysis-document-design-code-test-rollout sequential model, develop projects that use rapid iteration to deliver early and frequent releases, adding features as needed. You might end up with only a small percentage of what would be in a traditional needs assessment.  But you release quickly, get users in the loop right from the beginning of the design, and update frequently based on user tracking and analysis.  Projects are fast, reliable, and affordable.  Moreover if built correctly, they are scalable, so that as you grow, the software can accommodate new users without you having to add new staff.

This “agile” approach is particularly suited to SaaS application design.  At Catalyst, we typically look at a user-validated design of a SaaS application with proof of concepts in 4-8 weeks, with rollouts and updates coming every 90 days.

Optimize human capital

SaaS also can be designed to address a touchier subject in unstable economic times - staffing.  Human resources are still the greatest expenditure for any software application company.  By addressing the full customer life cycle as part of the SaaS application design, you can significantly reduce the human costs.  Put the acquisition, customization, provisioning and support workflows in your customers hands as part of the SaaS application design, instead of opting for a big high touch sales or support process.

The strategy I am suggesting for SaaS application design is both cost contained and predictable. User validation is an integral part of the design so you know in advance that the product will be of value to users.  The design will also scalable for when growth does reoccur.

Use this (euphemism coming next) “financial transition period” as the impetus to adopt an adaptive enterprise application design and development model that will work well now, and work really well when the markets recover.

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.