RIA Blog Posts

I just noticed that the Velocity Online Conference is coming up next week. This conference is focused on best practices in performance and operations for web applications to improve the user experience as well as a company's bottom line.

I've written previously about the importance of perceived performance in the design of a SaaS application. 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.

But what is the empirical evidence and how much of a change in perceived performance is necessary to have a significant impact? Well I just came across some hard data - metrics for page views, amount of interaction/use and online revenue presented at Velocity 2009 from some data-heavy players.

The empirical data on the impact of web application performance

Microsoft reported that with Bing, a 2 second slowdown in response time reduced the number of searches by 1.8% and reduced revenue/user by 4.3%. That a lot of money left on the table.

Google reported that as little as a 400 millisecond delay resulted in 0.59% fewer searches per user. But perhaps more interesting, even after the delay was removed, these users still had 0.21% fewer searches, indicating that a slower user experience affected long term behavior. While Google did not report revenue directly, fewer searches likely means fewer AdWord clicks.

Shopzilla had the most complete data on the impact of performance on the bottom line. A year-long performance redesign reduced response times by 5 seconds (from ~7 seconds to ~2 seconds). This resulted in a 7-12% increase in revenue.

But it's really perceived performance that matters

This empirical "bottom line" data becomes even more interesting when it is reviewed in the context of the study 'The Truth About Download Times. This study found that users do not rate the download speeds of Web pages based on the actual stopwatch-clocked download speeds. Perceived speed is dependent on how well "users successfully complete their tasks on a site."

In other words, it's not just page load time that matters. It is the time it takes for a user to successfully complete a task that has the real impact. In the case of the Velocity 2009 data, users couldn't interact with a page until it loaded. Those few milliseconds of additional time, prevented users from accomplishing their search tasks. That signficantly impacted the bottom line.

Designing RIAs for perceived performance

So how do you design a SaaS to enable the user to perform real work more productively - to feel fast, responsive and streamlined. Our RIA designers focus on a number of application flow and design areas.

• Determine the high value scenarios and then reduce the number of actions required to accomplish them
• Minimize the need for complete page refreshes and reloads - the waiting between screens creates serious friction with the user
• Incrementally add information and functionality to a page, based on an analysis of how users process the information (e.g. load a modular component only when needed or in the background based on predictive analysis)
• Progressively download data locally to avoid round-tripping to the database (HTML 5 is a great development here)
• Validate designs (visual, information, interaction and architectural) to determine where users perceive adequate performance vs. where they get slowed down and wait for the web application to catch up
• Enable queries or actions to be canceled - it gives the user a feeling of control and lets them move on to something else they consider more important than waiting
• Add 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)

RIAs are about more than features, graphics and nice visuals. Optimizing perceived and actual performance has a real and quantifiable impact on the bottom line. The more productive an RIA/SaaS design, the more users interact with software.

Like everyone, I want to believe that cutting-edge Cleantech will provide the solution to most or all of our environmental and energy problems.  Whether it’s wind, solar,  geothermal, algae-produced biofuels, laser-powered nuclear fusion, or something even more exotic, most efforts to move the world to a low-carbon, low-resource economy view the sustainability challenge in technological terms.  Much of the dollars are flowing this way as well.

But I am increasingly skeptical.  Notwithstanding the closing scene of 1985’s “Back to the Future,” in which Doc Brown returns from the future and refuels his time-traveling DeLorean with a banana peel, beer can and other garbage, for us in the present, a universal power source that consumes our waste and garbage and turns it into clean energy to power our electrical grid and transportation needs, simply does not exist.

Moreover, even with technological breakthroughs,  Cleantech will struggle to compete head-on against incumbents in established markets. It will take time to take root and become widespread outside of niche environments. But time is one luxury we are lacking if we are going to mitigate climate change.

Sustainability as a parallel track to Cleantech

So I see the need for a parallel sustainability track focused on using software and hardware to optimize and manage existing energy and waste/resource management technology. This may not be as “glamorous” as the Cleantech vision of cheap, inexhaustible, carbon-neutral power, but it is likely far more efficacious in the short term, and completely transferable to any new tech in the long term.

As I’ve written previously, companies need to reduce their resource use and waste production in order to:  lower costs across internal operations and their supply chain; meet regulations; and document their sustainability efforts to an increasingly aware consumer.  This requires investment in and development of web applications (specifically SaaS solutions) in order to track, manage, and determine ROI of energy/resource optimization actions.

Innovating the user experience of sustainability

