Role
UX Designer
Tools
Figma · Miro · Kentico
Timeline
Q2 2026 – present
Status
Design complete · Development in progress
Responsibilities
Design systems · UX/UI design · Interaction design · Stakeholder collaboration
Corporate One's public website was redesigned in 2022 in Kentico, with a set of custom widgets and page types built to support it. Over the four years that followed, the site kept needing new functionality that we no longer had the development capacity to build. It grew to more than fifty core pages plus a continuously expanding library of resource articles, event pages, and landing pages, and most of that new content was built using our rich-text widget, which is essentially a container for dropping in custom HTML with inline CSS at most.
I'm one of a small number of people at the company outside our developers who works in HTML and CSS, so much of that implementation ran through me and a couple of colleagues. I know the workflow firsthand: find a similar element elsewhere on the site, copy its HTML, paste it in, edit it, and add inline CSS to close the gap.
In 2026 we brought on a development vendor and could build custom widgets again. Our marketing director tasked me with the project: bring the public website back into consistency, and keep it that way as it grows. Figuring out how was up to me.
I audited the site independently and brought a plan to leadership structured in two phases:
1. Design.
Global styles first, then a component library built on them.
2. Implementation.
Development projects with our vendor to apply the new styles and build the widgets.
One thing shaped every decision after this: the components had to be easier than the workaround. The rich-text widget wasn't going away, and I'd been on the other side of that choice enough times to know which one wins on a deadline.
Four years of building this way produced what you'd expect: multiple versions of the same card, hero banners at different widths, and variation in styling across similar elements depending on where you encountered them. Each of those decisions made sense at the time. Someone needed a new page, and they used the only tool they had. Four years of that adds up.
Our executive leadership team raised the concern that the site no longer felt like one site.
Example of three different card components that we identified on the website.
My audit was one designer's perspective, so I ran a workshop with the broader stakeholder group, including people from each of the four teams that own content on the site. I shared the site ahead of time so people arrived having looked at it themselves, presented what I'd found, then opened the floor.
I compiled everything into a Miro board, organized by category with screenshots documenting each inconsistency. From there I grouped related findings together and proposed the scope my team reviewed and approved. We planned to standardize the global styles and develop ten widgets covering the recurring patterns across the site.
Screenshots from Miro Board where we took notes and screenshots of inconsistencies.
Before designing individual components, I created a foundational style guide establishing shared visual rules across the website: color, typography, spacing, border radius, shadows, and standardized buttons, links, and interactive states.
I defined these as a shared set of values that both the component designs and the site CSS build from, so the design files and the implementation stay aligned as the system grows. Creating them first also gave me a consistent set of rules to design against, so each component wasn't its own separate styling debate.
Aligning beyond the website.
The style guide reconciled three inputs: our existing brand guidelines, the OutSystems-based design system we were phasing out, and Google's Material Design, which our newer internal systems are being built on. Aligning to Material meant more work upfront, but it puts the public site in the same visual language as everything we build next instead of setting up another reconciliation project in two years.
The full design standards document, covering color, typography, spacing, and interaction states.
Working from the approved standards and the audit findings, I designed a library of ten components in Figma covering the recurring content patterns across the public website.
I built them as working components. Variants, states, and properties can be toggled directly in Figma, so anyone reviewing could see how a component behaves across content scenarios before it was built. Each is specified with its variants, states, responsive behavior, and accessibility requirements so it hands off to development as a complete definition. Knowing what these would become in code shaped how I specified them.
The library had to work for the content we actually publish, not ideal content. Each component holds its visual and structural rules constant (type scale, spacing, radius, states, responsive behavior) while allowing the content inside to vary. That way a single widget serves multiple use cases across the site instead of generating a new rich-text variation each time the content changes.
Building the library in Figma also changed how we plan new pages. Instead of building something in Kentico to see whether it works, we can assemble a page from existing components and review it before implementation, which makes it much easier to iterate on a page before committing to it.
I brought the library to weekly reviews with my team, where most of the refinement happened.
The full component and widget library, with each component's variants, states, and usage defined for development.
The project delivered an approved style guide, a library of ten defined components, and a prioritized implementation backlog.
I ordered that backlog by impact rather than by effort. Cards are first, as we found more variations of them than anything else, so standardizing that one widget does more for the site than several smaller ones would. Buttons and other small elements come later in the sequence.
Global style changes go to our development vendor first, followed by widget development against the Figma specifications. As each widget ships, it replaces the rich-text workarounds it was designed to make unnecessary, including the ones I built myself.
10
components designed
1
unified style guide
4
years of inconsistency addressed
Before and after — showing how three existing cards will look with new standardized widget.
The audit gave leadership something to decide against.
Four years of drift is overwhelming to act on, so before proposing anything I documented it. I created the Miro board organized by category with screenshots of each inconsistency, then a workshop with people from all four teams that own content on the site. The findings came back grouped into recurring patterns rather than a list of complaints. This made it easy to scope ten widgets and a style guide. The prioritized backlog came out of the same material, ordered by impact rather than effort, with cards first because we found more variations of them than anything else.
The audit gave leadership something to decide against.
We've agreed on a process for when a page needs a pattern the library doesn't cover, which is to open a project with our vendor so the library grows instead of getting worked around. My concern is what happens under deadline pressure, because standing up a development project takes longer than a page sometimes has, and the rich-text widget will still be sitting there. It is a reasonable stop-gap and it kept the site running for four years, but the same convenience that made it useful is what caused the drift in the first place. The system does not remove that risk on its own. What it does is make the right path easier than the workaround, and whether the site stays consistent depends on the team choosing it while the fast path is still available.
What we’ll be able to measure.
Once implementation is underway, Google Analytics and Microsoft Clarity give us engagement patterns on key pages and session recordings showing whether people are finding what they came for. I'd expect any effect to show up in behavior rather than in feedback. Visitors to this site aren't completing complex flows; they're navigating, reading, and reaching sales or support when they need to, and consistency helps with those tasks by making the site easier to move through without being something anyone consciously notices. Our audience is specific enough that meaningful quantitative comparison would be difficult to gather, so qualitative conversations are the realistic option, as long as we're clear that what we'd learn is whether the site feels more put together rather than whether anyone noticed the specific changes that made it so.
Where this work sits.
This is as much a marketing effort as a UX one, and I don't think a user consciously registers that a card's border radius changed between two pages. Regardless, our public-facing site is the first thing most of our members see, and a coherent experience is expected.
Want to talk through this project?
I’m happy to share more about the audit process, component decisions, and what I learned from bringing a live public website back into a maintainable system.
© 2026 Michelle Magruder · Public Website Consistency