Product Design Figma Plugin Dev TypeScript UX Research
Overview
Choosing fonts with your own text in view
Choosing a typeface in Figma meant applying fonts one at a time to see how they looked in a design. I designed and built FontContext so people could compare Google Fonts using their selected text, save options, and apply a choice without repeatedly changing the canvas. This was my own project, from observing the problem in workshops to building and publishing the plugin.
The Solution
Preview, compare, and apply a typeface
1. Selection Synchronization
The plugin acts as a listener, not just a viewer. When you select a text layer on your canvas, FontContext instantly pulls that exact raw text string into the interface. This eliminates the "copy paste" tax. Your design context follows you.
2. The Live Preview Engine
I replaced the standard search behavior with a dual-mode engine. Toggling the "Eye" icon, the list transforms from a standard directory into a live creative stage where every font in the library renders your synced text.
3. Standardized Favoriting
Once FontContext is launched, you can scroll through the library and curate your own type foundry. Hover over any font and click the heart icon to save it, instantly adding it to your personal collection. Your saved fonts are accessible via the heart tab, which displays a live count badge showing exactly how many fonts you've curated.
4. Adaptive Workspace Layouts
Designers work in different environments. FontContext includes a responsive layout engine that toggles between Vertical (List) and Horizontal (Grid) views, ensuring longform headlines are never clipped.
The Problem
The Pain Was Always There
3+ years running design workshops, judging hackathons, mentoring at Figma events. Hundreds of first-time Figma users.
Every session, the same scene: someone opens the font dropdown. A thousand names scroll by. They pick one, apply it, squint, undo. Pick another. Undo. 10-30 minutes gone.
After hundreds of these sessions, one frustration came up more than any other:
"I'm trying to envision my brand in this font. But I can't see it. I'm just guessing."
Design students. PMs making decks. Founders building their first landing page. The same struggle.
Waterloo Velocity MVP Hacks
Waterloo Velocity MVP Hacks
Waterloo Velocity MVP Hacks
Research
Validating the Observation
Mapping what designers need versus what the tool provides.
→
The Discovery Gap
I mapped the disparity between what designers were looking for versus what the tool provided.
User Intent (The Goal)Figma Reality (The Tool)
"I need a font that feels 'playful' for this headline."List of 1,000 names sorted A-Z (Abel, Abhaya...)
"I need to compare these 3 options side-by-side."Single-select dropdown (One at a time)
"I want to see if this works in Dark Mode."White background list only
Quantifying the Pain
The data from our sessions was stark. The friction wasn't just annoying; it was costly.
~15min Average Selection Time
Average time spent selecting a single font header
12+ Undo Actions
"Undo" actions per selection (Cmd+Z)
80+ Target SUS Score
Target SUS score required for the solution
These pain points validated our position: Designers need to see the actual content in their fonts, not just font names.
The Need
Recall vs Recognition
The native picker forces recall. You guess what Playfair Display looks like, apply it, then see if you're wrong. What people actually need is recognition: the ability to see their text in a font before committing to it.
I'd watched this struggle hundreds of times. But I wasn't just observing. Every time I picked a font for my own projects, I felt the same friction.
How might we create a type testing experience that is both contextual and performant, without leaving Figma?
The key shift: one field that infers intent, with the eye icon to override it, instead of separate search and preview inputs.
MVP Building
I Built First
I'm a designer, not an engineer. But I didn't wait for one.
↓
The hunch
I had a hunch that live preview was the answer. But a hunch means nothing until you build it and feel it. The problem was, I didn't know if I could even render the fonts. So I opened VS Code that night and started small: a light mode MVP, bare bones, just to answer one question: can I render a user's text live across multiple fonts inside a Figma plugin?
The first working version loaded Google Fonts and rendered the text I typed into the preview input. It was slow and visually rough, but it answered the technical question: live text previews were possible inside the plugin.
Early MVP
A working plugin let me test loading behavior and selection changes alongside the interface.
I built the interface and integration logic myself. I used Claude Code and advice from an engineer friend when I needed help with Google Fonts inside Figma’s iframe sandbox, selection synchronization, and the plugin API.
My implementation connected selection changes, preview modes, and the plugin UI. Learning unfamiliar patterns was part of building it, rather than work I handed off.
Before shipping, an engineer friend reviewed the code with me for edge cases and implementation patterns. That feedback helped me check behavior beyond the examples I had been using during development.
Competitors
What the existing tools left unresolved
Looking around while building.
→
Alongside the MVP, I reviewed existing font-selection tools to understand what they already supported and where a plugin could improve the workflow.
I compared the native picker, other design tools, and an existing Figma plugin:
The Market Gap
Compare the workflow, not just the feature list
My comparison asked two questions: how often would someone need the tool, and how directly did it help them choose a typeface in their current design?
The map was my assessment of the workflow fit, not measured market demand.
Native Figma Dropdown
Reliable but "blind." You pick without seeing your text in the font before committing. High frequency because it's built in, but low value.
Adobe Fonts
Robust web-based previews, but you have to leave Figma, browse externally, then come back. High value preview system, but low frequency because of context switching.
Canva
Lacks a native panel that shows your phrase in dozens of fonts at once. You still click one by one or duplicate text boxes for comparison. Low frequency, low value.
Font Preview (Figma Plugin)
Had preview mode but lacked key Google Fonts, showed constant "Failed" states, and used non-standard star icons for favorites. Dated design, late dark mode. Medium frequency (in Figma), low value because half the features are broken.
COMPETITIVE POSITIONING
Frequency of Use →Value to Users →High Value Low FrequencyHigh Value High FrequencyLow Value Low FrequencyLow Value High Frequency
FontContext
Native Figma
Adobe Fonts
Canva
Font Preview Plugin
I installed it immediately.
Friction in the plugin I tested
I opened it expecting to find the answer already built.
1. I encountered "Failed to load font" errors. Favorites were accessed through a separate floating star control.
2. Search and preview used separate controls that did not stay in sync. I wanted to test whether one input could make the relationship clearer.
3. The control hierarchy made it difficult to tell where to search and where to enter preview text.
4. These observations gave me specific requirements to test: reliable font loading, clear search and preview behavior, and easy access to saved fonts.
That left a practical question:
What would make someone choose FontContext over the workflow they already knew?
The benefit needed to be visible in the first interaction. Previewing someone’s selected text would let them compare fonts before changing the canvas.
I focused the next iteration on that comparison loop: select text, preview typefaces, and apply a choice in Figma.
That's where FontContext needed to sit.
Design Process
The Two Bar Problem
A real UX challenge with three failed attempts.
↓
The core UX challenge: search and preview are different intents, but both involve typing into a field.
Font Preview fragmented this completely. I watched five people use it for the first time. All five clicked the wrong input field first. Three of them said "wait, which one do I type in?" One person tried typing in both fields to see what would happen. Another person just gave up and closed the plugin.
That's not a design opinion. That's a usability failure.
I tried fixing this three ways.
Two labeled inputs
Search on top, preview below. Same affordance, same action.
Users asked which one to type in. Ambiguous affordances. Good UI makes the next action obvious - this didn't.
Two inputs
Search left, preview dropdown right. Still two text inputs side by side.
Same confusion, different layout. Two inputs, same affordance. Still taxing mental load.
One input, eye toggle
One field. Type a font name to search; type a phrase to preview. The system infers intent.
Eye icon overrides when the guess is wrong. One input, two modes, zero extra choices.
Of the three options, the third made the most sense: one field that syncs whether you type a font name or a phrase to preview.
For the icon in the input I debated between a pencil and an eye. Pencil would mean "edit," but I wasn't building an editor; I was building a previewer. Eye means "visibility," "show/hide." That's exactly what preview mode does. It's the same icon Figma uses in the layers panel, the same icon Photoshop uses for layer visibility. Users already know what it means. Pattern matching.
Eye won.
I tested the final version with four people. Nobody asked how it worked. They just typed and it did what they expected.
Universal Users
Who This Is Actually For
Not just designers. Anyone who touches text in Figma.
↓
I initially thought I was building for workshop students, beginners who didn't know font names yet, people early in their design journey.
Then I tested with twelve people across different skill levels.
Junior Designers (4 people)
Didn't know what fonts existed. They needed to browse, discover, see options rendered. Recognition over recall was everything - they couldn't remember what fonts looked like because they'd never used them before.
"I'm trying to envision my brand in this font, but I can't see it. So I'm just guessing."
Mid-level Designers (4 people)
Already had favorites. They wanted to search fast, curate a personal library, build their own type foundry over time.
"I usually know which fonts I want. But I still have to scroll through Figma's list to find them. This feels... less risky. I can just browse."
Engineers (2 people)
Were updating UI copy. Didn't care about typography theory. Just needed to pick something decent and ship.
"I don't care about typography. I just need something that doesn't look terrible so I can move on."
PMs & Founders (2 people)
Surprised me most. Just needed a font that doesn't look terrible in thirty minutes. No desire to become typography experts.
"I have thirty minutes. I just need a font that doesn't look terrible. I don't want to become a typography expert."
That reframed everything.
Different experience levels, one comparison task
Beginners needed help discovering fonts. Experienced designers wanted to explore beyond their usual choices, while engineers and founders wanted a quick way to find a suitable option.
That range of needs supported a shared preview workflow, with search and favorites available for people who already knew what they wanted.
Keep the scope on choosing a font
Testing with people in different roles clarified the shared task: compare typefaces using their own text, then apply a choice. I had started adding weight, spacing, and style controls, but Figma already handles those after a font is selected. I kept FontContext focused on discovery and preview.
That also meant cutting a partly built code-export feature. A Google Fonts URL and CSS snippet could help developers, but they did not improve the core selection task. This boundary kept the interface focused on the font list, preview, and favorites.
Interaction Details
Making browsing feel predictable
With the input resolved and the scope narrowed, I refined the actions around the font list. The list remained the main content, with search and preview above it, favorites at the right edge, and preferences kept secondary.
Separate previewing from saving
With hearts on the left, people sometimes selected a font when they meant to save it. I moved the hearts to the right edge so saving and previewing had distinct targets. I also made the favorites count update immediately; the delayed count had led people to click again because they weren't sure the first click registered.
Keep the font name available in preview mode
Replacing font names with the selected text made comparison easier, but hid the name of each typeface. I added a name annotation above the hovered row, where it would not cover the next option. After trying 100ms and 200ms delays, I settled on 120ms to balance quick access with accidental triggers while scrolling.
Support the text and workspace people already use
A long wedding-invitation headline exposed the limits of the compact list. I added a wider card layout for reading longer samples while keeping the list available for browsing more fonts at once. Theme detection followed Figma's light or dark setting so the plugin fit the surrounding workspace.
Make the preview keep up with scrolling
Those interactions depended on fonts loading reliably. Loading the full library upfront used too much memory. Loading each font only as it appeared reduced that cost, but rapid scrolling created bursts of requests and rate limits.
I switched to virtual scrolling, rendering only the visible rows and a small buffer. Fonts load from the CDN before entering the viewport and are cached in the browser. This let me keep the live preview without loading the entire library at launch.
The Outcome
A shipped plugin used beyond the test sessions
Available on Figma Community.
I published FontContext on Figma Community. One useful sign after launch was seeing someone return to it for their own work.
Sarah, a medtech startup founder new to design, had helped me compare iterations. A few weeks after launch, I saw her using FontContext for her startup’s brandbook: browsing serifs, saving options, and building a personal library. When I asked about picking fonts, she said, "You just preview and pick." That was an example of continued use outside a test session, rather than a measure of adoption across all users.
Version one ships lean, but that means trade offs.
→
Category Filters
Adding serif/sans/display filters created more decisions. Speed mattered more than organization.
Variable Fonts
Supporting variable fonts meant rewriting how fonts load. Saved for a future version.
Popular Sorting
Trending data changes daily and breaks caching. Needs a more stable data source.
Code Export
Letting developers copy font CDN links. Useful, but not core to font discovery.
Typography Editor
Controls for weight, style, and spacing. This is a font picker, not a typography tool.
AI Recommendations
Suggesting fonts based on project context. Interesting, but adds complexity to v1.
Learnings
What I Took Away
Watch what happens after the test
Seeing Sarah return to FontContext for a brandbook told me something the guided sessions could not: the plugin had a place in her own workflow. I would look for that repeated use when evaluating the next version, alongside whether people can preview and apply fonts without help.
Building exposed constraints the mockup missed
I used Claude to learn unfamiliar implementation patterns, including virtual scrolling and font loading. Building the plugin exposed memory and request limits that were invisible in Figma. I still had to decide what to load, check the behavior, and refine the interaction by using it with people.
Give the plugin one clear job
Weight and spacing controls would have duplicated work Figma already supports. Keeping the plugin focused on comparing and choosing typefaces helped me decide which features to finish and which to leave out, including a partly built code-export feature.
