Enterprise Software Design Blog

Archive for December 2009

Software as a Service (or On-demand applications) has evolved tremendously over the past couple of years. After the success of companies such as salesforce.com and Netsuite, even the traditional on-premise vendors have started delivering their applications on an on-demand and hybrid model. This presents a disruptive change and challenges to the vendors, customer and integration partners on how they conduct their business. Gone are the days when a vendor used to sell a product for a fixed license cost and is assured of maintenance revenue every year. The customers no longer have to make huge capital expenditure to make the application and system work since it has been purchased. The system integration partners can no longer offer implementation and customization services. In the SaaS (or on demand) vs on premise series of posts, I’ll discuss these challenges faced by the entire enterprise software eco-system and how it can be overcome with smart design.

On traditional on-premise model, once the customers buy enterprise software, they will ensure that software is implemented, customized and used by all its employees. They will spend much more (which incidentally forms the bulk of the TCO) than the application cost to implement the software. They need to hire expensive business and technical consultants who will help them define business process, customize the application and get the application up and running for the employees to use. Since most software implementation brings in big changes with-in the organization, they need to conduct elaborate training program with the help of partners and enterprise software vendors to bring the employees up to speed. Even after the successful implementation and training, there is no guarantee that the software will be used across the enterprise. If the software is not used by the employees (due to poor user experience or poor short term benefits to the users), then the entire customer’s investment goes in vain. There is no incentive for the application software vendors to make the software useful to their clients.

On an on-demand model there is no compulsion on customers somehow make the software work since there is no upfront investment. They can use the software on a trial basis and if the software is not used within the organization (due to poor design or no apparent benefits emerging out of software or don’t add value to the company), then there is good chance that the customer can easily switch to another vendor or just stop using the software. The customer can terminate the subscription and recurring revenue tap will be turned off for the enterprise software vendor.

The software vendors will realize the fact that its not enough to deliver a software that is feature rich, moderately useable and with accepted quality standards. They need to ensure that the software is usable, adaptable and provides short term clear benefits to the end user that’s attracts them towards the software. The software needs to be exciting to end user and it should have a ‘pull factor’ that makes the users come back to the application.

To create the ‘pull factor’ and make the software compelling for the user, the software needs to display new and relevant content to end users each and every time they login to the application. This feature is used in social media application on internet as Facebook and youTube, where you would see different content relevant to the logged in user every time they login. Or take an example of a simple email application (Gmail, Hotmail etc.,) which attracts the users since new content (or emails) are displayed every time the user logs in.  As the users start using the application, he would start creating more content (i.e. incoming emails, outgoing emails, contacts etc.,) over a period of time. Once a huge amount of content is created, then moving to another application becomes tedious and virtually an impossible task. Similar pull factor can be created on the enterprise on demand such that the user will be attracted to the software and over a period of time will create enormous content the users cannot live without the application and moving to another application will tedious and time consuming.

One such design idea I have for the pull factor is displaying enterprise updates as live feeds. The application can configure events and when the event occurs the application will detect the event and will be displayed on the users’ screen whenever the user logs in. The end users are always curious to know about the information that is going around within the organization and relevant to them. A smart organization will use this to drive the employee performance as well. For example, a sales representative always wants to know what changes are made to the sales organization, how do they performed against the peers,  who’s the top sales person in a week or month, information about key deals, discount offered etc., Optionally these live feeds can drive the user to complete tasks.

Enterprise Software on Smart phones

Mobile phones and smart phones are driving internet usage and it’s predicted that it will overtake the preferred medium for accessing internet in the future. Most popular internet application (Email, YouTube, Facebook etc.,) has a mobile application and increasing people are using these applications from their mobile phone. The enterprise users expect the enterprise software be available on mobile and executives who are mobile such as (sales representative, field sales technician etc.) it’s a must have and influences their productivity.

Designing and developing application for smart phones has its own issues that include lower bandwidth, different screen size and resolution of the device, device capability etc. The application vendor will typically deliver two different versions of same application, one for smart phones and one for the desktop computers. This approach has its own limitations.

  1. Development Overhead: The application vendor will have two dedicated team to develop and maintain such applications. This increases the development and maintenance cost and other overhead associated with having two teams.
  2. Non-standard devices: No two handheld devices (from different vendor such as Nokia smart phones and iPhone) have standard capabilities and come with its own limitations. Designing applications for such devices are tedious and time consuming
  3. User experience: The user experience between the mobile application and desktop application is almost always very different and user doesn’t relate between these applications.

The limitation mentioned above can be overcome with maturing technologies (i.e. Adobe flex open source framework) and smart design. The solution lies in using Zoomable User Interface.

Zoomable User Interface

