New Business
(650) 678-6743
(800) 313-7874
Email
Offices
Silicon Valley, New York,
Vancouver, London, Milan
Type of Inquiry
* indicates required field
Required fields must be filled in!

Blog on RIAs, SaaS and User Experience

RIA Blog Posts

Back to Blog


Application Redesign in Insurance and Banking - Augment or Replace?

Posted on January 21, 2011 by Paul Giurata

image

Many financial services firms, particularly insurance and banking, are resistant to making the changes needed to enhance their competitiveness. They have made significant investments in legacy software/hardware and are wary of moving to Rich Internet Applications and cloud application services for reasons of security and performance. On top of this, most firms also have experience with big IT projects or on-premise software upgrades that have ended up absorbing large amounts of resources but not delivering business value.

Augment rather than replace

Rather than wholesale replacement of existing applications, a more manageable and risk aware approach is to design new RIAs that augment what is already in place. One of the advantages to RIAs is that they don't have to be used throughout the entire application. The richness and interactivity they provide can be applied in choice areas in order to augment the experience offered by the application as a whole.

Where to augment?

First insurers and bankers should examine the competitive factors that drive the need for application redesign. Then they work with an application design firm like Catalyst to incrementally support the most important or complex business issue. Examples factors to consider include:

  • Need to increase customer intimacy, interactivity & loyalty
  • Need to be where the customers or workers are: on the web, on mobile
  • Need to accommodate a workforce that has grown up with on-demand, easy to use applications
  • Growing demand for real-time access to information and information sharing
  • Automating and streamlining business processes
  • Need for consistent UI across applications due to Mergers & Acquisitions
  • Need to move away from paper-driven processes & reduce duplication of effort and transcription errors
  • Growing number of users per application
  • Increasing transaction volumes requiring higher performance & better visualization
  • Need to do business with a larger set of partners across the supply chain

Customer-facing applications

We have worked with many insurance and banking firms facing these challenges and often the most "bang for the buck" is to focus first on redesigning customer-facing applications.

Customer-facing applications provide direct access to tools for in-house decision makers, agents, sales teams and call center staff, from their web browser or increasingly, their mobile devices. External customers, the end consumer, can also use self-serve tools and navigate on their own. The customer should be in control, by adding a flexible user experience layer on top of your existing IT infrastructure.

Agile design process for substantive short- & long- term wins

Initially, the focus is on delivering the applications to support the highest value scenarios with simplicity, accessibility and convenience. It is also essential that these design address scalability, modularization, dependency management and performance tuning. The delivery process should be lightweight— with a delivery of usable production quality software every few weeks, so that end user feedback may be obtained for quick refinement of the solution.

The end results of the new application design improves customer interaction and increases agent loyalty. Modular design systems improves time to market for new add-on services. Delivery via the cloud increases availability and reduces costs.

HTML5 in 2010 - think the design of mobile apps

Posted on August 05, 2010 by Paul Giurata

image

Undoubtedly you have heard about the great RIA war raging between Apple and Adobe. Apple claims that HTML5 is all you need for web applications and Flash has no future. Adobe shoots back that Flash is the best choice today and claims (not entirely convincingly) that it will remain relevant 5-10 years from now. So how do we make sense of this brouhaha as it relates to our own work designing SaaS and Rich Internet Applications for the Enterprise?

The enterprise desktop of 2010 relies on non-HTML5 desktop browsers

Regardless of what the future will hold, the reality is that in 2010, there is an enormous installed base of IE 6, IE 7, and IE 8 on the desktop - particularly in the Enterprise (with governments typically frozen on IE6!).

Consequently, for Rich Internet Application design work intended for Enterprise desktop web browsers, it is a non-starter to design solutions that don't run on IE7 at the very least. For this RIA market, HTML5-related technologies (see below) are simply not yet viable.

RIAs designed with Flex for the desktop user