In contrast to Cleantech, the challenge to successfully implementing SaaS-based sustainability solutions is less about designing new technology and more about designing new ways to motivate behavior.  For sustainability SaaS to succeed we need to innovate with user experience. The basic functionality of monitoring and tracking resource use does not really change, but the meaning of the application and the way the user interacts with the application, must be unique and valuable.

Examples of user experience changing the meaning of the mundane abound.  15 years ago, organic food was associated with co-ops and lower incomes.  Along came Whole Foods which changed the experience of shopping organic. The basic product stayed the same, but the meaning and value of the product changed.

The iPod is, of course, a classic example of user experience changing meaning. The iPod was not just an MP3 storage device, it offered a seamless experience for finding, buying, organizing, sharing and listening to music through an intuitive, rich interface.

Design Sustainability SaaS RIAs to be more than record management

As we design SaaS sustainability applications, we need to design the same shift in meaning.  We need to identify propositions so compelling that the customers/business could not have possibly asked for them (user-centered design be damned). This kind of innovation is “push” not “pull” and is based on compelling vision, Rich Internet Application (RIA) design, and the ability to seek inspiration outside of current application.

Clients often ask which Rich Internet Application development tool they should choose - Flex, Silverlight, or an AJAX framework. Excitement over HTML 5 has been stirring up this question in the RIA community even more than usual.

At Catalyst we're in the business of delivering very sophisticated, responsive, interactive and graphically rich applications over the web, not pushing specific technologies. Sometimes Flex is a better option and sometimes AJAX is the better option and other times Silverlight or JavaFX is better. It all depends on the requirements, the team, and the application.

Each of these technologies have the same goal: enable delivery of a rich UI and immersive experiences with the interactivity and user engagement similar to desktop applications, but adding in the availability and interconnectivity of the web.

There are no hard and fast rules for selecting one technology over the other, however there are some rules of thumb.

AJAX - use for incremental, tactical improvements, SEO-friendliness, customizable footprint

If you are updating an existing application and want to implement rich functionality incrementally, with small, frequent updates then AJAX is a good choice. Or if you need to meet specific application footprints and performance requirements (e.g. fast initial page load time) AJAX development frameworks (e.g. jQuery, EXT JS) can be customized and tuned. Importantly you can also use Flash to fill in the gaps where you need richer behaviors, than are easy to create with AJAX (e.g. video players or real-timestock tickers).

Of course HTML 5 (supported in FireFox, Safari, Chrome and IE 8) will add to the allure of AJAX/HTML bringing local storage, multithreading, real-time data sharing, form validation, and more (e.g. 2D and 3D drawing).

See examples of our work in AJAX for Digital Advertising and Teleconferencing.

Flex - use for large-scale, more comprehensive user productivity applications

Like AJAX, Flex also can be used for gradual re-factoring of existing web applications via widgets, but the argument for Flex becomes particularly strong when an application is built from scratch, or has a high level of complexity and data processing. You get better performance (i.e. data sorting, search, display) and easier code maintainability. Also for large applications there is a definite plus with Flex in that you can avoid the necessity for testing and tweaking across browsers and OSs.

See examples of our work in Flex for Real Time Analytics and Media Advertising.

Silverlight - use if you are a .Net shop

Silverlight has many of the same arguments as Flex, except that it is geared for the community of .Net developers and offers seamless integration to .Net tools and components. Enterprises that work in .Net will find it easier to integrate interfaces and application designs created in Silverlight.

See examples of our work in WPF and SIlverlight for Financial Systems and Issue & Support Tracking.

So which technology do we choose?

We are agnostic about RIA technologies. Our developers are facile in all of the relevant options. So the general rule for us is to identify what problems our client needs to solve and then select the appropriate RIA technology. No one technology is inherently better than another. For each applications we look at the requirements for performance, interactivity, security, maintainability, scalability and in-house expertise, and then give our clients a recommendation as to the best technology or combination of technologies.

User experience designers all agree on the importance of user interface simplicity, consistency, and performance as keys to successful application design. This is particularly relevant for enterprise SaaS and RIA applications where expectations for "use without training" have been set high by consumer SaaS applications.

But one often overlooked attribute of good user experience design is perceived control. This is surprising because in many ways, a user's feeling of being in control is what defines their perception of simplicity, consistency, performance and even innovation.

