Project Captivate

Project Captivate is the title of an atomic design system I helped create during my time at Two Bulls. It’s custom built for Lord Abbett, a growing international financial investment firm. As their reach expanded, they looked to build a robust online brand presence to share their philosophy, approach, and offerings.

Over time, I designed 200+ web components and collaborated closely with developers to launch them, all while evangelizing to earn our clients’ trust.

Role
Designer
Timeline
2020 – 2021
Client & Team
Teammates
Part 1

The design system

lordabbett.com hosts thought leadership, portfolio information, and up to date insights on ever-shifting market forces. They planned to publish scores of new webpages as soon as possible. Quick growth was expected.
The design system is used to build the following website
We partnered with Lord Abbett developers to build a toolkit of reusable custom components. These simple “building blocks” allowed their in-house content team to spin up new webpages on the fly using AEM.
Some examples of the ‘building block’ components:
Reusability was the core of our strategy.
Each component was a balance of brand recognition and generic-ness. We usually designed with vague content patterns in mind rather than content-first. Using this mindset we could design 5 headers that serve 200+ news stories, for example.
Over time, we created a library of patterns that the content team could draw from. This meant they could publish polished, final webpages with little to no hands-on work from a designer, saving Lord Abbett time and money.
We used atomic design methodology to drive our approach and our language, which helped us align strategically with developers.
When developers knew a Block or Element was intended to be reused, they could build it with a scalable structure in place. The tech debt we avoided with a coordinated strategy made everyone’s lives easier.
The atomic mental model communicated structure. Every component could be broken down to its base elements, which could be as simple as spacing, fonts, and colors.
Buttons, header fonts, link fonts, pills, etc. were duplicated across components. For designers, that let us make a decision once about what the brand ‘feels’ like, and cascade changes to dozens of components at once with shared code.
For viewers, the repeated elements subconsciously reinforce the idea of the brand. Soon, it only takes a glance to know you’re reading Lord Abbett. Any large brand aims to be consistent. With our approach, scalable consistency was built in from the start.
Over time we created a ‘lego box’ of UI pieces for the development and design teams. With some imagination, anything could be wrapped and published in the style of Lord Abbett.
During this project, I learned to design within our system – reusing as much as possible, and only introducing new elements if the situation required something new. This project had an excess of developers, so design solutions needed to be high impact. Building was a constant trade off between brand and engineering. Essential brand moments couldn’t be too complicated when we had hundreds of components to build. At all levels , I ensured my solutions introduced value that could scale and be reused.
The main constraint in this project was time – we managed a large team of developers, so my value as a designer needed to be immediately realized. I gained valuable experience managing a team of developers and collaborating on delivering quick and effectively.
Part 2

Systems for collaboration

We were delivering dozens of components each sprint, each of which required designers create markup documents (a time consuming process).
There was a glaring problem, though. The format we used wasn’t really cutting it.
On top of the time-consuming process of making these documents, designers were often left explaining important information in tagged comments and 5-minute Zoom calls.
The original format of our markup docs. This basic structure we used made it hard to include all the detail developers needed to know.The original format for redline (in our case, blueline) documents.
To bridge the gap, I redesigned the format for our handoff documents.
My redesign created space to explain in detail, so less got lost in translation.
Addition of right rail - shown in red
Added a column to explain relevant details that are required for the build.
That allowed us to include type / color styles and write detailed explanations, reducing need for extra meetings.
I also introduced new tools to help speed up our workflow.
‘Atomic level’ iconography
Icons signifying “levels” allowed us to more easily show how we intended to build reusabile pieces of our system.
Essential-info checklist
A list that helped our design team make sure to include the information developers needed most.
The list was compiled by auditing previous handoffs and Q&As with developers.
‘Breakdown tools’ stickersheet
A collection of well-crafted Figma components helped our team mock things up just a little quicker.
The redesign had structure to get us started quickly & flexibility to let us explain details when we needed.
After this format was adopted, collaboration between designers and developers on our team got a lot simpler.