User Experience Blog Posts

The goal of business process reengineering (BPR) is to redesign how an organization conducts business in order to improve critical measures of performance such as cost, quality, service, and speed.  A company can spend a great deal of money on consultants to develop an implementable BPR retooling plan. But if you are are migrating your application to SaaS, BPR can be a natural “by-product” of the user interface/application design process.

Typically, application design and UI are viewed as a medium to access a software’s functionality. But optimizing the user interface for a SaaS or business application is not simply about enhancing usability. The UI is also the tangible part of business process itself.  The way a user interacts with the application should tightly map to the workflow and business objectives.  Streamlining and validating the application UI necessarily means streamlining and validating the business process.

For example, Catalyst was tasked with the redesign for the UI of a bond trading application that handled billions of dollars in securities a year. As part of the application design, we re-evaluated the real-world workflow corresponding to the business scenarios of trading bonds. We worked with stakeholders to identify the business objectives and map the existing process. By focusing on high value scenarios and applying the right conceptual models as a foundation for the UI, we were able to not only streamline the number applications screens,  but also could help the firm streamline the process in the real world. (i.e BPR).

Importantly, the user-validation techniques we applied to the UI, could also be applied to the change in business processes. With UI and processes tightly coupled, we could iteratively refine both to quickly achieve meaningful business enhancements.

The factors that drive companies to understake BPR - addressing inefficiencies. improving customer service, streamlining processes to cut costs, or improving reporting and analysis are also the by-products of well-designed user interface and application design. This is particularly true in the design of SaaS applications, where the focus is on providing a service and addressing the full customer life cycle.

This year’s downturn economy is forcing many organizations to choose between offering software solutions that “stay the course” or those that “adapt and embrace change”. For many companies, it is difficult to pull away from a traditional business model that’s been profitable, even though they know that the model faces significant threats and that profitability will wane.

The quintessential business school case study for this phenomenon is Kodak. Kodak tried to hold on to their profitable traditional film business long past the point where the signs were clear that digital photography was a threat and was going to overtake their existing business. They ignored the red flags and rode their business into the ground.

Software as a Service (SaaS) is another example of a fundamental threat to an old way of doing business. On-premise enterprise application vendors run the risk of pointedly ignoring this threat long enough to end up hurting their viability as a business.

Some enterprise software providers actually use the current economic crises as a justification for the decision to “stay the course”. They rationalize that they just don’t have the money and resources to invest in a new SaaS application or that with today’s market they would need to lower their SaaS pricing, so better to wait, until they can charge more. Instead they try to extend the lifespan of their current on-premise software by marketing it with terms like “tried and true, “stable, “tested, secure.”  But marketing to customers’ fears can only trump a software wave for so long.

The reality is that now is the time to be investing in SaaS. But the reality is also that SaaS will require fundamental shifts in how a company does business. ReadWriteWeb recently published an article on how some of the big players like IBM have embraced SaaS. What I found most interesting in their post was some of the reasons they gave for why on-premise vendors so want to avoid SaaS.

• Putting SaaS financing on an old product is simply the ASP model and that is terrible economics. You will report horrible results to investors for a long time before it turns positive. In other words, you can’t just port an existing product to SaaS, you have to design for SaaS, focusing on multi-tenant architecture, high value scenarios , the right conceptual models and the full SaaS customer life cycle.
• However carefully you position your SaaS offering versus your traditional product, you will legitimize SaaS to your conservative clients and hasten the decline of your traditional business. Sad but true. A user-validated, well-designed SaaS that is always on and available, from any location, will definitely capture the attention of even the most risk-averse “I hate change” customer. So while it may impact your on-premise software business,  it is better that the SaaS solution comes from you, rather then have your customers find it from your competition.
• Your current client base is not much help. You need to position the new SaaS offering for a new market, where you will be competing on a level playing field with the start-ups. Basically this means you need to be nimble, you need to use agile development techniques, and you need to think of innovation, not as new features, but as application design/UI that increases the usage and adoption of your solution by current and future customers.

Of course a move to a SaaS model is not an all-or-nothing, off-then-on proposition.  Many companies can offer hybrid solutions that help their customer bridge on-premise and on-line solutions. But regardless, now is the time to be exploring SaaS and acting like an agile start-up. Take the lesson of Kodak to heart and don’t stay the course.

Location, location, location. We are used to hearing that mantra when it comes to real estate. But location and geo-analytics can play an important role in many SaaS applications as a way to analyze data, manage resources, and provide tailored services.

What spurred me to blog on this topic, was a series of recent news items, all focused on the increased use of location information for mainstream business:

• The rapidly growing range of interactive mashup services for consumers, government, and businesses that combine maps with all sorts of data from a variety of sources (e.g. all of the apps you have seen integrating Google Earth, Google Maps, or Microsoft Virtual Earth).
• The extensive list of pilot projects using Radio Frequency Identification (RFID) for enterprise supply chain management to improve the efficiency of inventory tracking and management. (RFID tags are essentially tiny radio transmitters that get attached to supplies, products, transportation vehicles, & even employees).
• The introduction of geospatial technology into PDFs for collaboration and self-service access. Adobe has determined that location information is of sufficiently great interest to enterprise organizations and government agencies, that they have built geospatial mapping into their main cash cow software, Acrobat.
• Most of the "killer apps" that were winners in Google's Android Developer Challenge were focused around location using GPS (Android is the new open source mobile OS from Google coming out first on the G1 from T-mobile).
• Firefox 3.1 has implemented the W3C's geolocation API. This will give users the option for web applications to deliver tailored information based on their current location - for the laptops, desktops, or mobile devices.