For Enterprise web and SaaS applications, by far the majority of RIA work that we do is in Flex (Adobe's RIA platform based on Flash). It is predictable, has a good development environment, is scalable, and provides good performance.

What about Silverlight?

I should also note that we do a growing amount of work in Silverlight 4, particularly for desktop/surfaces/large display multi-touch and gesture applications.

RIAs on the mobile devices of 2010 = HTML5

But when it comes to mobile devices, it is a completely different story. On mobile devices over 90% of the smartphone and tablet market in the US (Apple, Android, WebOS, Rim soon) use the HTML5-savvy WebKit framework for the browser. Consequently our RIA and UI design work for mobile (smartphones and tablets) is increasingly HTML5 and associated technologies.

Key Features of HTML5 and associated technologies

For those who are interested, I just want to quickly note some of the most compelling aspects of HTML5 and the collection of technologies that almost always go with it (Note: I'm not breaking out which are core HTML5 vs associated tech). This list is not at all complete - it just references some of the things I think have intuitive appeal to both technical and non-technical audiences.

  • Semantic Tags - for more meaningful markup that is great for search, accessibility and coders
  • Audio and Video Tags - for plug-in-less audio and video with native controls
  • 2D Canvas and Animations - for rich dynamic Flash-like graphics, animations and effects
  • Geolocation/Location Awareness - makes the mobile device's geographic location available to a web application
  • Offline Application Caching - cache an entire Web application for offline use so mobile users can access and interact with a Web app even outside of a coverage area
  • Web Storage - allows information to pass between pages in a session or even across sessions
  • Web Workers - enable developers to parallelize web application tasks for multi-core processors (mutli-core are not yet the standard for mobile devices but probably will be within a year or so)

Android, iPad, iPhone and Beyond

As a rule, Catalyst is technology agnostic. We design applications and UI for our clients using the technology that is optimal for their market and that is manageable by the organization's development team. For web applications intended for desktop users in 2010, this typically means Java, Flex or Silverlight. For applications and web applications intended for mobile users on the iPhone, iPad, Android devices, WebOS, and soon Rim and Nokia, this typically means HTML5 ( with fallback content adaptation for other mobile devices).

What makes Catalyst Resources tick? What is in our DNA?

Posted on May 13, 2010 by Paul Giurata

image

I recently attended an event on social media and application design. I got into a conversation with another attendee and asked him what he did for a living.  He paused and then answered “I help good companies let others know how good they really are”.

It was an odd answer, so I asked more:  “How do you do that?”. He then went on to explain how he developed web sites, wrote content, optimized SEO, and did the whole social media thing.  It sounded like all of the mechanical things that so many other consultants and agencies say they do. But his initial description intrigued me because his description gave me his purpose for what he did, the ‘why’ rather than the ‘what and how’.

It started me thinking about Catalyst Resources and the way that we describe what we do.  Sure we design Rich Internet Applications and efficient, aesthetic interfaces. We even refine this further by specifying our focus on mission critical applications and modular, reusable UI.  But this ‘what and how’ is not the motivator that actually makes us wake up every morning and go to work.  It is not the ‘why’ we do what we do.  It is not the essence of our DNA as a company.

Why we do what we do at Catalyst Resources is because we believe that we can fundamentally improve the efficiency and the “pleasurability” of any business activity.  The ‘what and how’ is by optimizing business processes, streamlining workflows, creating user-validated, high-performance, modular user interfaces and designing beautiful, intuitive and streamlined Rich Internet Applications.

When I am brought in on a new project I don’t immediately start thinking about what I am going to do from a UI or an application design perspective.  I think “what does this company need in order to be more successful”.  Coming up with this takes a lot more work and a lot more creativity then coming up with a well-designed set of UI elements.  But it is this goal that is the real inspiration behind every project that Catalyst undertakes.

Maybe we need to come up with a tag line: Catalyst Resources - we make the world better, one application at a time.  Kind of has a nice ring.

Real-time systems, mission critical applications and RIA requirements

Posted on April 08, 2010 by Paul Giurata

image

I often talk about how mission critical applications have unique requirements when it comes to RIA and user experience design. Broadly speaking mission critical applications require a combination high-performance, at-a-glance clarity, security, redundancy, scheduling, reporting and scalability.

I was explaining these characteristics to a client looking for an RIA front-end design for their green energy production system. I found that the easiest way to explain some of the real-time design requirements was to give examples from our own client work. I thought I would share a few of these from that conversation.

Example requirements for mission critical UI and application design

Scheduling - Trading systems
With most application, when you make a change to a preference of function, you save the change and the change is applied then and there. With international trading systems affecting large $$ trades/data, you need to be able to make changes and then precisely define triggers or schedule when these changes are applied.

Reporting and Tracking - Financial transaction processing
With mission critical applications there often needs to be an audit trail for changes to data, system settings and transactions. For example when changes are made to the interest rate on credit card there needs to be a non-alterable record that tracks who did it, when, and why.

Clear Conceptual Models - Flight planning
Complex or mission critical systems needs to designed it so that the user knows exactly what they're interacting with. In flight planning, the FAA uses a very particular type of document which is drilled into to every pilot or controller. The RIA interface for a flight planning application had to be modeled tightly around this existing model so it was immediately interpretable.

At-a-Glance Clarity - Telecommunications processing
Imagine a system with 200,000,000 transactions a day. The visualization and reporting system needs to be designed to represent mass volumes of things happening with automatic callouts and quick ways to drill down.

Privacy and Security - Medical diagnostic collaboration
While security is vital in every enterprise, security in medical records is a hot button item right now. Web-based medical records and collaboration applications need to have clear options to define roles, access levels, recurring re-validation requirements, and multiple layers of protection.

Redundancy and Validation - Emergency notification
For most web applications, it is standard to have simple error checking for things like entering an invalid email address. But advanced validation and redundancy become vital in mission critical applications. For emergency notification systems that trigger emergency first responders and can impact the physical well-being of many individuals, any alert messages need to have built in redundancy (i.e. you can't accidentally send out a notification without confirmation) and geospatial validation (you can't inadvertently send out a notice to residents in San Francisco about a threat occurring in Seattle).

Scalability - Insurance M&A
Scalability is desirable for any enterprise where there is an expectation for growth and change. But this was critical for an insurance carrier that grew rapidly due to acquisitions. The user base was to expand several orders of magnitude in the course of a very short time and the application would need to scale to accommodate the increased demands without requiring rework.

High Performance - Fuel management
Real-time reporting and high performance applies to virtually all mission critical applications. But when I was discussing this with the green energy company, rather than discussing our work in financial systems (i.e. where it is easy to see how even seconds of delay can translate to millions of dollars in impct), I instead referenced real-time remote monitoring, management and incident reporting of critical fuel supplies - such as in power plants, backup power systems, emergency fleets vehicles. As inventory drops or there is a change in the status of a critical fuel system, many actions need to quickly and automatically come into play to avert catastrophic failures.

Designing RIAs that address these mission critical requirements is not simple. In addition to the technical demands, it requires extensive user validation and testing as well as an understanding of the inner workings and organizational structures of large enterprises. Needless to say, it makes for very interesting and challenging work.

Does perceived performance really impact the bottom line for web applications

Posted on March 08, 2010 by Paul Giurata

image

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.

Rich Internet Application agnosticism - Flex vs Silverlight vs AJAX / HTML5

Posted on November 17, 2009 by Paul Giurata

image

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.

The importance of perceived control in SaaS, RIA and user interface design

Posted on March 18, 2009 by Paul Giurata

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.

A Comcast remote control as an example of not being able to control the software or hardwareBut 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".