There is a lot of discussion around User Interface design and best practices. Especially in the area of Software as a Service where systems are accessed through web browsers and therefore any enhancements in web technology, scripting languages and market-driven “best practices” are easier to adopt and put into action. I am putting the term “best practices” inside quotes because I think that sometimes market is driving designers to choices around UI that are controversial to say the least.
For this discussion I will focus on high-end Business Application software and not low-end, narrow-scope programs; let’s have in mind some ERP or CRM applications. Many times, when users look at a SaaS product expect to see a kind of user interface that they are used to by the usual daily exposure they have on the internet, such as social media, news web sites etc. When they see a more “traditional” design approach they tend to characterize the software “old”, “cumbersome” and “not functional”. And all this before they even press a single button!
If the discussion moves further, they will sometimes argue that the system should have been modernized or revamped from its previous version to look more fresh and contemporary. They express these views before having seen how things work inside the application, how entities are connected to each other, how the reporting capabilities of the whole system suit their needs and stop at the first element of examination: the User Interface.
So big is the impact of this discussion, that we see newer systems adapt to the general requirements of the current mid-level management age range, which is the millennials: people that have aged with social media, sites like Facebook, twitter, Messenger for their communication needs etc. That adaptation is their effort to be liked by the today’s buyer (which is in many cases a millennial professional).
Having set the discussion on the general landscape, I pose the question: is the User Interface overrated? Should it be a critical factor for the buyers, in the area of Business Software as a Service? I am putting the cart before the horse and I answer “no”. You see, when we examine a piece of software, we must first examine if it gets the work (that we need) done. In most cases there are small differences in each business process, as it is executed by customer A and B. Sure, the Sales Order Processing is something that most people know and execute in the same way, but the peculiarities of each business tend to infuse small changes in the process or inevitably create variants of it. And it is the SaaS system’s job to try and fit-all-purposes (otherwise it’s “bye-bye multitenancy” and “bye-bye cloud business model”, right?) Therefore, it is possible that the maker of the software has inserted several options and parameters, some selection tick boxes etc. in each screen/view/report that tend to make it somewhat more “packed with information” than you would initially expect. And the discussion begins with something like “the whole thing seems like a bit too much for us…”. The next request is something like “can we redesign some of the screens of the system? We actually don’t need so much overwhelming information” and the whole discussion is derailed from the actual topic of focus (i.e. how good is the system) to a costly, yet irrelevant, effort to making it work “somehow differently”.
My experience over the years (and different technologies used) is that the discussion around User Interface is indeed a valid one, as long as it evolves around ease of use and how objects and entities are connected to each other inside an integrated Business Application. On the flipside, discussions around the design of the screens, the views, the reports and any other design elements of the (web-based) application only makes the final decision harder; and for no apparent reason. At this point, I should mention one funny incident that shows how irrelevant this discussion can sometimes become: In an application I used a small “magnifying lens” icon to show that a specific field had a search function associated with it. A prospect customer that I was giving a presentation to, didn’t like the idea of having a “tennis racket” icon beside the Customer Code field! You get the point? (You would be surprised of how similar a magnifying lens and a tennis racket can look in 16x16 pixel size)
Any kind of user interface will eventually be digested by the users and they will forget how they used to do things. What can’t be overlooked is the problem that a particular system does not fit the purpose and was selected only because it looked fresher, more functional and contemporary.
My advice to buyers, especially the younger ones, is to not “judge by appearances”. It is a very rare case that you will get the functionality that you are looking for from a twitter-like application. Sure, makers will listen to you and try to evolve their User Interface over time, but having a “live-feed” on your production ERP is not what will make your plant work better, nor should it be a decisive factor for your SaaS system decision.
Popular posts from this blog
Through this channel I have been talking about the advantages of cloud and SaaS products for a long time. In this post I’d like to focus on a more specific area. An area that contains a large pool of potential customers, who at the same time are still facing basic problems in their journey towards a “computerized enterprise”. That of small business ERP and especially the Financial ERP. By the term “Financial ERP” we define the software that performs the basic functions of book-keeping, sales and purchases, stock keeping customer/vendor order management and perhaps some more like basic workflows and some kind of business intelligence. These are requirements that small and medium-sized businesses are seeking to approach first, or they have already done so with not much success. Also, they are the kind of requirement that start-ups are trying to cover, since they touch the back-bone of the business function.
The relationships between customers and providers in the cloud business are generally governed by the Service Level Agreement or SLA. In a previous post I made the point that a really “tough” SLA is probably not the “holy grail” of the cloud business, which every customer should be looking for. In this post I will continue the same line of thought, focusing this time in the impact that a strict SLA has on the customer organization itself. For this purpose, I will use the term “Reverse SLA”.
In the organization’s journey from an on-premise Business Application setup to a Software as a Service one, one of the key factors of success is data migration. Of course, one starts with basic questions like “do I want or need to move to the cloud?”, “Which is the best SaaS solution for my case?”, “Does it address my special requirements?”, “am I content with the reporting/BI capabilities that it offers?” etc. But having answered all of the above, you should take into consideration the data migration issue. This post will point out some very significant issues around this subject, which you need to address and examine; probably in close co-operation with the SaaS vendor of your choice, before accepting their financial proposal and start the journey.