The zoomable user interface allows the user to zoom-in and zoom-out of content displayed in the user interface. This is similar to Google Maps where we can zoom-in and zoom-out to view details on the map such as country, state, city and roads. These zoomable user interfaces allows application developers to define the content to be displays depending upon zoom factor i.e. how much the user has zoomed. By defining the content for zoom factor, the same application can be used both in mobile devices and desktop (esp. internet based application that works on a browser). Typically zoom factor takes in account the number of pixels available to render the page and once defined the same application can be accessed over the internet. The mobile phone with smaller screen will have smaller zoom factor and so only those content will be displayed where the same application when accessed from a desktop will display much more content. On the mobile phone, the user can pan (i.e. drag the screen on all directions) to view all the content.

As usual let me take an example and explain. Take an example of simple contact management application. The application will allow the users to add and update a contact. The sample user interface screen for the desktop application looks below.

It displays the complete page with maximum zoom factor. It has all the contents that the page contains. Typically application will define a set resolutions, say 1024  X 768 to be the maximum or 100% zoom factor  and it will confirm to a typical desktop resolution. The application developer will define all the controls that are to be displayed for this zoom factor. And then the developer will define controls to be displayed for different zoom factor such 25%, 50%, 75% etc., The user can view the application with 25% zoom factor initially with limited controls in it and zoom-in to view more control as defined by the application developer.

The zoom factor is basically the different screen resolution available for (i.e. 25% zoom factor is 200 * 150, 50% zoom factor is 450 * 300 etc.) rendering the page. When the application is accessed from smart phones with a certain screen resolution, the application will display content for appropriate zoom factor i.e. the iPhone has a screen resolution of 480 * 350, so 50% zoom factor will be displayed as shown below). The user can zoom out, drag the screen on either direction to access the entire page.

Design Advantages

  1. Multiple devices support: One design will support various devices including Smart phones, Netbooks and desktop computers (with different resolutions).
  2. One application: The application vendors will have only one application. No integration or repetition of backend transactions involved.
  3. Consistency: There is a consistency in UI between the mobile and desktop applications and provides seamless switch between these applications.
  4. Intuitive: The application is intuitive since zoom and pan designs are widely used in maps and other picture viewing application and the user knows that zoom always display details of the object being viewed.

Comments welcome..

There is an unwritten rule and widespread acknowledgment within the software industry that 80% of end users of enterprise software’s only use 20% of the features provided in an application. Imagine how many times we have used all the features available in our word processing software such as tracking changes, creating envelopes, inserting citation etc. Most of the time we only use  common features such as create a document, format the document and then print it. That’s it.

Enterprise software vendors in a race to expand and capture market share, offer a number of features in their applications. It could range from a simple data entry to complex work flow solutions. The product team incrementally adds these features in to the product and to increase the demonstration capability of the product and to reduce number of clicks, they bury the entire feature in one single screen. They fill up every single pixel on the screen with UI widgets such as links and text fields. While this makes the look product feature intensive and reduces the number of clicks, it also clutters the screen and the amount of information display the end user is simply overwhelming. While reducing the number of clicks is a good idea, it shouldn’t be at the expense of clarity and usability. Once such screen is given below

This screen was designed by team who doesn’t know which feature is critical to customers and instead offered all the features in one single screen. There are following disadvantages with this approach.

  1. Too much information on the screen.
  2. UI is cluttered and unstructured.
  3. It offers too many features such as opportunity editing, adding products, adding contacts and interested parties, adding attachment and notes.

Does this mean that enterprise application shouldn’t deliver many features and Shouldn’t cater to the rest of the 20% of the market? No. They should and an intelligent design would help them do all these.

A typical sales representative is interested in creating a opportunity and recording its revenue. All other features such as contacts, attachments and notes though are good to have but are not critical to complete the sales process. So I recommend a design that by default hides all other details other than the critical ones. The sales rep will have a UI widget (a link) that will allow him to show and hide these features. I would redesign as it’s given below.

The sales representative, as they get comfortable with the common features will start exploring the hidden features and will start using as they deem fit. This design makes a clear distinction between what is critical to a sales representative and will coerce him to start looking to other features provided. This will allow for the entire software to be voluntarily adopted by the end user.The are apparent advantages of this design is given below

  1. There is no information overload.
  2. The information displayed is structured and uncluttered.
  3. The design is self evident. The user knows what he can accomplish my looking the page

From time immemorial it’s been taught in computer science class rooms that a computer processes ‘data’ and produces ‘Information’. The user interface designs of some of the enterprise application software will make you doubt my first statement. With rows and columns of data filled all over the computer screen, the application makes the computer screen looks like as if it’s straight out of the ‘Matrix’ movie (green screen with characters dropping).

A typical enterprise application is used over a period of time and since the data is entered and updated almost on a daily basis, huge data gets accumulated in the database. Digging information from the data is vital and the good news is this can be done with simple changes to the conventional enterprise software design.

To illustrate my point, let me show you with a example on how this can be accomplished. Lets us consider a simple use case. An organization has implemented HR software to maintain the employee information. When a new employee joins, the application will allow the HR representative to add a new employee and enter all the employee related information such as personal details, salary details, educational qualifications and business unit details. The UI will look like something below. Whenever a employee is created, it will displayed on the list regardless of whether complete information requested is been entered or not.

