About Joshua Briley
I've been building user interfaces for 20 years. That's long enough to have strong opinions about what makes a component library actually work, what makes one fail quietly, and why the same problems keep appearing in design systems regardless of how much the tooling has changed.
I spent most of that time in the space where design and engineering meet, not fully in either camp, but responsible to both.
Travelers
Accessible component library powering applications across the US and UK.
Web Components & React
Berkshire Hathaway Specialty Insurance
Component library built from the ground up, establishing front-end standards across an enterprise product.
Vue.js & Nuxt.js
America's Test Kitchen
Shared component system serving multiple editorial brands from a single architectural foundation.
React & Next.js
How do you build a system that makes the right output the natural result of using it, rather than the result of individual developers making the right decisions at the right time?
That's the question design systems are supposed to answer. Most of them don't answer it completely, not because the people building them aren't capable, but because the structural decisions that determine a library's long-term maintainability are easy to defer and expensive to reverse.
What 20 years actually teaches you
Early in my career, I learned to build things. That part is foundational.
What took longer to learn was how to see a system clearly: to distinguish between a library that works because the people on the team know its quirks, and a library that works because it's structured to produce consistent output regardless of who's using it. Those two things look similar from the outside until the team changes, the product scales, or an accessibility audit arrives.
I've worked in both kinds of systems. I've built both kinds of systems in the early years. Inheriting a brittle foundation and spending months working around it rather than building on it shaped how I work now.
Pattern recognition is what a consultant brings that a new hire doesn't. Not just the ability to do the work, but the ability to identify quickly which work matters.
How I approach the work
Accessibility as architecture
I don't treat accessibility as a compliance requirement. I treat it as an architectural constraint, one that shapes component API design, token structure, and documentation from the start rather than being addressed in remediation after the fact.
The distinction matters because accessibility built into the component layer is structural and durable. Accessibility added as a retrofit is fragile and expensive.
Documentation as delivery
I don't treat documentation as a deliverable that happens at the end of a project. A component that isn't documented accurately isn't fully built.
Documentation that describes the component as it was intended to work rather than how it actually behaves is worse than no documentation, because it produces incorrect implementations with confidence.
Directness over diplomacy
If an audit surfaces problems that are more significant than expected, I say so and explain why. If a team is considering a rebuild when targeted remediation would accomplish the same thing, I'll make that case.
The goal is for you to have an accurate picture of your system and a clear path forward, not a report that validates decisions already made.
Staying current as a professional discipline
The front-end landscape changes faster than any individual can fully track. Frameworks cycle. Build tools evolve. Specifications that were drafts when I first read them are now the baseline.
What I've found is that staying current requires treating it as a discipline rather than a side effect of doing the work. I follow the specifications that matter (the WAI-ARIA authoring practices, the Design Tokens Community Group format, the CSS working group drafts) rather than just the frameworks that implement them. When you understand the underlying standards, framework changes are context rather than disruption.
Rudiment UI
My open-source component library exists partly as a reference implementation and partly as a place to work through architectural decisions without the constraints of a client engagement.
Building something you intend to publish forces a different standard of care than building something for internal use.
Working together
I take a limited number of consulting engagements at a time. That's not a scarcity tactic. It's the practical limit of doing this work with the attention it requires.
I respond to every message and I'm direct about whether I'm the right fit. If I'm not, I'll tell you that too.
If your UI is slowing your team down, let's fix it.
Start with the scorecard for a quick read. Book a call to go deeper.