Perceived control is a fundamental concept but rarely discussed and even more rarely do I see it implemented as a specific goal in SaaS application design. The basic idea is simple: the more a user feels in control of their software environment, the more satisfied they feel and the more likely they will become loyal repeat users. On the flip side, the more a user feels that they cannot control the software (because of a poorly designed or poorly validated UI), the more likely they will blame it on a "bad" application and seek alternatives.

Predictability, Simplicity, Performance, & Innovation

Designing for consistency is in large part just a way of creating predictability. Predictability is about controlling your environment. The user knows what will happen when they do something - even for the first time. It gives them a feeling of mastery and control, which is critically important to product use and loyalty.

Designing for simplicity is similarly about designing for control. Software feels simple, intuitive and easy to use when it matches a users conceptual model of the world.

Perceived performance is how responsive the computer feels to your actions. When an application forces you to wait for it to catch up (e.g. a spinning clock), you feel like you no longer have immediate control over the application and your environment. Low perceived performance can lead to low satisfaction and high customer churn, High perceived performance makes you feel in control and will result in high customer satisfaction and stability.

Innovation in UI is often in the form of discovering how to increase perceived control. Truly innovative software makes previously difficult tasks, easier to manage and complete.

Examples of applications/products that offer little perceived control: a Comcast digital remote control, Microsoft Word.
Examples of applications/products that offer high perceived control: the iPhone, Google search, many video games.

Design for Perceived Control from the Start

Levels of perceived control of course change as users gain experience with an application. But with SaaS, where it is easy for users to switch to a different service, a UI that creates the perception of control, right from the start, can reduce churn and keep customers coming back month after month.

At Catalyst we spend much of our initial design sprint developing and validating the right conceptual models that make software feel simple. We use RIAs in a way that we can optimize perceived performance. And as a company, we are uniquely focused on designing modular reusable UI which deliver consistency (as well as cutting development costs!). We recognize that perceived control is an essentail factor in user experience design and we regularly assess it in usability and user validation testing, quickly iterating to correct perceived "lack of control".

I've written a great deal about the intricacies of designing the user experience for an enterprise RIA or SaaS. These applications typically need to handle very large data sets, scale to service thousands of users, and address complex business logic that encompasses many functional elements and scores to hundreds of screens.

While many organizations attempt to develop their SaaS or RIA using their internal IT department, perhaps assisted by a web design or Flash creative firm, the end result will "feel" like it was built by an IT department. It may be functional, may even be visually pleasing, but it will not identify high value tasks, streamline business processes, increase user productivity, build the brand or drive adoption & use. To achieve this level of business value you need a UI engineering team of experts, each with a different focus, distinct skills and tight accountability.

Multi-disciplinary teams

Based on our experience designing over 270 pieces of software, the most successful projects follow a well-formulated process using a small, highly experienced, multi-disciplinary team comprised of an experience architect, experience designer and experience developer. This collaborative team then works with an organization's IT department to smoothly integrate the design with existing infrastructures and back-end systems.

Each of these primary team members needs to be facile in several different domains and take on different roles at different points in the project timeline. Below are brief explanations of some of these roles.

User Experience Architect

• Functional requirements definition - work with the product's stakeholder to define an initial set of key functionalities based on business drivers and value proposition
• User studies & ethnography - observe the actual users and usage environments in order to  refine functional requirements and document the actual user scenarios that will drive the User experience design
• Personas - create personas from the information collected during ethnographic studies. These represent typical users and help the design team keep a clear imagine for whom they are designing
• User validation - involve real users throughout the design process to enable testing the coherence of early mockups and ensure potential usability issues are identified early on
• Business process design - look for ways to organize complex business processes into simple logical structures that can be easily communicated
• UI architecture - design consistent behaviors that apply to the User Interface throughout the application. This enable the user to quickly understand, use and predict how the application will behave
• Conceptual models - define conceptual models that help users to naturally comprehend what they are trying to accomplish with the software, the kind of data they are manipulating, how the data is organized and their goals for interaction

User Experience Designer

• Information design - synthesize user requirements into interaction use cases that define a product's usage from a user's perspective
• User interface design - begin with fast, low-fidelity prototypes and iteratively develop into interactive, high-fidelity prototypes, incorporating feedback from user validations throughout to identify how "intuitive" the application is and the value it provides from extended use
• Interaction design - optimize and test navigation, control elements and messaging for user comprehension and efficient and effective use
• Branding and visual design - define the colors, graphics, fonts, motion, polish and fluidity that create the brand experience, always testing with users
• Documentation - provide screen functionality specifications  and visual design style guide

User Experience Developer

