There is a particular kind of design debt that nobody talks about in sprint retros. It lives in your Figma file, buried three pages deep. It is inconsistent stroke widths, a random mix of filled and outlined icons, one set from Heroicons, another ripped from Material Design, and a couple of bespoke ones drawn by a contractor in 2022 who has long since moved on. This is the state of icon design in a depressing number of British SaaS and fintech products right now, and it matters far more than most teams acknowledge.
Across the UK’s product landscape, from challenger banks to B2B SaaS tools built in Leeds and Edinburgh, the icon layer is treated as an afterthought. And that is a serious problem, because icons are the nervous system of any interface. They carry meaning at a glance, reduce cognitive load, and signal whether a product feels polished or patched together. When your icon system is incoherent, users feel it even if they cannot name it. The trust erodes quietly.
Why Lazy Icon Choices Are So Common
The root cause is almost always speed. A team picks a free icon library early in the product’s life because something needs to ship. Heroicons is solid. Lucide is solid. Phosphor is genuinely excellent. The problem is not the library itself; the problem is never graduating beyond it. Products grow, brand guidelines get written, a design system gets built, and the icon layer just… never gets revisited.
Then there is the “bespoke one-off” problem. A product manager wants a specific icon for a new feature that does not exist in the library. A designer draws it quickly. Now you have 80 icons from Phosphor at 1.5px stroke and one custom icon at 2px stroke with rounded joins, sitting right next to each other in your nav bar. Nobody notices until a sharp-eyed user or a new senior designer joins and immediately clocks it.
Fintech interfaces in particular suffer from a third issue: regulatory screen clutter. FCA-compliant products often carry a lot of required information and iconography for warnings, risk levels, and disclosures. Teams bolt icons onto these elements ad hoc, sourced from wherever is convenient, which means the most legally sensitive parts of your interface often have the most visually chaotic iconography. That is a branding and a trust problem wrapped in a compliance wrapper.
What a Coherent Icon Design System Actually Looks Like
Building a proper icon design system for UK product design in 2026 is not as complex as some teams fear, but it does require deliberate decisions made up front. Here is the framework I find most useful.
Step 1: Define Your Icon Grammar
Before you draw a single icon, you need a written grammar. This means committing to: a single stroke weight (1.5px or 2px, not both), corner radius (sharp, slightly rounded, or fully rounded), fill style (outlined only, filled only, or a deliberate mixed system with semantic rules), and a grid (typically 24×24 with a 2px inner padding creating a 20×20 optical field). Monochrome or two-tone? That decision needs to happen now, not mid-sprint.
The grammar is your constraint document. Without it, every new icon becomes a judgment call. With it, a new designer can add an icon six months from now and have it look like it belonged from day one.
Step 2: Audit and Cull Your Existing Set
Run a full audit. Export every icon currently in your product, lay them side by side, and apply your new grammar as a filter. Some will pass. Some will need redrawing. Some need removing entirely because the feature they represent was deprecated in 2024 and the icon is still floating around in three screens. Yes, this actually happens.
Tools like Figma’s component analytics (available via the Org and Enterprise plans) can surface how many times a component is used, which makes this audit dramatically faster. If an icon has zero instances, archive it. If it has 400 instances and does not match your grammar, it goes into the redraw queue.
Step 3: Build in Figma With Dark Mode Baked In From the Start
This is where a lot of teams make a costly mistake. They build their icon system for light mode, then try to adapt it for dark mode later using colour overrides. By then, some icons have hard-coded fill colours, some use current colour correctly, and the whole thing becomes a maintenance nightmare.
The correct approach: all icons should use currentColor as their fill or stroke value from the beginning. In Figma, this maps to “Use as mask” or, more precisely, building icons as fully monochromatic components where the colour is inherited from the parent frame or a semantic colour token. If you are using Tokens Studio (which pairs beautifully with Figma), your icon colour tokens can reference your semantic palette, so icon/primary resolves to #1A1A1A in light mode and #F5F5F5 in dark mode automatically. No overrides, no separate dark mode icon set required.
Step 4: Scalability Means Naming Conventions Matter
A naming convention sounds boring. It is actually the difference between a system that scales and one that collapses under its own weight eighteen months later. Use a consistent taxonomy: [category]/[name]/[variant]. So action/download/outline, status/warning/filled, navigation/home/outline. Every icon findable by category. Every variant predictably named.
This also feeds directly into your front-end implementation. If you are exporting to SVG sprites or using a tool like SVGR to generate React components, a consistent naming convention means your component names are predictable too. <IconActionDownload /> is infinitely more maintainable than <DownloadIcon2New />, which is a real component name I have seen in production code.
Step 5: Document Intent, Not Just Appearance
The icon design system for UK product design in 2026 needs to go beyond a grid of icons in a Figma page. Each icon, or at minimum each category, needs usage notes. What is the difference between status/warning and status/error? When do you use the filled variant versus the outline? Are there contexts where icons should never appear without a text label (hint: for accessibility, the answer is almost always yes).
The UK government’s accessibility requirements for public sector websites and apps are instructive here even if you are building a private SaaS product. WCAG 2.1 AA is the benchmark, and icons that carry meaning without a text alternative fail it. Documenting which icons are decorative and which are informational, and what the accessible label should be, is part of the system.
The Brand Alignment Layer
A coherent icon design system should feel like an extension of your brand, not a neutral utility grafted onto it. If your brand uses geometric, modernist typography and sharp angles, your icons should share that character. Soft, rounded icons in a brand that communicates precision and authority create a subconscious mismatch that users pick up on, even if they cannot articulate why something feels slightly off.
This is why picking an off-the-shelf library and calling it done is always a partial solution at best. Libraries like Phosphor or Lucide are excellent starting points and perfectly valid for early-stage products. But a mature product with a defined brand identity, especially one competing in UK fintech where trust signals are everything, should have icons that were either drawn to the brand’s geometric character or significantly adapted from a base library.
The practical route for most teams: start with a base library that is closest to your brand’s visual character, establish your grammar document, and then redraw any icons that deviate or that your product requires specifically. Over time, the bespoke set grows and the dependency on the base library shrinks. That is a healthy progression.
Consistency as a Product Value
Here is the thing that is easy to miss when you are deep in delivery cycles: icon consistency is not a nice-to-have design detail. It is a product quality signal. Users who encounter a polished, coherent icon set are building a subconscious model that this product was made carefully, by people who sweat the details. That trust compounds. It affects retention, it affects willingness to enter payment information, and in regulated sectors like fintech, it affects whether a user completes onboarding or bounces at the first moment of uncertainty.
A proper icon design system for UK product design in 2026 is not about aesthetics for aesthetics’ sake. It is about building a product that communicates competence at every pixel.
Leave a Reply