Ashley Frasier
Experience Designer

Lightning Migration

 Task

Support Enterprise Risk organization convert their Classic Salesforce product to the Salesforce Lighting

Ok, so here is a bit of context and background before we get into all of this Salesforce talk. I have been working for Codescience for 4 years. CodeScience helps SaaS businesses thrive on the Salesforce AppExchange. These could be:

  1. Large organizations that implement Salesforce internally for their their employees

  2. Companies that create products using the Salesforce platform which they sell and maintain

    1. A product that integrate into an organizations instance

    2. A stand alone product

When you hear Classic Salesforce this is referring to the older user interface and technology that Salesforce was built upon. The old interface is called Aloha. The framework is using Visualforce and Apex to render information. It is super similar to Javascript and HTML - subtle differences in code.

Classic Salesforce Aloha interface.

Classic Salesforce Aloha interface.

Yea. It looks quite outdated but I will tell you, users that have been using that platform for years absolutely LOVE it and are VERY hesitant to change. They have taken years to meticulously optimized their job around this platform. At CodeScience we found out projects were a lot SPAs (Single Page Applications) where we brought in Angular or React to build custom apps on the platform. In all honesty, it was pretty hacky and not an ideal solution.

About 4 years ago, Salesforce started to slowly release what they call ‘Lightning’. Now, this not only refers to a new look and feel but also new technology on how their platform is built. At first, it was strictly built with a framework called Aura. It also came with a design system which was HTML and CSS using SASS. This initial release was quite limited and was simply the start to what is now a very large and well supported framework. It was not the best choice to convert your product over and go all in quite yet but it was a great time to get familiar and use very select projects to test this with. Fast forward to now - Lightning is pretty amazing and Salesforce will officially be converting completely over this fall. Their Lightning Design System is one of the most well known and respected design systems in the world. They have a robust Lightning Component library which is made out of two technologies now - Aura and React Lightning Web Components. It is supported by a large team and is always being updated and improved upon.

A marketing example of the new Lightning interface.

A marketing example of the new Lightning interface.

Lightning Migration

In early 2018 a large Enterprise Risk organization approached CodeScience to get help in converting their product from Classic Salesforce to Lightning. They had about 10 different product offerings they were looking to convert. Lightning had now been out for about 3 years, it had been well supported and it was becoming the new standard for Salesforce platform products. This client knew it was time to make the big switch - they were losing a lot of current clients and potential new clients due to inefficiency of the experience of the current product. They had developments teams in place which included Product Owners, Technical Architects, developers, and QA but they did not have a designer of any kind on their teams. They wanted to use CodeScience as a design voice to be integrated into their teams and steer the new design direction of their product.

Plan of Attack

For this engagement to be successful not only for CodeScience but also for the client in their transition and also the future, we had to ensure we were setup for success. The key items we setup from the start were:

  • Identify overall Product Owner and Product Owners for each product

    • We needed to have a Product Owner who had oversight on the project as a hole but also product owners to work with on each individual product

  • Identify overall Developer Lead and Developer Lead for each product

    • Just like Product Owners, we needed to understand the developer landscape - our philosophy is that design is not separated from development in agile product development

  • Share our process and tools of integrating design into a product development workflow

    • Our end goal was to show the power and importance of design being a piece of their product development team. We wanted to enable them to staff this role when CodeScience was done.

  • Roadmap to show us order of priority for conversion

We were successful in identifying and expressing the above bullets except for getting a fluid working relationship with their development teams. They had many development teams compared to our 2 design resources. Many of their development teams were offshore. We took a walk-first approach and committed to showing the success of design on development teams where we could and hoped it would be a trickle effect to the other teams.

Gaining Context and Understanding

To kickstart this process we had a series of meetings where we met with various Product Owners who shared their user research around their products. We prioritized these meetings based on the roadmap and keeping an agile approach to build in mind. Our sessions starting to surface out key users flows which we then began mapping to the Salesforce platform. We used LucidChart to quickly create user flows which we could share remotely with all team members. This allowed us the flexibility needed to do very low fidelity work.

This is an example of a user flow. We created flows like this for each userflow with the product owners. This allowed us to then identify all the views we needed to optimize in Salesforce and any custom components that needed to be created. LucidChart was a great collaborative tool for our remote teams. People could easily make comments and updates in real time to share with team members.

This is an example of a user flow. We created flows like this for each userflow with the product owners. This allowed us to then identify all the views we needed to optimize in Salesforce and any custom components that needed to be created. LucidChart was a great collaborative tool for our remote teams. People could easily make comments and updates in real time to share with team members.

The back example is how we dissected the data that needed to be accessed and surfaced on a record view page. The front view was the list of custom components we began to gather throughout the these exercises.

The back example is how we dissected the data that needed to be accessed and surfaced on a record view page. The front view was the list of custom components we began to gather throughout the these exercises.

The first few months of this project was spent mainly in LucidChart and talking. The concept of creating mockups or designs wasn’t even brought up until we had a very firm understanding of our user journeys on the platform, data, and the custom components that would be needed to be built.

