Salesforce.com is the leader in CRM market and most of the implementations are carried using Agile/Scrum methodology. Today I would like to discuss the role of UX and its importance (or the lack of it).
What is UX?
UX stands for User Experience (well you must already know that if you are here). It is is the process of enhancing user satisfaction with a product by improving the usability, accessibility, and pleasure provided in the interaction with the product.[wikipedia] Let’s try to break down this definition:
- Any Application should be easy to use. Do we need training to use Google or Iphone?
- Features should be easily accessible.
- Application should appeal to the users.
- User Assistance and Help should be easily accessible.
The Absence of UX in CRM Implementation
My usual experience with any large implementation of CRM application (especially Salesforce.com) has been void of any UX consideration. Sure, there are UI design sessions but there are sporadic and there’s no single theme/idea that tie up the whole UI.
My observations have been:
- Gap in information: The flow of the requirements is Business User -> Business Analyst -> Technical Team. With each handover of requirements, some information is lost and the mismatch in the expectation starts creeping in.
- Absence of UX: In a 20 week project, I would believe that 4 weeks should be spent on UX and prototyping, however in reality it is not so.
- Complex UI: The end result is a customized solution with complex and hard to navigate UI.
- Unnecessary Data/Processes: Users end up having data that they don’t need but they believe they want. In one instance a client had data spread in 30 objects and then there was a complaint of Large Data Volume issues!
I have found that the action items listed below are very productive in resolving the issues above:
- Effective Communication: This lies in the lap of Scrum Master/Project Manager. How to prevent the discussions from veering off from the story being discussed. If you sit back and listen in on any story grooming sessions, sometimes you might feel that a new religion might be devised when in reality all they need is just a text box.
- Curtailing the roles: This too should be managed by Scrum Master/Project Manager. It’s quite common to experience that Business Analyst meet with users and get some requirement and they translate that into a solution and provide that as a requirement to the development team.
- Providing the “Business” need: This is the responsibility of Business Analysts. When the business analysts become experienced with any system, they implicitly start providing solutions as business requirements. Hence this practice must be curtailed by business analyst through self-discipline and solutions architect by asking questions which reveal underlying real business requirements.
- Adhering solution to Best Practices and requirements negotiation: This is an extremely important responsibility and it lies with the Solution/Technical Architect. It requires courage and guts, to prevent the requirements from being groomed which are incompatible with the system and finesse to negotiate with the users.
- Defining Nomenclature: This is a collective responsibility of all the parties involved in the project. This requires self-discipline to use the same terms across the users/teams. It is quite common to see different set of people in the same project use different terms to describe the same thing. e.g. Sales would call Prospects which the development team would refer as Leads. I have experienced numerous times that this has resulted in requirements being interpreted incorrectly and resulting in wrong solutions and loss of money and time.
In the end, the successful outcome of CRM implementation depends on the collective responsibilities of all the parties involved, self-discipline, effective communication and it is a collaborative effort.