Notes on LPL Design System
Rebuilding a component library against the system that actually renders it
Role
Product Designer at Perficient
Client
LPL Financial
This system is internal. Nothing in it is public, so there are no screenshots of the system itself and no figures I can share. What follows is how I worked and why.
Where it started
I picked this up while building pages for LPL's investor section. [LINK: investor experience case study] Components kept not matching what actually shipped. One offered a media slot that accepted video, and AEM only accepted images. Padding that looked right in Figma arrived different on the page. Text that fit in the file overflowed once real copy landed.
I went through the rest of the library after that, and most of it had the same problems.
An internal team had built the system, then moved to another project. Nobody had maintained it since, so the Figma library and the components running on the site had drifted apart.
———
What was broken
Hygiene. No variables anywhere. No auto layout. Layers unnamed, frames carrying duplicates of themselves. Atoms like buttons and form fields scattered rather than organized. No component properties, so changing a title meant going layer by layer. Color and text defined as styles rather than tokens. Spacing that varied for no reason. Components nobody had used in years.
Mismatches with production. This was the more expensive half. Components advertised capabilities AEM could not honor. Text boxes set to hug, or drawn generously, so everything looked pixel perfect regardless of length, while the real component enforced a character limit the file never mentioned. Constraints undefined, so like mentioned earlier, text and even images broke at mobile widths.
The mismatches produce work that gets approved, gets built, and then does not hold up. These components render on pages that advisors and their clients actually use, so a layout that falls apart at mobile width is money lost.
———
Taking it on
The VP of Design already knew about all of it. He had no bandwidth and there was no budget line for the work, which is the usual reason a design system stops being maintained.
I offered to take it on, with a condition: only once the week's commitments were done. That is why it was approved, and it is also why it has taken six months.
———
How I worked
One component at a time, no audit first. I had to open every component regardless, so listing them all beforehand would have meant the same pass twice.
For each one: the same copy and the same images loaded on both sides. Screenshot the live AEM version. Back in Figma, measure using rulers and fix what differs, then do the same at tablet and mobile widths. Test every capability the AEM component actually has, note what it does and what it refuses to do, and rebuild those as properties in Figma. Check the color and text combinations the component allows against contrast requirements, since a component that permits a failing pairing will eventually produce one. Annotate how it behaves and where its limits are. Test the rebuilt version. Move to the next one.
1-1.5 hours per component, across roughly 100 components. About 75% done.
I worked in a branched file and left the live library alone, apart from anything serious enough to fix immediately, and published at the halfway mark once there was enough to be worth adopting. Other designers were using the library throughout, and none of them had to work around me.
———
What I chose not to fix
An 8 point grid. I wanted one, for consistency, for scale, and so developer's life easy. But nothing in the existing system follows any grid, so adopting one means rebuilding every component in AEM and there was no budget for that. A grid that existed only in Figma would have widened the gap I was there to close, so I dropped it.
The missing capabilities. I could have pushed for AEM to build things like video support the file was already promising. Instead I stripped them out of Figma.
Both follow the same rule. Where Figma and production disagree, Figma is the one that changes.
———
What I got wrong
I started with tokens and spent a week on them. Every color, every possibility, buttons and containers and banners, defined exhaustively, and I was still only halfway through.
The reasoning was that nobody should be able to assemble a wrong combination. I still think that is the right instinct for a system used by people you will never meet. But my VP and lead pointed out that broken components were the larger problem, and that the token layer could grow alongside them instead of blocking them. They were right about the order, not the goal.
I moved to semantic naming, text-fill-primary, rather than a token defined for every component, and it covered the same ground at a fraction of the time.
What I would do now is treat them as one pass rather than two phases. Fix the component, define the tokens it needs while it is open, move on.
Where it stands
The clearest sign it is working is the questions that stopped arriving.
The creative team used to ask what size and aspect ratio an image needed for a given section. The content team used to ask how long a piece of copy could run and whether it would overflow on mobile. The AEM team used to come back after build to say a component could not support a sand background and would have to go back to white.
The file answers all three now, before anyone has to ask.
Other design teams are using the updated library. What they get out of it:
Pages get built faster
Developer handoff takes significantly less back and forth
Consistency holds across components instead of varying by whoever built the page
Contrast and accessibility rules built into the components rather than caught in review
No late "this component cannot do that" surprises, because the file says so upfront
What is in Figma matches what renders on the site, pixel for pixel, at desktop, tablet and mobile
That last one is the part I care most about.
The remaining 25% is the same process, component by component. Everything is documented inside Figma, annotated per component, covering behavior and limits, so someone else could pick it up where I left it. They would need to learn AEM first. That is the actual prerequisite for this work.
The library was the deliverable. What changed beyond it is confidence. Designers no longer hedge about whether what they see in Figma will survive implementation. The content team knows what will fit before writing it. The AEM team stops finding problems after the build. The file became something the whole team can work from, which it had not been for a long time.