Product Design

Under the hood: Updating LinkedIn's UI

Authored byJitesh Gandhi

Engineering Leader with a Passion for UX and Inclusivity

October 22, 2020

Co-author: Jitesh Gandhi and Eric Babyak

Across LinkedIn, we recently launched a new design that brings a warmer, more inclusive feeling to our products. Throughout the planning phases of this process, we were met with challenging questions in implementing this redesign, such as, “How do you modernize and refresh a user interface (UI) across three applications that combined have over 5,000 pages and hundreds of developers working within that code every day?” and “How do you do this while not blocking product development for our 706+ million members leveraging our platform?” It turned out to be quite the engineering challenge. This is the story of how many teams worked together to update the LinkedIn UI in less than 60 days—from kickoff to launch.

Thinking through our approach

To start, the client engineering and design infrastructure team had to create a plan for how to implement the new design across LinkedIn keeping the challenges outlined above in mind. However, we had some immediate constraints:

  1. Changes had to occur across our Android, iOS, and Web experiences at the same time
  2. We could not have any “Frankenstein” instances that mixed the old UI in some places with the new UI in others

We narrowed it down to two paths:

  1. Redesign and move to the new UX infrastructure to fully embrace the new design system, or
  2. Embrace as much of the new design language as we can today, while enabling us to later fully adopt the new design system in a transparent and seamless manner

As purists, we wanted to do the first option. It realizes the full design system, provides us with the opportunity to clean out years of tech debt, and would allow us to adopt a modern and extensible design infrastructure.

To complete a migration of this magnitude, we could stop all product feature work (this would be the fastest path, but we would not be able to roll out any new features) or continue product feature work (the much slower path, but allowing for new features) before we could “flip the switch” to the new design. Because we prioritized continuing to develop new features and needed a fast path to deliver the new design to members as soon as possible, we proceeded with the second option.

What we tackled first

Throughout the implementation of our new, more inclusive design language to LinkedIn, it was important to not disrupt the member experience. Similarly, we did not want to impact any work that other engineering teams were doing to bring important new features to our members. These goals resulted in the following high-level technical constraints:

  1. The bulk of work would happen within our application infrastructure code and would be transparent to our product engineering teams.
  2. We would leave our current design in place while implementing the new design language transparently to members.

In order to avoid disrupting teams and features in flight, we only adopted design changes that did not impact layouts for this redesign. The areas that we believed would maximize impact to the member experience included colors, shapes, icons, and illustrations.

image-showing-our-redesign-focus-on-colors-illustrations-shapes-and-icons

Our redesign focus

How we updated LinkedIn behind the scenes
Our adoption of LinkedIn’s new design language across all platforms (Web, Android, and iOS) was a massive undertaking involving over 50 teams and many other stakeholders. We decided to start this process with Art Deco, which is our internal UI library that provides guidelines for text, color, spacing, and common components, such as labels, buttons, and containers. However, even with this infrastructure, we faced two major issues in implementing the new design language:

  1. Art Deco does not have theming support, instead, the styling is strictly defined in the library to ensure consistency across platforms
  2. Our product is vast and adoption of the Art Deco UI library was not 100% across all platforms, leaving gaps for infrastructure-controlled styling

To address the first issue, the team began by creating mappings. These mappings pointed a color, icon, or illustration to its representation in the new design system (see diagram below). Additionally, the new design system reduced the total number of icons and illustrations, requiring the creation of more complex mappings that pointed multiple icons or illustrations to a single one in the new design language.

flow-chart-showing-client-requests-being-evaluated-to-determine-if-the-new-mapping-for-colors-or-icons-should-be-used-and-providing-the-appropriate-replacement

Client request flow example for design assets

The usage of these mappings was toggled behind “flags,” which are variables on each platform controlled by server endpoints. This approach was critical in enabling teams to continue working and building out features using our existing design. This ability to toggle also kept the redesign transparent for members, and enabled A/B testing. This testing allows us to roll out the new design in phases and fine-tune the redesign based on metrics and member feedback.

