⚡Moving a Global App to Lightning Experience – Design Phase (2/4)

Previously in our Lightning series, we understood better what Salesforce Lightning is, why moving and where to start…

Go to the Previous Post on Move to Lightning –  Plan and Analyze Phase

Now, let’s review one of the most important step in your Lightning Transformation journey: The Design Phase.

Personas Interviews

Work with your Business representatives to identify 2 or 3 end-users (from different geography) per role / persona and conduct a series of interviews (ideally with a UX expert). 

This first step is key to understand how the app is currently used in Classic version, what the major paint points are and identify in which part of the application you should invest your time (and money).

The best way to gather the feedback is to ask the End-user to demo how he is working on a daily basis: 

• What is the first action done after login?
• Which objects / Pages are mainly used?
• What are the key fields updated on the transactional objects?
• Is there some unnecessary fields / buttons on the page?
• What actions are painful to perform?

“Several buttons are not used,  the calendar visibility is not optimal, it involves a lot of scrolls…”

 ” A personalized Homepage would be a real plus, at a glance I can have an overview of all my actions..”

These interviews will be the raw materials for all the next steps and mainly to identify the mockups to be prepared.

Mockups and Design Workshop 

If you don’t have already a UX Designer in your team, hire one for this phase. Indeed, even if it is quite easy to create mockups on the Salesforce Platform, designing Lightning components requires a strong UX expertise.

Now, let’s design your new Lightning App. The work can be split into 2 parts:

• Lightning configuration of the standard layouts (Point & Click):
  • Review all the key objects you have in your app and review the target configuration:
    • Identify the best Lightning record template to use
    • Define which fields to display in the Highlight panel
    • If the object has a lifecycle, add a Path and identify the key fields to be updated from one stage to another
    • Depending on the number of fields you have in the Classic layout, decide if you want to break the main layout into several tabs, like: Basics, Advanced, Related, Details.
    • Need to manage Activities? Don’t forget the tab (side panel)
    • Need for collaboration? Don’t forget to add the Chatter tab (it is not automatic like in Classic).
• Lightning components and Lexification of existing Visualforce pages (custom development):
  • You won’t be able to re-design all your visual force pages into Lightning components, so:
    • For the non-critical page, just do a simple lexification (simple tag to be added in the code to make it render with the Lightning stylesheet)
    • For the business critical process, re-design it completely into Lightning components (Preferably in Lightning Web Component) with a strong focus on the User Experience (mockups are required for design discussions).  

Also, if you are working on a large implementation with several Business streams (Marketing, Sales, Service, Field Services, etc.), you may also have to agree on some common UX rules to be followed in order to keep a consistent experience for users which are working in multiple apps. Here are few things to consider:

• Keep the highlight panel not too heavy (6 fields max)
• Keep Related and Details tabs on all the record layouts (when a user is “lost” on a newly redesigned Lightning page, he will always be able to find the information in one of these 2 standard tabs)
• Always display warning / error messages in the same place (a simple component may help you here)

All this preparation is the basis of the design workshops you should conduct with your Business representatives to present the design options, take their feedbacks and define the different work items which will have to be delivered. This is what is going to make you move from a very high level requirement “Switch App to Lightning” to a series of detailed User Stories.

At the end of the Design Workshop you should be able to move your current Classic Functional specifications document into a Lightning version.

Functional Specifications

This step is actually not obvious and will require you some significant effort. Depending on the age and complexity of your application, it might be a rewriting of a several hundreds pages document.

The good thing is that most of the Business logic description will still be valid (except for the brand new Lightning components you have built) but the UI part will have to be totally re-specified. And describing a Lightning record page could be much more complex than a regular classic layout because of all the possible combinations (different templates, path or not, multi-tabs, standard / custom components added to the page, etc.). So, you will have to create a new structuring.

At the end, it will be a good opportunity to clean and refactor the document which could be a little heavy and obsolete after several iterative releases.

 Lessons learnt

• Hire a UX design if you don’t have already one in your Team
• Conduct End-users interviews to gather the feedback at the source
• Identify where you should invest your time and effort (only on Business critical part). It will also help your Business team to learn the new Lightning vocabulary.

In the next Post, you will see how we finally jump into the implementation phase…