Image for post
Image for post

Making design core to the agile process

A look into how we built Salesforce’s Lightning Experience

Ian Schoen
Jul 20, 2016 · 7 min read

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

Image for post
Image for post
Lightning’s Opportunity Workspace

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

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

Image for post
Image for post

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

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

Image for post
Image for post
Image credit IDEO

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.

Image for post
Image for post
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

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

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.

Moving forward

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.

Thoughts on design in the agile process? I’d love to hear! Find me @icschoen

Special thanks to Tatyana Mamut, JD Vogt, and Raymon Sutedjo-The.

Follow us at @SalesforceUX.
Want to work with us? Contact
Check out the
Salesforce Lightning Design System

Salesforce Experience and Design

A collection of stories, case studies, and ideas from…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store