• Code clickable models - provide a full clickable model using dynamic data of exactly what that software will be like when it is released
• Presentation layer architecture - map out and validate proposed UI architecture so it is consistent with technical architecture, before writing any code
• Client side technologies - select and implement the UI using the optimal RIA for the users and IT infrastructure (e.g. AJAX, Flex, AIR, Silverlight, Java). Re-factor UI designs into a customized library of UI components, data, and actions
• Server-side technologies - translate what is going on in the back-end systems to communicate with the front-end user UI, requiring fluency in multiple languages and Web services
• Data and business logic implementation - rapidly iterate designs and systematically incorporate feedback to expose and validate that all data elements and UI components are matched to the database schema

Designing user experience for enterprise RIAs and SaaS is complex - no doubt about it. But compromises to the user experience will have a fundamental negative impact on the success of any application, so it is not something you can ignore or marginalize. To maximize business value, you should look for a multi-disciplinary team with diverse skills and tactical experience to design the application and augment the technical development work of your internal IT group.

In the previous post I posed a question that is relevant to any enterprise that delivers services via software:  where does innovation really matter and where should it come in to play when defining the user experience for on-premise or SaaS applications. In this post I want to look at each layer of the application user experience and evaluate where there is potential to deliver innovation that has a real impact on increasing the usage, adoption and social media referral of the solution by customers.

When Catalyst defines the user experience of any application, we break it down in five basic layers:

1 - Conceptual Model
2 - Functional Definition
3 - User Interface
4 - Visual Design
5 - Interaction

Conceptual Models

Conceptual models can form the foundation layer for defining the user experience.  When they exist, they help users relate the software to real world things or situations (see an earlier post on Conceptual Models in SaaS).  If you craft the right conceptual model, then you are well on the way to designing an application that not only requires less training and support, but also will be easier to market (traditional and social), have higher adoption/retention rates, and be more intuitive and productive to use.

For example, if you are creating a medical record systems, users already have a familiar and well-understood conceptual model for how to handle records.  Systems based on charts and folders with color codes labels are universal in every medical office.  This forms a solid basis as the conceptual model for the online record system.  How you design the actual UI, interacton, or the functionality you include is flexible. But in this scenario, the conceptual model and user expectations are clearly defined and not the most efficacious place to innovate.

Note: There isn’t always a conceptual model that a user can relate to in a meaningful and intuitive way. But that is a special case that can be managed by focusing on the other layers.

Functional Definition

This is the actual application functionality and features that are delivered to the user.  It is specified as part of the application requirements rather than user experience so it is generally not an opportunity for innovation.  For example, a billing application must be able open customer records and print invoices.

While the functional definition is not an opportunity for innovation, it can be a place to evaluate and streamline workflows. As part of the process for defining the user experience, you necessarily need to identify the business objectives and map the existing process. In our experience this often leads to discovering ways to address inefficiencies, improving customer service, streamline processes to cut costs, or improve reporting and analysis.

User Interface

User Interface is where you really can begin getting the most from innovation. UI is the way the software presents the functionality, the way the user interacts and the way the system communicates. RIAs (via AJAX, Flex, Silverlight, AIR, etc) enable richer, more compelling interface opportunities for creating effective and engaging experiences that drive adoption and reduce churn.

Apple (where I got my start) has built a very successful business model on providing products with dynamic and rich user interfaces.

Visual Design

Visual design refers to the style of the application - the colors, the fonts, the graphics.  A lot of this is the skill of the visual designer in how to be creative and come up with a distinct and compelling look that effectively brands a company.

Visual design is always an opportunity for innovation and consists primarily of four areas: branding, look and feel, information design (which is focused on optimizing user comprehension of actual data) and information and tone of voice. If you visit a Citibank, or Wamu ATM they have worked very hard at creating a tone of voice that is personal and helpful.

Interaction

Historically, web-based mission critical applications had a fairly limited range of interaction (click a button, select a menu, or complete a form).  However interaction using RIA provides a considerable opportunity to create more effective and compelling experiences.  Interaction itself is a very promising emerging area of innovation, as evidenced by the growing use of multi-touch screens, accelerometers, and voice interfaces.  This becomes particularly relevant giving the rapidly growing range of form factors for accessing enterprise SaaS applications.

Innovation across all layers

There are opportunities for innovation at each layer of the user experience. Obviously, this complexity means that it is unlikely for any one individual to have sufficient depth of skills to maximize innovation.  Real and effective innovation requires the combined skills of a UI architect, a UI designer, and a UI developer, working in tandem.

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.