Any complex changes to components that could not be made through mappings were made within the components directly in the Art Deco library and behind the same toggle. This approach minimized technical debt and allowed us to continue usage of the shared library without branching and incurring additional maintenance costs.These infrastructure changes resulted in minimal disruption to our product teams.

The next step was to adopt the new design language for the parts of our apps that had not fully adopted Art Deco. We built a semi-automated auditing tool to help teams identify any remaining house cleaning efforts. This tool highlighted the areas on each platform that were using Art Deco components and styling. Areas that were not highlighted then required investigation by the product team.

screen-shot-of-the-infrastructure-highlighting-tool-on-web-that-shows-which-parts-of-the-screen-are-using-infrastructure-and-which-are-not

Components in magenta are infrastructure components or styling

Scaling remaining work to product teams
Once the infrastructure changes in Art Deco were complete, the teams that owned the product features began the work to adopt the new design language. To help, we provided them training materials and guidance on how to update components in place. A key piece of this guidance was a cheat sheet with specifics on the style changes for each component update.

table-showing-visual-comparisons-of-buttons-checkboxes-and-toasts-along-with-notes-on-the-style-changes-from-the-previous-design-to-the-new-design

Snippet from our component cheat sheet

The cheat sheet was accompanied by more detailed guidance for each platform. For the web platform, we introduced a Sass function and mixin to help teams more easily apply these new styles in a consistent manner. The ui-token function converted predefined tokens into values to use with properties like colors or border radius. The nds mixin allowed for styles to only be applied when it was enabled. These also helped us to remove and replace reSTYLE, which inlined predefined groups of styles and was very difficult to toggle based on a flag.

// Mixin to be used inside a selector
.foo {
  background-color: #0073b1;


  @include nds() {
    // Function to use defined tokens
    color: ui-token(color-primary);
  }
}

Simple example of the Sass function and mixin

Leaving ourselves in a better technical state

In addition to updating our UI to better embody the inclusive, warm, and welcoming community of individuals who make LinkedIn, LinkedIn, we have further pushed our products to fully adopt the new design system while largely avoiding additional technical debt. We can update our UI significantly faster today than we were able to when we started because we took this opportunity to not only leverage as much infrastructure as we could, but also provide a common framework for gaps not covered by infrastructure-controlled styling. This will allow us to experiment and iterate in the coming months to learn what works (and what doesn’t) for members with our new design system.

We will be able to adopt other parts of the design language, like layout changes, without them looking out of place and creating a “Frankenstein” experience. We will also be able to introduce the new infrastructure for this design system much more seamlessly into our product on a timeline that makes sense for our product teams and avoids a massive migration. We are providing valuable feedback on the new design system before all of LinkedIn’s products adopt it.

Lastly, development of the new infrastructure is now far enough along that we are able to align anything we redesign or build more closely by adopting the new language, including semantic tokens. This process of abstracting colors and other design system variables has changed our developer approach and language to be more semantic for these design terms. Doing this now makes adopting the new design system easier, and opens up opportunities to bring more UI improvements to our members.

Acknowledgments

We would like to thank the core infrastructure engineering team for making this possible: John Robinson, Abhishek Nancherla, Luis Torres, Bryce Pauken, Christopher Wilson, Daniel Hagman, and Jensen Kuo. We’d also like to shout out our key infrastructure partners—Chris Leonavicius, Tian Sun, Bryan Levay, Yeli Arenyeka, and Domenic Santangelo—as well as Samson Choi, Alex Lakas, and Tony Lai for supporting our early tests.

A big thank you to our design and research partners: George Penston, Oscar Gonzalez, Jessica Clark, Nate Whitson, Joe Farquharson, Karolina Sadocha, Aryel Cianflone, and Craig Mackintosh.

Thank you to the team that helped execute this project: Vivek Tripathi, Yoshi Komada, Mark Hill, and Zuki Ndulo.

Thank you to the executive team that placed their trust in us to execute this project: Nisheth Joshi, Erran Berger, Joann Wu, and Kiran Prasad.

Lastly, a huge thank you to the many engineers and designers that came together and made all of this a reality.

Topics: Product Design Infrastructure

Related articles