SaaS UI & Application Design 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.

I recently had a discussion with a colleague about where to innovate when designing an application or SaaS.  He was pitching a new client that kept repeating how they wanted an innovative design. But they defined innovative as a revolutionary new way for people to think about task X, with a dazzling Flash interface full of bells and whistles.  

The problem he faced (and something every user interface design firm encounters) was whether he should tell the clients what would create the best application or if should he just deliver what they said they wanted. He chose to advise them to do what would be most effective to increase user productivity and application usage - i.e. build the application around universal (not revolutionary) conceptual models and implement a UI that uses effects & interaction as a way to reinforce appropriate behaviors rather than just “dazzle.”   We will see if he gets the contract.

In any case, it got me thinking that it would be intereting to write about where innovation really matters and where it really should come in to play when defining a application. 

Consumer applications lead in innovation

It’s instructive that last week, during the Cloud Computing panel at the Web 2.0 Summit, Google’s Dave Girouard (manager for Google’s enterprise business) talked about how the innovation delivered in the consumer world is so far ahead of what is available in the world of enterprise applications. Girouard was not talking innovation in terms of new functionality, razzle-dazzle,  or new technologies. By innovation he specifically was referring to enhanced user experience that makes it easier for users to accomplish high value scenarios and that drives increased usage.

Application designs are built in layers

When you evaluate any application, you see the design is built on several layers. Each of these layers represents a point where there is the potential for innovation. But there are some layers where the business value to innovate is more compelling than at others.  This is particularly true for SaaS application design, where the value of innovation is defined primarily on the ability to increase the usage and adoption of the solution by customers (new or existing).

In next week’s post I will describe the business proposition for innovation at each layer.

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.

With the financial crunch in full swing both in the US and the global market, it's fair to predict that businesses will find their cost of capital has increased. Consequently many companies will try to stretch their dollars further by moving to technologies or methodologies that deliver greater efficiencies. Two viable options include SaaS and outsourcing.

SaaS

The move to SaaS is of course, not only for financial reasons. Well-designed SaaS enables companies to respond to market changes in a more agile manner. But SaaS can also be less expensive to design, deploy and update then on-premise software.

Outsourcing

Outsourcing is already pretty widespread. The global environment has enabled many organizations to harness outside expertise as a competitive cost advantage for the development of new applications (e.g. IBM and offshoring).

Several of our clients have pursued both options. They decided to migrate their on-premise application to a SaaS model and they outsourced a significant portion of the code development for this SaaS outside of the U.S.

Keys to Success

From our experience, for this approach to be successful several procedures need to be in place:

• Your internal IT department needs to be a strategic and integral part of the business so they can act as an effective facilitator and project manager. If they are just "the gearheads" in your organization with a technology driven ethos, rather than strategic business advisers with a business focus, they will not be able to manage the project.
• The application design needs to be completely vetted, tuned and visually blueprinted, so that it can be implemented by almost any developer - regardless of whether they are internal or external. This means systematically defining and designing all aspects of the application in terms of everything that the user experiences, as well as validating that the UI and database schema/back-end will integrate when the project is deployed. Plan to include on-going user validation at each phase of iteration (see below).
• Regular, on-going dialog is required between the U.S.-based IT project managers, the U.S.-based application/UI design firm, and the outsourced developer. Communication can be done effectively, environmentally friendly, and economically using web-conferencing.
• Development managers need to avoid the traditional analyze, design, code, test, and deploy model where each stage is 100% completed before moving on. Instead, rapidly iterate on development and get working components up quickly. This lets you address ambiguities and resolve problems. Each iteration consists of some development, some testing, some user-validation, and some deployment.

Whether the economy is on an upswing or in the tank, SaaS and outsourcing can act as catalysts for streamlining business operations, getting to market faster, and increasing flexibility.

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.