Moving a Salesforce application, globally deployed on +6K end users over the last 4 years, from Salesforce Classic to Lightning Experience (Aka “LeX”) is not an easy game. In this series of blog Posts, we are going to present you how SpringFive helped a Global Energy Company to achieve this objective in less than 12 months.
Let’s start this first Post focusing on the Plan / Analyze phase and few basics questions:
What is Salesforce Lightning?
Lightning is the new foundation to get all the new capabilities of the Salesforce Platform. It is an intuitive, modern and highly flexible desktop experience and also a new way to build and customize apps.
Lightning is mainly impacting the presentation layer: UI but mainly the way users interact with their application. So the good news is that all your business rules and data model won’t be impacted.
Why moving to Lightning Experience?
After many years on Classic with a process well established, you need good reasons to justify a move to Lightning.
For Business users, Lightning is an opportunity to:
- Simplify: Usually after many years of iterative releases on Classic, your Salesforce solution may have become quite heavy and complex with a lot of fields, buttons and custom pages. Moving to Lightning is the good opportunity to reduce all these elements not always justified.
- Increase Efficiency: You can address the existing pain points by redesigning part of your solution to streamline your business processes. You can create Lightning component to bring the information to your users and make them save many clicks and vertical scrolling.
- Get ready for the next features: And maybe the most important, you will be ready to use all the new features Salesforce is providing as part of its seasonal releases (indeed most of the enhancements are available only for Lightning).
For IT people, Lightning will require a lot more effort because it is a whole new World. Your developers and Administrators will have to learn new concepts, new frameworks, focus more on UX and they will need to switch their mind to a “Component” mindset. Only after that, the real value will come:
- Speed your development: leveraging a library of Lightning components will allow you to create advanced page faster.
- Simplify: Get rid of your complex VFP / Apex and replace it with well-design Lightning components and contribute to decrease your technical debt.
So now, you know why moving to LeX, but…
Where to start?
The very first step if to start with the Salesforce Lightning Experience Readiness Report. This report is a tool provided by Salesforce to evaluate the readiness of your solution and provide an initial list of components which will require an adaptation to work in Lightning (like Javascript buttons not supported in LeX). It will give you a first list of items but it won’t help you on the major redesign you may want to do. On this area, you need to evaluate which part of your process you want to redesign and make your own Effort estimations.
As part of this assessment, don’t forget to look also at the Lightning readiness of the managed packages you are using. If you have critical business process running on ISV packages, you must ensure that they are Lightning ready. Don’t trust too much the icon “Lightning Ready” visible on the AppExchange… Contact directly your ISV contacts to confirm.
At the end of the Assessment, you should be able to make some High Level Estimates and start the preparation of the design phase.
Moving to Lightning is not (only) an IT project but a Business Transformation
At this stage of the project, you may think that moving to Lightning is an “IT only” project, this is a big mistake! If you don’t involve the Business people since the beginning, you will more likely fail to deploy all the changes you would have done. So, why do you need them:
- First thing, it will be very difficult to continue to deliver the Business Requirements expected by the Business and move to Lightning at the same time. Which means that you will have to “pause” all the ongoing enhancements which could be critical for the Business and this could lead to painful discussions.
- We have said that Lightning is an opportunity to bring more efficiency, streamline the process, etc. But who is going to tell you what the current pain points are and where time is lost if you are not working with Business representatives. So you need them you collect these key information.
- Finally, because Lightning is so powerful and you can build very advanced UI. You need to go back to design workshops, build mockups, present to the Business and discuss what the new capabilities are and what they want.
Define your Personas and start planning
An important step of the Analyze phase is to define your Personas:
- What are the key Business roles of your application?
- What should they see as soon as they log on the system (Homepage components)?
- Do they need to access other functional streams than their main one (Sales, Customer Care, Field Services, etc.)?
Having defined your list of Personas will drive all the rest of your transformation, you will usually:
- Prioritize the delivery per Persona (recommends to start with the simple one to learn and finish by the most critical)
- Design workshop will be done Persona per Persona
- Deployment of the Solution will be done by Persona
Why not starting with a Proof of Concept (PoC)?
A good way to move from Analysis to Design and Execution phases is to start with a PoC. On our project, this is what we did. We selected a non-operational critical Persona (Manager level) and a limited scope of the application and started an Agile delivery of the PoC: In 5 weeks, with 2 weekly meeting with the Business team, we delivered:
- A first version of the Homepage with all the information a Manager needs to see when he connects to (we followed the idea of pushing information instead of going to reports).
- A first set of Objects (4 to 6) redesigned in Lightning with a Lightning template, highlight panel, split of the fields in multiple tabs, etc.
- Few simple Lightning components to start learning on this area (advanced Related List, Warning message, etc.).
The output value of this PoC was key for the rest of the project, it allowed to:
- Start speaking the “Lightning vocabulary” (Highlight panel, Path, Quick actions, components, etc.) between IT and Business teams during the design session.
- Start thinking more in terms of User Experience (how to improve efficiency, reduce numbers of clicks, reduce scrolling, etc).
- Start learning how to build Lightning components.
Lessons learnt
- Don’t forget to check the Lightning readiness of the managed packaged you are using.
- Involve Business people since the beginning to maximize your chance of success.
- Well define your personas as it will drive all the rest of your delivery and deployment.
- Start learning by doing (with a PoC).
In the next Post, you will see how we managed the Design phase…