A look into how we built Salesforce’s Lightning Experience
In modern product design, Agile methodologies have become a standard for shipping products for both startups and large enterprise companies alike. In theory, the process follows a simple, contained structure that is iterative, collaborative and user-focused. But in practice, Agile is often complex — altered to fit and flex with the unique needs of individual product teams.
At Salesforce, the agile process is central to how we deliver products. It’s a framework that’s allowed us to develop rapidly through incremental improvements, iterate quickly upon feedback, and steadily develop.
But how does a team strive to make major innovations within an agile process and create transformative change at scale? At Salesforce, we faced this question head on. Here’s a look into how we took a new approach to build the Lightning Experience and make design core to our process.
Redesigning a product from the ground up
Less than a year ago, Salesforce launched the ‘Lightning Experience’, a redesign of the Sales Cloud, our core web-based CRM product. Lightning was a dramatic reimagining of the sales experience and marked our first major product redesign in over 10 years. As an enterprise company, we recognized that the world had changed, technology had evolved, and that users had come to expect great design. We knew where we needed to go but were faced with the challenge of how to get there. With 85 designers and 60 scrum teams prepared to take on the effort, product leadership took a step back to evaluate how we would deliver on a new product for sales reps.
Innovation and the agile process
The potential for a fresh, new experience excited people and garnered considerable expectations. Keep in mind, however, that Salesforce is used by millions of people across 150k companies and organizations to do their work every day. Redesigning Salesforce would be difficult, due to its scale, but the potential for innovation was equally significant.
One of agile’s greatest strengths is its ability to focus teams on executing incremental change but struggles as a framework to accommodate for broader innovation. As work gets broken down into sprints within agile, it can be easy for teams to experience tunnel vision, focusing on the what and when of what to build without asking the why.
Too often teams jump into building before developing a clear definition of the problem. To innovate, we needed to pause and ask ourselves the why.
We had to know the right thing to build before we could build the thing right.
Products need a point of view — a user-centric strategy that drives what is built. Otherwise, product teams run the risk of making software or apps that no one would want or need. We took a step back and started from the beginning, revisit our users’ goals, problems, and pain points.
Framing the problem
Product leadership from UX, product management, and engineering came together to set the stage, asking our teams to imagine what a new desktop product for sales people could look like in two years if there were no constraints. By doing so, we were able to break out of the agile mindset and embrace ‘blue sky’ thinking, providing a space to explore new ideas and reimagine the sales experience as a whole.
To better frame the problem, we started at the core and asked ourselves to determine the most critical experiences to sales reps and evaluate the most common behaviors within their workflow. By focusing on their goals and behaviors, we could begin designing and developing a new user experience that was meaningful to our users.
Aligning around design
By asking the right questions, the team was ready to align around design. That said, it didn’t come without its challenges. There lies a fundamental tension within product teams themselves that make it difficult to align. Designers, developers, and product managers each have their own point of view on how to make products successful and a stake in advocating for their role within an agile framework. For a product team, the idea of a ‘design-led’ process can be scary.
When beginning designs for the Lightning Experience, it was important to communicate to the rest of the product team that a ‘design-led’ process for us didn’t have to mean that designers would lead and the rest would follow. Instead, it could mean something different.
Everyone is a designer
IDEO often discusses the convergence of desirability (human), viability (business) and feasibility (technical) when designing great products. As a team, we were inspired by this concept and made it clear that design was a mindset and everyone had a stake in design. From the beginning of our process, we wanted to make clear to the team that everyone was a designer. Traditional UX designers became ‘human’ designers, PMs became ‘business designers’, and developers became ‘technology designers’, each having their own valuable perspective to bring to the table. By doing so, design became a means for solving problems instead of a category reserved for those with unique expertise.
From there, we set up workshops and watched as PMs, engineers, and UX designers sketched out ideas, worked through edge cases, and mapped out key user flows, representing important tasks that our users commonly tackle. Pen and paper became the tools to help us re-imagine the product and were a major catalyst in reinforcing the idea that all of us had a stake in design.
An initial sketch of the Opportunity Kanban — a drag and drop way to move deals forward
The Sharpie proved to be one of the most democratic tools in our process. Anyone could pick one up and put their idea out into the world. It wasn’t always pretty but it allowed us an excellent way to collaborate cross-functionally.
Finding design’s place in the agile process
Once we established our key flows and sketched out some initial UI, we were able to involve the greater product team. We got moving on in-depth interaction design, a design system, and into prototyping and development. With growing momentum and trust, we had an opportunity to evolve the way designers, PMs, and developers practiced agile on a daily basis — an area in which the role of the designer hadn’t always been clearly defined.
Design is more than advocating user needs and making mockups. It’s about craft — ensuring quality and trust in what is built.
It was important to us that designers were utilized more as partners in the agile process and had a role in prioritization, planning and execution during product development. Working together with PMs and developers we found methods to involve design in new ways that led to both process and cultural-based changes in the way we practiced agile.
At a micro-level, this involved devoting time to having regular UX reviews, raising the priority of UI-related bugs from P3 (shippable) to p2 (un-shippable), and bringing developers into the design process earlier, while also holding designers more accountable for what was shipped.
Design practices for the agile process at scale
Through experimentation, we also found ways to better involve design at a macro-level. Here are a few things that worked well for us when scaling across scrum teams…
A common build environment — a place where designers, PMs, and developers could compare what had been built by dev teams to what had been designed and spec’d. This allows anyone on scrum teams to call out inconsistencies and spur discussion around design.
Monthly sprint reviews — a designated time for the whole product team and company leaders to come together to review progress. These are milestones for our team and are also a forum for designs to get greater exposure.
Friday lunch demos — a time and place for teams to demo their works-in-progress, creating an informal environment to see new functionality and mix and mingle with other team members. These can also provide a change to develop a more holistic understanding of what is being designed and built.
UX bug blitzes — designated times throughout the development cycle where groups of product teams get together to run through key user flows and log UX and UI bugs.
Design posters — visual artifacts (mockups, etc.) that designers put up in common spaces, such as lunch areas, hallways, and outside elevators that help spur impromptu conversations around design and allowed the our teams to challenge and improve upon designs during development.
During the time it took us to design, develop, and ship the Lightning Experience, we were able to demonstrate the value of design within our agile process and helped elevate the role of design within the company. This, of course, was not without challenges and it continues to be an ongoing endeavor of ours to champion design. We don’t have it all figured out, but as we continue to build upon the Lightning Experience, we go on to evolve our process.
Developing an effective agile framework is fluid and requires the time and involvement of many stakeholders. As designers and as design teams, we have an opportunity to inspire and motivate our teams to bring a more design-centered approach to build products. Let’s continue to do so.