Ever felt like your design team is stuck re-inventing the wheel (or rudder, in our case) for every project? That was us at ShipServ not long ago. As a design manager at a fast-moving maritime tech company, I faced a sea of inconsistencies – buttons styled six different ways, ad hoc colour choices, and product screens that felt like distant cousins rather than siblings. Design requests piled up, and our velocity lagged. Something had to change. So, I donned my captain’s hat and introduced a unified design system to right the ship. The result? We slashed our design time, boosted consistency, and even made our users happier – all while cracking a few jokes and learning invaluable lessons along the way. This post dives into how we did it, the challenges we hit, and why our “Lighthouse” design system became the beacon guiding our team to faster, better design (with a dash of fun).
The Storm Before the Calm: Why We Needed a Design System
Before Lighthouse (our aptly named design system), ShipServ’s design workflow was a bit like a stormy sea. We actually had an old design framework, but it had drifted out of date and fragmented over time, causing widespread inconsistency and confusion. Different teams interpreted guidelines differently, and our “single source of truth” was no longer singular or truthful. For example, our colour palette had multiplied into a rainbow of trouble—we discovered multiple shades of “ShipServ blue” across the product. Worse, some of those hues didn’t meet accessibility standards, and users complained about low-contrast text that was hard to read. We also lacked proper documentation; new designers would join and ask, “Which button style is the real one?”—and no one could tell them! (Ouch.) With no documentation or clarity, using the design system became a guessing game.
On a personal note, I found myself spending more time policing pixel inconsistencies and hunting down the right components than actually designing. It was, frankly, a headache. Our sprint burndown charts showed design tasks dragging on as we repeatedly fixed the same UI issues. The verdict was clear: we were rowing upstream with a leaky boat. To boost our speed and sanity, we needed a unifying solution. Enter the design system.
Plotting the Course: Building “Lighthouse” (ShipServ’s Design System)
I knew that implementing a design system would be a sizable undertaking – like fixing a ship while still at sea. We couldn’t exactly halt all product work, so we took an incremental approach. I started with a thorough audit of our existing UI: every style, component, and pattern in use. The findings fueled my resolve: we had dozens of mismatched components and a disorganised colour scheme. Armed with this, I made a plan to rebuild systematically. Some key steps in our journey:
Adjacent System for Minimal Disruption: Rather than scrapping the old system overnight, we built the new design system in parallel. This allowed designers to gradually adopt components from the new library without derailing the ongoing sprint. It was less “ta-da, new system today!” and more a stealthy phase-in. This adjacent approach kept our stakeholders calm – features still shipped on time while Lighthouse was under construction.
Atomic Design & Figma Mastery: We adopted Atomic Design principles for our new system. I started with the foundations – colour tokens, typography, basic UI atoms – and then combined those into molecules and more complex organisms. Figma became my shipyard: we leveraged its latest features (like components within components and variables) to build a robust library. For instance, the humble button component got a complete makeover. Initially, we had a dozen inconsistent button styles with fixed widths and limited flexibility. By nesting components and using Figma’s variability, we created a single Button that could morph to any state or size needed, from primary CTAs to tiny text links – all consistent by design. This not only decluttered our palette of buttons but also made it dead simple for designers to grab one master button and tweak variants, instead of copying a similar button from an old file and hoping it behaves.
Unified Colour Palette with Accessibility Built-In: Our colour system needed profound love. We curated it down to a set of scalable, meaningful colours with proper naming (goodbye “#0F72EE” and “#0F73EE” confusion, hello “Primary Blue”). Every colour was checked against WCAG contrast guidelines to meet accessibility standards—no more illegible grey text on grey backgrounds. In fact, ensuring WCAG AA compliance was a non-negotiable principle for Lighthouse. By baking accessibility in from the start, we avoided having to fix contrast issues later (and our users’ eyes thanked us). We even included usage guidance in the Figma library – e.g., which colour combos to avoid – effectively making accessibility “auto-pilot” for our designers.
Comprehensive Component Library: I compiled a giant spreadsheet of every UI component in our product, then marked which to refactor, replace, or retire. It felt like spring cleaning: some components were merged, others were tossed overboard. In the end, we distilled the UI into a library of 50+ standardised components (56, to be exact) spanning all common patterns – forms, modals, tables, you name it. Each element was built to be flexible (thanks to Figma variants) and documented with usage notes. For the first time, our team had a shared playbook of UI elements. A designer described it as going from “Lego pieces scattered on the floor” to “a tidy box with compartments” – you can imagine how much faster you find the right piece now.
Storybook Integration: Crucially, we didn’t build this system in a design silo. I looped in our front-end developers early, syncing the Figma components with a Storybook (code component library) effort. This cross-functional push was a game-changer. By the time we finished designing a component in Lighthouse, our engineers had a matching coded component ready in the repository. No more “the design looks different from the product” – they were two sails on the same mast. In hindsight, getting devs involved from day one was key to success (and something I’ll never forget in future projects). It fostered shared ownership: the design system wasn’t just a UX or dev thing; it was an everyone thing. This collaboration also meant our Storybook served as living documentation for developers, reducing back-and-forth on how things should look or behave.
Throughout the build, I kept the team in the loop with regular show-and-tell sessions. We gave the system its nautical nickname “Lighthouse” to fit our maritime culture (and because who doesn’t love a good lighthouse metaphor?). It honestly started to feel like a lighthouse—shining a light on the rocks (design pitfalls) and guiding us toward a unified style.
Rough Seas: Challenges and Lessons Learned
Was it all smooth sailing? Ha, I wish. Implementing a design system came with its own choppy waters that taught me (and my team) a ton:
Selling the Investment: Initially, not everyone was on board with pausing some feature work to focus on a design system. I had to make the case to leadership that this wasn’t just “design playing with new toys” but a strategic move to increase velocity and quality. We backed this up by showing how often inconsistencies and redesign churn were slowing releases. One slide from my pitch deck literally showed six different button styles from our product – that visual alone made the point. In the end, leadership gave us the green light (and trust) to proceed, but it took education and securing some quick wins to prove the value.
Underestimation of Scope: I confess—I underestimated just how much work a complete design system overhaul would entail. What started as “let’s clean up the style guide” grew into a months-long project refactoring over 100 components and assets. At one point, I joked that I’d aged a year in the few months of building Lighthouse. It was far greater in scope than I anticipated, and there were moments I worried we’d never finish. The lesson? Plan realistically, and break the work into phases. Also, don’t do it alone—which brings me to…
Collaboration is King (or Captain): Early on, I made the mistake of tinkering away in isolation, imagining I’d unveil the new system like a surprise gift—wrong move. I quickly learned that engineers and other stakeholders must be co-creators. Once I involved the front-end team and even folks from Solutions and Product, the implementation accelerated. Developers helped hook components into our app’s codebase, and product managers offered input on patterns that needed rethinking. This multi-team effort ensured the system wasn’t just a UX pet project, but a solution that worked for everyone. As one engineer quipped, “We finally speak the same language as design!” That alignment was golden. My takeaway: a design system is a team sport – you need your devs and product folks on the field, not on the sidelines.
Change Management & Adoption: Even after building the system, we had to nudge the team to adopt it gently. Old habits die hard; a few designers initially kept using outdated assets out of familiarity. To tackle this, we held internal workshops and made Lighthouse super accessible – literally one click to install the Figma library, with documentation and even plugin links included. We also archived old components to remove temptation. Over a couple of sprints, usage of the new system went from tentative to ubiquitous. The turning point was when people saw it actually saved them time. One designer told me she finished a new feature mock-up in half the time because she wasn’t drawing components from scratch—“It’s like I got my evenings back!” she joked. That’s when I knew Lighthouse had truly been embraced.
Perfection vs. Pragmatism: Another challenge was deciding how polished the system needed to be before release. I wrestled with questions like: do we include every possible component now, or evolve as required? Ultimately, we launched with an MVP design system that covered our most common UI needs (roughly 80% of cases), and we documented a backlog of nice-to-have components to add later. This pragmatic approach meant we delivered value sooner and didn’t get stuck in endless pixel-perfect tweaks. A design system is never really done, and that’s okay.
Smooth Sailing Ahead: Impact on Velocity and Consistency
Once Lighthouse was in play, the differences were night and day. Our design process went from sluggish to swift. We started tracking our sprint burndown metrics more closely to quantify the change. The data spoke loud and clear: our design team’s throughput (tickets or tasks completed per sprint) increased by about 8% after the design system rollout. That may not sound huge, but in practice, it meant we squeezed in extra tasks and hit deadlines more reliably. Designers were spending less time on rote work and more on actual problem-solving, which boosted morale as well.
Even more impressive, our end-to-end design cycle time – from kickoff to final designs ready for dev – became roughly 30% faster on average. We shaved days off the design timelines for specific features because so many elements were prepared to go out of the box. Need a new admin dashboard? We already have the table grids, form fields, buttons, and colours all standardised – assemble and tweak. It’s like comparing hand-drawing each Lego block versus snapping together pre-made pieces. This speed gain was a direct competitive advantage; our product team could respond to customer needs quickly. (One PM literally asked me, “Did you guys find a cheat code?” because suddenly, design was ahead of schedule!).
Consistency-wise, the product’s UI cohesion went through the roof. We achieved the holy grail: a uniform look and feel across our platform. No more Frankenstein screens. This consistency also led to fewer design-related QA issues. Previously, we’d get bug reports like “font size on Page A doesn’t match Page B”—those virtually disappeared. Our support team noted that users seemed less confused by the interface changes because patterns were predictable and familiar. In fact, user satisfaction scores ticked up in post-release surveys after the design system was implemented. While many factors influence user sentiment, I’m confident our more polished, coherent UI played a role. The design case study even highlighted ShipServ’s overhaul as resulting in “better user satisfaction,” alongside the efficiency gains.
Perhaps my favourite metric: the sigh of relief factor. Okay, it’s not a fundamental metric, but it was palpable. Designers weren’t sighing in frustration at conflicting guidelines anymore – they were sighing like, “Ahh, the component I need is right here.” Our team could focus on higher-level design challenges (user flows, UX strategy) rather than nitpick whether this week’s modal had an 8px or 12px border radius. The cognitive load on design decisions dropped significantly. New hires ramped up faster, too, since they could rely on the system rather than tribal knowledge. All told, the design system became a force multiplier for velocity and quality.
Reflections: What I’d Tell My Fellow Design Managers
Implementing a design system at ShipServ has been one of the most challenging yet rewarding projects of my career. It wasn’t just about creating a style guide; it was organisational change, cleanup duty, and forward-thinking strategy all in one. Some final reflections and tips from the journey:
Track and Celebrate the Wins: From the start, decide on a few metrics to measure (e.g. design task velocity, UI bug count, etc.) and track them through the rollout. This helped me prove the value to stakeholders. When we saw that ~30% faster design cycle stat, you bet I shared it in our all-hands! It builds momentum and justifies the effort.
Design Systems Are Hard (But Worth It): It’s easy to read shiny blog posts about design systems and underestimate the effort (guilty as charged). Building components is fun, but maintaining them and aligning them with production is a much bigger effort than it appears. Prepare your team for this to be a marathon, not a sprint. However, once you cross that finish line (or even reach a good cruising altitude), the payoff is immense. Our team now wonders how we ever lived without a design system.
Involve Engineering Early and Often: I cannot overstate this – a design system lives or dies by adoption. If your codebase isn’t updated in tandem, you’ll have a pretty Figma file that nobody uses. Our success was primarily because devs were partners in the process, not recipients. This collaboration ensured that what we designed was feasible and was implemented near-simultaneously. Plus, it created advocates for the system outside the design team.
Keep it Fun and Authentic: We kept the tone light throughout the project—from naming it Lighthouse to sharing the occasional meme about “design system struggles” in team chats. This wasn’t just frivolous; it helped keep morale up during heavy workload weeks and made the project feel human. Thought leadership doesn’t mean you have to be overly stuffy. In fact, I’d argue a bit of humour and storytelling helps land your message. I often used analogies (like our ship-at-sea one) to help non-design colleagues grasp what we were doing. If you can laugh together, you can work together more smoothly.
Never Stop Evolving: Finally, launching a design system isn’t the end – it’s version 1.0 of an ongoing product. We set up a governance process that allows any team member to suggest improvements or new components, and we regularly refine them. Staying open to feedback kept Lighthouse from becoming a rigid artefact. As our product grows, so will the system. In retrospect, I’m glad we treated it as a living program rather than a one-off deliverable.
Closing Thoughts
Implementing a design system at ShipServ was a journey from chaos to cohesion. It required vision, patience, collaboration, and yes, a sense of humour to get through the tricky bits. But looking at our faster design cycles, the consistent UI, and a happier team and user base, I’d do it all again in a heartbeat.
For any design managers out there feeling the pain of design inconsistency or slow turnarounds – consider investing in a design system. It might just be the lighthouse your team needs to navigate out of the fog. And trust me, the view from the deck is much better when the sun is shining on a well-oiled design process. Anchors aweigh, and happy designing!