Typically information about the new employees will not updated on one go and the HR representative will need to collect the data, cycle back with the employee and other external parties to get the relevant information. Once the information is available, HR representative will select the employee and go to the relevant tab to update the details. This is a typical daily day-to-day task of an HR representative.

There are two fundamental flaws with this design.

  1. The designer assumes that the HR representative will know which employee information is complete and which ones are not. This is not the case and with one representative managing large number of employees this can become cumbersome.
  2. Though the data about which employee information is complete and which ones are not, the application software doesn’t display those information.

Needless to say, the application is complex and is very difficult to use even for a simple day-to-day employee information update.

Thankfully this situation can be corrected by making a simple design change. As you can see in the image below, a completeness meter column can be introduced that will appraise the HR rep about the percentage completeness of the employee information. The completeness meter is horizontal bar that will indicate the completeness. On hover on bar, a tooltip text will display the incomplete tasks. HR rep can click on the incomplete task to navigate to the appropriate tab.

This method offers the following benefits.

  1. Displays relevant information along with data.
  2. The HR rep needs not view or remember every single customer whose information is not complete.
  3. It saves time and frustration for the user.
  4. Every time the user looks at the list, it reminds about the incomplete task and the user is more likely to complete the task seeing the image rather than going thru every single employee record.

This is classic example of how an simple design change can make the application more usable and less complex for the end user.

Enterprise application software is one of the heavily invested technologies and it largely drives investment in other technology areas within an enterprise. Billions of peoples around the world with varied responsibilities use enterprise software on a daily basis to perform their day-to-day tasks.  They use enterprise application software to complete from an ordinary task such as applying for a leave, creating an expense to most complex task such scheduling work assignments, allocating bonus etc.,. Though these applications are most widely used, the user experience of these applications forthe end user is far from encouraging and leaves much to be desired. There is general and accepted tendency among enterprise application users that they need to go through a huge change management exercise within their organization and develop expertise in just using these applications to perform ordinary tasks.

In my view, what ails enterprise software applications is that it was never originally designed for easy use of its customers. If you dig little deep in the strategies employed by most enterprise application software vendor, you would see that user experience design would not be a major milestone within their development processes. Most vendors do not know who their end customers are and why and for what purpose are they using this product? The application software vendor performs truly a great technical design such as identifying and prioritizing the features, data model design, technical design. The human aspect of it is often overlooked and UI design and development is the least preferred activities of developers. Nothing explains the plight of UI design more than the cartoon strip given below.

Lets look at some specific items that makes the vendor to overlook the user experience design.

  1. Race to develop compelling feature: First and foremost is the race the vendors are in to introduce new applications and features before their competitors launch. Since there is huge gap between the time the software is bought and it’s implanted and used, the vendors naturally skip or shorten the human factor design step from the product development cycle. The tendency is that if there are any problems with the software, it will report and can be fixed. End of the day customer bought the software because it supports the features and not because of its ease of use. As long as the features and there is a way to use that however painful it’s the end user’s to use, vendors are find with that.
  2. Match competitor’s functionality: The marketing team in any product development company wants to ensure product they sell should support all features that the competitors offer. This way they do not allow competitor to differentiate their offering in the market and adding more features in to their product, they can differentiate and overtake the competitor. To meet marketing requirements, the development will force introduce the feature even if the feature cannot be supported given the technology design.
  3. Buyer is different from users: The buyer of the software is mostly C-level executives or the VPs with in any organization. The CEOs and CIOs look at the vendor brand name, market leadership and number of features supported by the product and not necessarily its ease of use since most of them don’t use this product. The purchase is generally made at the corporate level and the application will be installed around all their departments.
  4. Product Development Methodology: The traditional product development methods followed in non-software industry always includes a step for industrial design that looks at the aesthetics and usability of the product developed.
  5. Design Decision: The key decisions around which product and features to be supported are either made by the CEOs or Product levels VPs within any vendor company. To include a feature in the release the product managers start designing to the product that will satisfy the decision makers. The decision makers hardly use these products and more often or not they don’t understand the end users. The design that impressed almost and always never met the user’s expectation.
  6. Misunderstood design: Most product development team view software design is all about creating jazzy looking icons, stylishly designed button and using all the color supported by the latest display screens. Though these can be used to improve the design and look and feel, design goes much beyond just how things are displayed on the screen. The design should allow the end user complete their responsibilities with ease
  7. Technology limitations: The technology used to render the UI elements will have its own limitations. The developer understands these limitations and often the design suggested by the designer either cannot be implemented or to implement such as feature would require major redevelopment effort. In such cases the product development team either comes out with a decision that is technically feasible but compromises user experience or lets the developer come out with a design that can be implemented.
  8. Information Overload: Enterprise application software is sophisticated and they support a wide variety of business process. Unaware about the customer usage, the product development ensures that that business process are supported from an single page and display data pertaining these business process within single. The end user gets lost in information overload and  is stranded in the information jungle now knowing how to complete a simple task.