When on Salesforce and we say custom components, this refers to building functionality that Salesforce does not offer out of the box. Salesforce has a large set of components that allows admins to build layouts but when you start to build custom products you tend to begin to add in custom components that set that product apart and becomes the reason for someone to purchase it. Custom components are heavily vetted and weighed against the effort, cost and maintenance.

Design Strategy

Our job was not only to provide high fidelity design prototypes but we were also there to define the design strategy for their product on the Salesforce platform. What this means is, Salesforce has a tool called the App Builder. It is a way for admins to configure an app through clicks - not code - how a view will look to users. Salesforce really sells itself on being a ‘no-code’ platform. You can build apps simply by using their App Builder. Our job was also to provide best practices for these record layouts that were most commonly used by users.

We started a documentation reference guide for the organization to follow when building layouts out of box. We also created a reference guide to the custom components so individuals building layouts also knew where and when to use these. This documentation was stored in a structured Google Drive so we could easily add to the documentation, add comments, and track changes over time.

Prototyping Process

Once our research was to a satisfactory point and felt like prototyping was appropriate we began to visualize custom components for the product owners. We use these tools to prototype with the client:

  • Salesforce enables us to create high fidelity mockups quickly because they have an awesome Sketch file to reference. It allows us to quickly build and iterate flat components to speak to and test without investing a lot in development

  • Once the flat prototype has reached what we consider a ‘stable’ state we actually move that into code. We do this because we can quickly prototype leveraging the Lightning Design system code snippets and the Lightning Component library

  • Get on the platform as soon as possible - once we have our code prototyped in a Salesforce org - we can put it on layouts and in views. It is a pretty amazing way to get to a testable prototype to put in front of users

For each custom component we went through the above exercises. We would have an every other day cadence of updated prototypes that we would share with a team of Product Owners and Lead Developers. In these meetings we were able to understand the level of effort and weigh features quickly. It was a fantastic collaborative approach that gave everyone visibility into the process and they felt ownership. The Product Owners would then go and test these features with their users and we would make changes based on feedback.

We isolated components because that is how Salesforce is built. You use the App Builder, very similar to any page building tool, and pull components onto different types of layouts to create views for the user. Here is an example of a wireframe of come common Salesforce page views:

Example Components

Policies

This company offered the visual display of insurance policy information. It is a very company visual in industries. Their current version was very outdated, slow, and vert hard to use. As we converted this feature to Lightning we were sure to follow the Lightning Design System guidelines the best we could. Salesforce did not really have this type of visual but used colors, buttons, typography, and other small components as reference to build this large components. We had to account for many small features but two main ones visualized here are users being able to change colors of the policy, hover over blocks to see more data, and take what they called ‘snapshots’ where a user can save a view for future reference to download.

This component followed basic principles and patterns of the Lightning Design system.

Hierarchies

Salesforce has an out of the box feature called Hierarchy. It allows for an individual to see the hierarchy of data in their organization. This tool is important to individuals because it allows them to visually drill down and see important details along the way. Salesforce has yet to create a Lightning version of this feature. It was not on the roadmap and the client decided it was important enough to visualize for their future product. These was a robust component that we did a lot of iteration upon, not only for the overall idea and use but working with the development team to ensure all of the different states and interactions were accounted for. This component came with dragging and dropping and live editing - it was integral that we designed and accounted for all of the different states.

This component followed basic principles and patterns of the Lightning Design system.

Claims on Incidents

Claims were a core feature to their product. How to visually show claim data was very important to their users. Salesforce out of the box did not give us a great option to optimize how this was done so it was decided to create a custom component record to go on an Incident record to better show claim data.

This component followed basic principles and patterns of the Lightning Design system.

Communications

Building this component was quite a heated debate. Salesforce had a way for users to send out emails to records but this company felt it did not contain certain features that were integral to what their users needed. After a lot of back and forth with development and product it was finally decided to create a custom component called ‘Communications’. This could live on different record types to track and initiate different forms of communication about that record. The main features we had to include were:

  • User can select a template to create their communication

  • If an email, add email fields

  • Be able to search Contact Roles in Salesforce on the record to add to Communication

  • Rich text editor that can have basic formatting and embedding of images and links

  • Can Save Draft, Send Email, Export into a PDF or do both

  • Can attached larger image files

  • Can pop out into utility window to work on

  • Show any previous communications below for context

Small Components

Along the process we also came across many smaller components that needed to be built to better support specific use cases. Lightning has this whole debacle about buttons and actions… if you want to learn more about it - you can go here. That become a big thing we had to account for on the new platform. There were important use cases for just surfacing details and information to help a user know the status or state of a record. At the time, Lightning did not have a lot of that, it has gotten better now but at the time we did not have such components, so we built a few.

End Engagement

By the end of the engagement we had created over 100 custom components and worked on 8 products. It was a whirlwind and towards the end of the process it started to become a bit siloed with design and Product Owners away from development. This was the result of a very aggressive timeline and not enough design resources. Throughout the engagement we continually tried to recommend hiring design resources to permanently be a part of their teams. As we transitioned off there were talks of this but nothing had been solidified.