UI Frameworks: Custom Needs vs. Off-the-Shelf Tools
UI frameworks ship with ready-made components and default styling, but how far can those defaults take a real product? For developers, the convenience is obvious—pre-built styles save time. But relying on default styling assumes whoever built the framework designed those components well for your specific use case. That assumption deserves scrutiny.
This is the question explored in the latest episode of the Smashing Podcast. Drew McLellan talks with UX designer Stéphanie Walter about what teams should weigh when building applications on a UI framework.
Component Libraries: A Foundation, Not a Finish Line
Frameworks provide a useful starting point for interface development. However, the gap between what a framework offers out of the box and what your application actually needs can be significant. Custom user requirements often demand design and behavior that generic components don't anticipate.
The key, according to Walter's perspective, is to approach a framework as a structural base rather than a finished product. Using default styling without evaluation risks shipping an interface that doesn't fully address your users' needs.
Accessibility and Brand Consistency
Some considerations to keep in mind when selecting and using a UI framework:
- Assess whether the framework supports accessible patterns that your project requires. If not, how much work is needed to fill gaps?
- Default styling rarely aligns with a brand's look and feel. Teams often need to customize components, which can require writing additional CSS—partially defeating the purpose of the framework's built-in styles.
Rather than blindly trusting a framework's defaults, probing those areas early can help avoid redesign and rework later in a project.
Framework Features vs. Custom Development
UI frameworks bundle useful interactions and components, which helps developers avoid inventing common patterns from scratch. Yet, forcing a product into a framework's constraints can produce friction. Every framework makes trade-offs between flexibility and convenience.
Finding a balance is an integral part of the decision-making process, whether one is building a dashboard or communication-heavy application. Evaluating the project's particular needs in light of framework strengths and weaknesses is the safest path forward.
Weekly Update
UI Frameworks Don’t Replace Designers
User experience designer Stéphanie Walter joins the podcast to discuss working with off-the-shelf UI frameworks like Material-UI and Ant Design. She argues that while these tools provide a strong starting point for development teams, they are not a substitute for design thinking — even when budgets and timelines are tight.
The Role of Frameworks in Modern Teams
Walter sees UI frameworks frequently in large IT teams, especially where dedicated designers are scarce. Material-UI, for example, offers a Google Material design look for Angular and React projects, but it is a separate implementation with its own constraints. Ant Design, another React framework popular in some circles, even provides Sketch files to help designers align their work with the components developers will use.
She notes that in many internal product teams, frameworks are chosen simply because they are convenient for developers — the components are already built, and there may be no designer on staff at all. That convenience, however, only covers the visual layer.
“The role of the UI designer is not just to decide about should the button be red, green, orange, blue,” Walter explains. “Usually the role of the UI designer is information architecture, understanding user needs.” Even with a framework in place, someone must still decide what goes on the screen, how it behaves, and how users achieve their goals.
Compromise Is Inevitable
Building usable interfaces with a framework is possible, Walter says, but it requires accepting trade-offs on both sides. She cites a common example: Material-UI’s ripple effect on buttons. It works well on mobile for large tactile feedback, but on desktop it feels excessive. Removing it, however, would require complex rework inside the React implementation, so her team keeps it and adjusts other aspects of the interface instead.
Some requirements, however, are non-negotiable. Walter describes working on an airline project where standard calendar components failed to meet the user’s needs
—they needed to display prices and departure/arrival information in ways basic frameworks do not support. The team kept the calendar grid but added custom React development on top. This mixed approach—using a framework’s base component and enhancing it—struck the right balance.
“It’s about compromises on both sides,” she says. “Do we use the basic component? Do we create a custom one that will fit the user needs? Or do we make a mix of the two?”
Beyond Themings, Customisation Has Many Layers
Customisation often goes deeper than developers would prefer. Walter describes a project where the team used a card component to build a modal window. The card already had the needed structure:
- a background
- a header with a title
- buttons at the bottom
The modal behaviour, however, differed enough that semantics became an issue.
Consider the difference between a link and a button that clears a form. The link navigates; the button performs an action. Walter’s developer preferred using an anchor tag with an href because the framework did not offer a styled button without a button shape. She pushed back, as the element does not open a new page but clears the form—so semantically it must be a button.
Accessibility adds another layer. Walter notes that deep nesting of interactive elements—buttons inside divs inside divs—creates problems for assistive technologies. She wants to ensure the basic components work well for everyone, not just sighted mouse users.
Start Research Before Choosing Tools
Walter stresses that user research should precede framework selection. Her current project, a migration from a 10-to-15-year-old internal application to a new Material-UI React interface, is a case study in that principle. The old system had grown organically, with users requesting features directly from IT over the years, resulting in around 400 pages of tables within tables—some containing content that should not even be in a table at all, like simple key-value pairs.
Through workshops and discussions with internal users, Walter’s team identified distinct goals—planning, monitoring, reporting, and collaborating—and discovered that some features slated for later migration were actually critical daily workflow tools. This understanding changes whether data is best displayed as a table, a histogram for evolution over time, or a pie chart for part-of-whole comparison. A designer must decide this, not the chart library.
“Usually it’s not a developer job to do that,” she says. Developers are highly skilled, “but they are not super qualified to say this data should be displayed like that.”
For testing, she mixes methods. Paper prototypes and quick development, then usability tests on screens when the change is complex or entirely new. For form-heavy workflows, building a working form is often more efficient than InVision mockups, as the front-end behaviour of auto-completes and validation matters. She also mentions guerrilla testing—recruiting through social media, remote screen-sharing—as a low-cost option when direct access to the public is limited.
Process Lessons from the Field
- Recommend cheap, safe tests — even a dozen users on a platform like Whereby can catch issues before heading to build.
- Be wary of tech limitations — some users test on virtual machines or cannot install tools; adapt with a phone call and screen sharing.
- Test early and often — if retesting after the final build is not possible, make it a habit to go back to users or at least run A/B tests post-deployment.
Selecting the Right Framework Is a Team Decision
Framework choice is rarely a pure design decision. Walter advises that everyone—designers, developers, and architects—should be involved. The technical architecture may influence the decision, as might accessibility needs. In her experience in Luxembourg, accessibility legislation applies to some institutions, and checking that a framework meets those standards later is painful. “It’s a little bit too late” to discover compliance issues after a few months of build, she warns.
Yet, in practice, the choice often comes down to developer familiarity and comfort. Walter has seen teams pick Ant Design or Material-UI because developers were already proficient, even when the product’s requirements were not yet fully mapped. The result is a framework that might not align with the user flows, or that lacks components needed for main navigation. She advises that, unless you are certain a framework covers your needs, you should have at least a rough idea of content and navigation first.
Styling: The Visible Customisation
Developers often value frameworks for the default styling that comes out of the box. Walter agrees that is preferable to starting from scratch, especially without a designer on the team. However, relying on defaults has a consequence:
- Material-UI products look like generic Google products.
- Changing the primary colour without a designer can clash, or worse, create contrast issues.
Walter’s advice is to start with colours (important for brand identity) and fonts — both are usually straightforward to change via CSS variables or a single theming step.
Icons offer a way to bring personality, though many frameworks come with one icon library baked in, and swapping them requires a lot of replacements. She has seen some frameworks that let you choose an icon library
—Font Awesome or Font Awesome alternatives like Glyphicons.
One infamous example: uppercase text on buttons. Walter asked a developer to remove it, as it was hard to read in their selected font. The developer searched the framework’s API documentation for a config flag, missing the simplest fix—a CSS rule to remove text-transform: uppercase. “If there’s no API for that, I think you can change it in CSS,” she told him.
The Bigger Picture: Your Own Design System
Jumping through hoops yields a
“good enough” solution, but, Walter argues, you are ultimately building your own mini design system on top of the framework. Her team in InVision, or rather in Sketch, document each component’s use cases and states—inputs with focus, placeholders, content and arrows. They document shadows, gradients and exact hex values so developers do not have to guess. The developers also build a “sandbox” tool for components to see how they behave with custom text and icons.
The true value, she argues, lies in documenting auto-completes: at what point does it suggest options? How much typing is needed before suggestions appear? These detailed questions, if left undocumented, are prone to misinterpretation in other projects.
What begins as a generic framework, customised and judiciously used, becomes
“basically building it using React, Material or, Ant.” In the end, the development team ends up with its own system of recognised components and established conventions, but without the cost of building the basics from zero.
Updates, Maintenance and Long-term Viability
For upgrades, Walter’s project is safer than most. They have test environments to deploy new versions and see what breaks. Big changes, even sometimes — in companies that encapsulate components via web components, with two different (major) versions running side-by-side — can coexist without global failure. Still, she admits this may become extremely hard to maintain over the long term.
When pressed, Walter acknowledges that the frameworks evolve relatively slowly — yearly revisions are common, but she thinks her own team’s tool is built for the next five to ten years. At some point, though, B2B and B2C products often get a full redesign every few years anyway — when those design and framework choices are reconsidered at a higher level.
The Practical Takeaway
For anyone working within an existing framework—or choosing one fresh—Walter offers several priorities.
“There’s always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don’t design or build in a silo and try to have other people at least look at what you’ve created,” she says.
Involve the designer throughout, not just at the end for
“paint on top.” Deferring accessibility and semantics until late is similar. A framework does not eliminate the need to make considered choices; it just provides the raw materials to work with, and the best interfaces come from a careful team that uses the tools at hand to serve real user needs.
You can find Stéphanie Walter on Twitter at @WalterStephanie, and on her website, stephaniewalter.design.
She is currently taking an online introduction to psychology class, where she enjoys learning about visual illusions and cognitive psychology — topics she finds particularly relevant to interface design. Among her parting thoughts, she mentions that design decisions, like the ripple effect on buttons, are not without effort to change, but the result is a more polished look. “It’s called” smashing. The full conversation touches on further technical issues, such as a specific problem with Material-UI’s custom drop-downs freezing screens behind them on Internet Explorer
—a case of native select elements being worth considering over custom ones when they cause more issues than they solve.
Feature image via Smashing Podcast.