While each story addresses a completely different area of application, they all share a common theme that location-based services can play a productive role in business. Not only can they provide real-time visibility into a company’s performance (i.e. business intelligence), but they can be used to tailor information to individual users via their current location.

An intuitive lens onto complex data

Adding location intelligence to your SaaS can be basic as designing an interface that looks at your sales and performance data through the lens of a map. For supply chain, inventory, ERP, CRM, order fulfillment, and logistics, a map UI can provide significant insights into large amounts of data that would be difficult to discern from a spreadsheet or statistical analysis (e.g. clusters, holes in coverage, boundaries, overlap with other factors, etc). A user-validated map interface can quickly help to answer tactical questions such as “where are my customers and revenues vs. my sales force and competition?”

Analytic services designed for non-specialists

A SaaS can also be designed to integrate with a geospatially-aware on-premise backend (e.g. Oracle Spatial, ArcGIS) so a user can make analytic queries such as “show me the stores with sales > X AND which are within 10 miles of competitor Y”. Of course, a GIS specialist can do this kind of thing now using on-premise GIS software. But for this technology to be applicable to mainstream business, it needs to be available online, with an interface that exposes the high value scenario actions and queries for non-GIS experts.

Mobile SaaS enhanced by location

For mobile SaaS applications, GPS (or at least triangulation) is integrated into most modern cell phones. These applications can be designed specifically around location for asset and sales force tracking, fleet management, emergency notification, route planning, local search, marketing, etc. (not to mention the social networking and entertainment applications).

While rudimentary geospatial tools have been online as a service for quite some time (.e.g MapQuest maps and directions), modern SaaS that integrates location-based services can offer better, smarter, and faster decision making, better user experience, and completely new types of service offerings.

When a user moves a file from the draft folder to the final folder, does the file really move?  Of course not.  Internally the file system is just changing pointers. But talking about pointers would be meaningless to most users and would have no value in helping them to predict how to accomplish other actions, such as deleting a file.  Instead many UIs use the familiar metaphor of a real-world filing system so that users can anticipate what will happen when they drag files around or put them in the trash.

The idea of a filing system for arranging and manipulating documents, is a conceptual model - an internal representation that the user has about how the system works.

The Holy Grail of SaaS UI Design

Determining the right conceptual models is particularly important for SaaS applications.  Online attention spans are short and users are less willing to spend a lot of time learning how to use an online application then they are for on-premise applications.  However, if you craft the right conceptual model for a SaaS application, 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, have higher adoption/retention rates, and be more intuitive and productive to use.

Conceptual Model vs UI

A conceptual model is not the buttons, graphics, mouse-clicks or multi-touch gestures that make up a software’s user interface. Rather it is the user’s internal representation of 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.

An appropriate conceptual model makes it easier for users to answer questions like:

What will happen if I click here?
or
How can I…?

While the conceptual model is distinct from the UI, the right conceptual model greatly facilities the job of designing a componentized UI that is clean, simple, coherent and predictable (i.e. what many would say is the definition of intuitive).

Cover Flow as an example

While there are many excellent examples I can think of for conceptual models applied to UI in software, one of the easiest to understand is the Cover Flow UI for browsing music on the iPod.  It uses the conceptual model that people have for rummaging through album covers to find the music they want.  When they find the right album cover, they turn over the album to see the individual tracks.

Cover Flow takes advantage of users’ experience with the physical world so the user can rely on their intuition to manipulate the digital world. At the same time the UI expands their conceptual model of how things work, to take advantage of new capabilities that are possible in the digital realm - e.g. scroll the song list, tap a title to play, manage podcasts.

What makes this such a clear demonstration is that there is a direct mapping between the way the system operates (the UI)  and the tasks it serves (the conceptual model).  Users get it and embrace it.

Developing the UI using Conceptual Models

Coming up with the right conceptual models is an essential part of the iterative development process when designing a SaaS application. For our own teams, although not a linear process, we always assess the users, define the high value scenarios, and select and test conceptual models before we proceed with defining the actual UI components or application layout. The result is a always a better application that is readily adopted by users.

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.

I’ve been arguing for a while now, that  creating a Web-based version of a desktop or server-based product is only part of the battle if you plan to deploy SaaS in the enterprise space. This core application is just one component from the array of user experiences that need to be addressed when deploying or selling any enterprise application. These “other” experiences include marketing, evaluation, configuration, support, monitoring, and feedback.

Just how important are these other user experiences? While I usually try to write things from the point of view of our enterprise clients, this time I thought  I would share some personal anecdotal evidence in the consumer space.

I have accounts with two large financial institutions (no names since both have divisions that are clients).  Both have web applications that offer comparable services,  but Firm #2 seems to offer better pricing for comparable funds. 

Since both institutions deliver a very similar web application for trading,  you would think that pricing would automatically determine which service I choose. But the reality is that I almost consistently use the web application for Firm #1.  Why?  It offers a better user experience for all of those things that are outside of the core application of buying and selling funds.

For example, Firm #1’s web app lets me configure my screen so that I can view information that I use most frequently, including monitoring my activities and the fees I have paid.  I can get at the same information with Firm #2, but it requires me to use their menu structure and go through several steps for this high value task. 

Firm  #1 makes it easy for me to get support - both with an electronic help desk, and via email support.  Firm #2 offers these things as well, but they are not integral components of every screen - they are like separate applications.

On top of this, for the life of me, I could not figure out how to change my password for Firm #2.  I had to contact tech support via phone!

So to come back to the main point: the core application (in this case, fund investing) is only one component from the array of user experiences that need to be addressed by any web application. The other components help maximize the business value of the application. When they are not addressed,  you get customer churn.