RIA Blog Posts

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. 

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.

Several years ago, we developed a web collaboration application, primarily for use by our own distributed teams and a few select clients.  This application allowed us to share project files, and coordinate team activities online. One immediate benefit was that it cut down on the volume of email back-and-forths.  All documents that required review or approval were simply posted online in a team or project workspace. This also made it feasible for employees to telecommute.

In the last year or so, we have been making an active effort as a company (and individuals) to go green and reduce our impact on the environment. We are working to be certified by the City as a green business, doing the standard reduce/recycle/reuse things including using CLFs, buying recycle paper, composting, using low-toxic cleaners, encouraging public transportation, etc.

As part of this green effort, we started tracking how our our web collaboration solution was reducing our carbon footprint by replacing the need for air travel and local commuting. The initial results, based on just our own staff and a few clients, were so encouraging that we decided to enhance the web collaboration solution and provide it to our entire client base.

We knew that our clients would be intellectually supportive of a green initiative. But reality was that they were already familiar and comfortable with email, face-to-face meetings and hard copy documents. If we were going to be successful at getting them to adopt web collaboration as a preferred way of doing business with Catalyst, we would have to provide a better user experience and enhanced productivity as compared to the incumbent solution.

We redesigned the application as a multi-tenant SaaS giving each client their own team space, with 24-hour, anywhere access.  We also developed a user-validated RIA interface that minimizes the training requirements, provides high performance, and is natural to use. Clients can configure their team space to incorporate their own branding, as well as their own industry-related terms and language.

We deployed this to seven clients located throughout the US, as well as our own employees. Then we tracked our travel, monthly expenses and billable hours compared to previous months.

After implementing the new SaaS RIA web collaboration solution, Catalyst was able to reduce business travel and commuting across seven clients to achieve an average CO2 reduction of 21,000+ lbs per month. (roughly the amount produced by 3 US households in one year). In addition, in one month alone, Catalyst saved 70% in travel costs and increased billable activities by 20%.

We are excited by this initial data and will continue to enhance our web collaboration/team space solution.  Needless to say, we will use it automatically with all new clients as well as our growing staff.

There was plenty of coverage the past week about the new SproutCore HTML/JavaScript framework that was used by Apple to develop their MobileMe site.  “A SproutCore application is a JavaScript application that runs entirely in the web browser. It can often run on its own, without even needing support for a web server except when it makes sense for the application. This frees the server developer to focus on the things the server can do very well such as saving, restoring and aggregating data and performing expensive operations. Meanwhile the ‘thick’ client running in the web browser can handle the task of presenting the user with a friendly interface that is fast and intuitive,” from the SproutCore Web site.

What is interesting is that the description of SproutCore applies to any RIA stack - HTML/AJAX, Flex, Silverlight, Curl or any new flavor that comes along.  RIA is now the defacto standard for web application deployment.  This applies to applications ranging from simple e-commerce sites, to desktop widgets, to full blown enterprise applications delivered as SaaS.  The particular application develop platform an organization should choose should depend on two things:

1. The core technology for your application (typically .Net or Java). The core technology is driven by a much broader set of issues than just the presentation layer. If you already know what the core technology will be, put a stake in the ground to constrain your evaluation of RIA platforms. We have seen very few teams be successful in delivering an application within the required scope and schedule requirements when the team had to change to an entirely new technology base.
2. The primary device and platform where you plan to deliver your application (e.g. public web, in-house, iPhone, desktop widget, combined off-line and on-line interaction)

Lately we’ve done a lot of work with Adobe Flex because it met specific client needs (e.g. bidirectional network sockets), it is very good at media handling, it is fast to prototype and develop, and it is scalable. For SaaS, we can build smart, adaptive, and reusable interface and data handling components. These can be used in the core application as well as with all the supporting services delivered in software (e.g. billing, provisioning, configuration and support).

Most of our financial services, insurance and banking client work has used GWT and BackBase.

As we develop more applications specifically targeting mobile devices in the enterprise, we will be adding SproutCore to our list of AJAX/HTML solutions.

Regardless of the platform or technology, this is an exciting time to be developing enterprise applications.  The business value of user experience is no longer a hard sell.  Companies get it!  The success or failure of an enterprise web application or SaaS deployment is dependent on using RIAs to deliver compelling, addictive and productivity-enhancing user experiences.

Back in April I was interviewed by the American Bankers Association (ABA) Banking Journal for a feature they were writing on how banks and financial services firms were beginning to adopt RIAs and modernize their web presence into a full-service channel. I explained how our clients have used RIA features to drive business and help enhance self-service capabilities.  In the last month, I’ve seen several other news stories on similar topics.

RIAs

ReadWriteWeb noted the significance of RIAs to banking in their post about a survey of 1000 Facebook users (admittedly a young and tech savvy audience, but definitely the future of banking).  Almost half of respondents said they would use secure gadgets for personal banking if their bank offered it. A little over one quarter said they would consider switching to another bank that offered Web 2.0 gadgets for online banking.  With Gears or Adobe Air this could be extended to the offline world.

CNNMoney referenced Mint.com, an AJAX-based web application built for consumers to manage home finance - a service gap that banks have left open. Mint is particularly notable in how it delivers an RIA/Web 2.0 style experience that gets adults immersed in managing their finances the way teenagers immerse themselves in playing a video game. Mint is also highly viral - customers become advocates and evangelists for the services. This level of RIA user experience will be a requirement for any financial institution that develops their online presence.

Using RIAs and web services, financial institutions can integrate online banking, electronic billing and payment, and value-added services such as graphical tools,  and cash flow forecasting into an end-to-end solution. Moreover, the same web services that push electronic banking and bill payment functionality to the online channel,  can also push services to mobile devices, ATMs, teller stations and call centers. Reusable interface components can be built once and shared across these different channels. Componentized, re-usable UI will increase the probability of customers trying new services, reduce training / support, simplify regulartory compliance, and save significantly (as much as 85%) on application front-end development cycles.

Part II of this post will look at how banks and financial services firms can add SaaS into the mix with RIAs, to offer corporate customers, departments within organizations, and SMBs a diverse portfolio of services, that will effectively engage existing customers and lure new customers from other services.