Designing in the Browser

A realistic approach to realistic application design

Jory Tindall

Lead Designer, Closet Engineer, Helios Design System

About me

Lead Product Designer on the Helios Design System
"Part time engineer"
Based in Seattle, WA
Saxophonist and musician
Run a lot of miles (most often while listening to Limp Bizkit)

Many of you already know me from Slack, or the various memes that I circulate through our channels. But if this is your first time seeing me, let me introduce myself.

I'm a lead product designer on the Helios Design System, HashiCorp's enterprise design system (currently in the process of smoothing the transition over to IBM's Carbon design system).
I say "part time" engineer because while my technical job title is Product Designer, many of the projects I work on bridge the gap between design and engineering. You might also call this role a "design technologist" or "design engineer."
I'm based in the Seattle, Washington, in the USA.
I'm also a saxophonist and musician in the local music scene here in the Pacific Northwest.
And lastly, I run a lot of miles — usually while listening to Limp Bizkit. Don't judge me.

An interesting note about this presentation is that is was designed and written entirely in the browser and runs as a Svelte application. It's a pretty cool Svelte app built with Reveal.js to handle the slide deck functionality, but that's a conversation for a different presentation!

What does "product designer" even mean anymore?

To kick us off I'll pose a question: "what does the term 'product designer' even mean anymore?" Our industry is going through a significant shift right now, different values are being placed on designers and engineers.

The tools are changing, AI is injected everywhere in our process whether we like it or not.
The processes we use to design and build software are evolving in parallel with these tools.
The boundaries between design and engineering are blurring.
More broadly, the tech industry is consolidating. I'm not sure if you've heard of the recent large acquisitions of a company called IBM. This consolidation impacts the logistics around our roles, where we fit in the corporate hierarchy, and the value propositions we're required to deliver on.

I've mentioned AI a couple times already, and I think it's important to note that while AI is a significant driver of change in our industry right now, it's not the sole focus of this talk.

Instead, I want to focus on how we as designers can navigate this volatility by adopting a more "realistic" process to designing a UI, crafting an experience that brings us closer to our users, and reduces our dependence on tools and trends that may not serve us well in the long run.

What we'll cover

The infinite canvas problem

Figma's infinite canvas doesn't present a realistic experience. Your users don't have infinite space. They have viewports, scroll behavior, and real device constraints.
Designing in a vacuum of the infinite canvas creates a gap between your design and the reality of how it's experienced.
Perspective really matters! The way you view Figma mockups on this canvas creates a perspective disconnect that can skew your design desicions.
Elements might appear larger/smaller, spacing might feel different, hierarchy might be unclear, etc.
Not to mention anything related to responsive design!

Let's talk about "the infinite canvas problem" in Figma.

No realistic experience. Users have viewports, scroll behavior, and device constraints—not infinite space.
Designing in a vacuum. Static mockups look great in Figma but often feel off when implemented. You lose the sense of flow and real interaction that you would get in the browser.
Perspective disconnect. Zooming in/out skews your judgment on visual weight, hierarchy, and proportions.
Your perception of scale shifts. Spacing and typography that look perfect zoomed out may feel wrong at actual size.
Responsive design is hard to validate. Multiple artboards don't effectively capture the fluid nature of the web.

Let me be clear, I don't hate Figma, but I think as designers we should be trying to eliminate as many blockers as we can to experience what our users are experiencing. Figma is only a tool, and like any tool, it has its limitations.

What you gain

Realistic experience — you see more or less exactly what users will experience.
Faster iteration — working with many frames in Figma can sometimes be slow and clunky; in the browser, you can iterate quickly on small design and experience elements.
Avoid accessibility pitfalls — catch issues early with real DOM structure, focus management, and screen reader testing
Content design and reflow — content reflows within the viewport, giving you a better sense of copy length and complexity
Grounded interaction design — real hover states, real transitions, real feedback
Reduced time-to-value — by eliminating the mockup-to-code translation step, features reach users faster with fewer rounds of revision

So what benefits do you actually gain when you design in the browser?

When you design in the browser, you're working with reality; you see exactly what users will experience
Faster iteration - working with many frames in Figma can sometimes be slow and clunky; in the browser, you can iterate quickly on small design and experience elements.
You can avoid accessibility pitfalls early — working in the real DOM means you can test focus management, screen reader behavior, and keyboard navigation as you design rather than discovering issues after implementation.
Content design and reflow — content will reflow within the viewport, giving you a better idea of the exact length and perceived complexity of micro copy and long-form content.
(and this is the most important) Your design is grounded in what's actually possible — real hover states, real transitions, real system feedback having this level of grounded/realistic design from the beginning makes a huge difference when handing off and capturing the unique aspects of a design to an engineer.
When you're working directly in the medium that ships, you're cutting out a translation step. This means faster iteration cycles, fewer misunderstandings between design and engineering, and ultimately features reaching users sooner.

Design grounded in reality

The browser doesn't let you cheat! It forces you to answer questions that Figma lets you defer.

How does this actually scroll?
What happens when content overflows?
How does this feel on different screen sizes?
Is this interaction actually usable?
Is there logical keyboard navigation?
Does this work with a screen reader and other assistive technologies?
Is my design intent actually clear and achievable?

Let's get started

There are multiple ways to design in the browser, each with its own strengths.

Prerequisites

Basic HTML/CSS understanding — you don't need to be an expert, but knowing the fundamentals helps
Familiarity with browser DevTools — the inspect panel is your best friend
Curiosity and willingness to experiment — you'll learn by doing, and that means breaking things sometimes

Before diving in, here are some prerequisites that can be helpful to have:

A basic understanding of HTML and CSS — you don't need to be a frontend engineer, but knowing how elements are structured and styled makes everything easier. If you don't have any experience here, we're lucky to have some great corporate resources through IBM and O'Reilly that can help you get up to speed.
Some familiarity with browser DevTools — the inspect panel is an excellent tool, so getting comfortable with it is essential.
A willingness to experiment — you're going to break things, and that's okay. That's how you learn what works and what doesn't.

Fun fact about me: I have a degree in the jazz saxophone, which in no way equates to a design/front-end development skillset. But I'm a curious person and brought these skills into my arsenal through much trial and error, breaking things, and creating really terrible websites.

Different levels of entry

Browser inspect tools Great for quick tweaks, refining details on the fly, or iterating with an engineer in real-time. This is the easiest entry point with minimal setup required.

CodePen or demo apps Ideal for exploration, iterating on small patterns, or testing ideas in isolation. Requires basic HTML/CSS knowledge but no local development environment.

Running the app locally Best for mapping out UX, testing large layouts, pushing boundaries, or updating legacy designs. This gives you the full picture with real components and patterns.

There are different levels at which you can start designing in the browser, each serving a different purpose and being suited for different parts of the design process and development lifecycle:

Browser inspect tools: Perfect for quick adjustments and refinements or identifying exactly what type of design language is used in a specific element (the CSS styles applied to an element). This is especially useful when you're working with an engineer on a call — you can tweak values live and see changes immediately.
CodePen or demo apps: Great for exploration and experimentation. When you want to iterate on a small pattern or component without the overhead of a full application. Working in this way can also be great for testing interaction design very quickly, for example, hover, active, and focus states.
Running the app that your working on locally: This is where you get the full picture. You can map out complete UX flows, test responsive layouts at scale, explore what's actually possible with real design system components or application-specific patterns. This level is also ideal for updating and modernizing existing designs through an iterative process.

The skill gap is real...

New skills for designers.
Understanding web development basics is a real time investment.
Web development tooling and frameworks move quickly.

...but it's attainable

The basics of web development aren't outrageously challenging.
You don't need to become a senior engineer.
Start small, build gradually, and use AI as your pair programmer and educator.

Let's be honest about some of the challenges of designing within the browser. The skill gap is real.

These are new skills that aren't part of a typical designer's job description
Learning how the browser works, understanding web dev basics, efficient workflows — it's a real investment.
The web development space moves so quickly that if you're focused on design most of the time, it can be hard to keep up

That said, I don't want to leave you with the impression that these challenges are insurmountable.

The basics of web development aren't outrageously challenging. A rudimentary understanding HTML and CSS can be picked up relatively quickly and can be really helpful at understanding the implementation phase of your design.
You don't need to become a senior engineer. Many of the basics of building a UI are attainable with some effort and practice.
Start small, build gradually, and use AI as your pair programmer and educator. Tools like Claude or Cursor aren't just code generators — they can explain why code works, suggest alternatives, and teach you patterns as you go. The key is to engage with what they generate, ask follow-up questions, and build real understanding over time.

Where Figma still wins

Rapid iteration on many design variations
Visual comparison of different versions
Component exploration and refinement
Stakeholder presentations and alignment

The landscape is changing

Learning Figma is necessary for the job right now.
Design systems and component libraries are a massive strong suit of Figma.

Where Figma fits best

Early exploration and ideation
Stakeholder presentations and alignment
Design documentation and handoff artifacts

Let's be clear; Figma isn't going away, but the landscape is changing.

Learning it was and is necessary for our jobs
Managing design systems and component libraries are still a massive strong suit of Figma

In a hybrid workflow, Figma excels at specific stages of the design process:

Early exploration and ideation — when you need to quickly sketch out ideas and explore different directions without worrying about implementation details. Or even storyboarding or crazy eights.
Stakeholder presentations and alignment — Figma's presentation features and easy sharing make it ideal for getting buy-in and feedback from non-technical stakeholders, especially early on in the process.
Design documentation and handoff artifacts — creating specs, component documentation, and design system guidelines that need to be referenced by multiple teams.

More importantly, you want to consider who is going to be using these artifacts. If somebody else is going to be using them, probably beneficial to use Figma for these stages.

Where do AI design tools fit?

Figma Make is an interesting attempt to integrate AI into the design process. However...

The middle step isn't eliminated...yet.
Why add AI to the middle step when you could skip it entirely?
Sometimes the mockup becomes a bottleneck, not a benefit — slowing down time-to-value for your product.

Figma sees where the software development industry is going and is trying to be the end-to-end design to code solution. Figma Make is an interesting attempt to integrate AI directly into the design process however...

They don't eliminate the middle step...yet.
But here's the thing: why add AI to the middle step when you could eliminate the middle step entirely?
Sometimes Figma becomes a bottleneck rather than a benefit. When you receive feedback on spacing, want to explore an interaction, or need to test with real data, updating a mockup adds friction rather than value. Every hour spent updating mockups is an hour not spent shipping. When you can iterate directly in the browser with AI assistance, you're reducing the time between design decision and user value.

Obviously some of these points are opinionated and meant to be provocative, but I encourage you to really think about them in a way that encourages discussion and critical thinking about how your design process could evolve over the next 5 years.

Let's look at some specific scenarios where skipping Figma can speed up your workflow.

Scenario: Hover animation

You want to add some whimsy to a card's hover interaction. Instead of wrestling with Figma's animation and prototyping tools, pair with an AI tool to prototype it directly in your demo app.

.card {
  transition: transform 200ms ease-out,
              box-shadow 200ms ease-out;
}

.card:hover {
  transform: translateY(-4px);
  box-shadow: 0 12px 24px rgba(0, 0, 0, 0.15);
}

Scenario: Spacing feedback

Your PM gives feedback on the spacing between elements. Instead of updating the mockup, use the browser's inspect tool to explore options and pass specs directly to your engineer.

.card-grid {
  gap: 24px; /* Try 16px, 24px, or 32px */
}

.card-content {
  padding: 16px 20px;
}

Scenario: Form field width

The form's max-width isn't accounting for realistic input values. Instead of guessing in Figma, test with real data in your local environment.

.form-container {
  max-width: 480px; /* Accommodates long email addresses */
}

.input-field {
  width: 100%;
  min-width: 0; /* Prevents flex overflow */
}

The hybrid workflow

Where the browser fits in the workflow

Rapid iteration on interaction design
Testing with real data and real constraints
Final refinement and VQA before shipping

Let me show you with a live demo!

"Can I ship production-ready work?"

Probably not today. But the barriers are eroding.

What's in reach vs. what's not

In reach: UI design, presentational JavaScript, cleaning up legacy experiences
Further out: Complex APIs, databases, complex functional JavaScript
Know what's achievable and focus there

Can designers ship production-ready code today?

Let's be realistic — in most scenarios, designers won't ship production code yet! Fortunately that isn't true in all scenarios, and as I've mentioned, the landscape is changing!
There are organizational blockers, processes, ownership issues
But these barriers are starting to erode for technically minded designers. My own experience is an example of this, where code that I've written is being used in applications of a (now) Fortune 100 company.

What's realistically in reach for designers today? There's a spectrum here.

In reach: UI development/engineering work, presentational JavaScript, cleaning up legacy experiences
Further out: Complex APIs, database work, heavy functional JavaScript
Know what's achievable and within your bounds, focus there

"What does 'product designer' even mean now?"

Someone who solves problems through design thinking and deep understanding of the problem space.

Technical knowledge + AI as pair programmer + creative thinking = a new kind of designer.

Organizations that embrace this flexibility will move faster. Those that don't will fall behind.

"Did I waste years learning Figma?"

No. But the landscape is shifting.
Figma skills got you here. Browser skills will take you further.
There are a lot of transferable skills
Designers who can work in both worlds will have an advantage

Start today

Open DevTools and inspect an element — understand how it's built
Clone your team's repo and get the application running locally
Find one small UI change and try to make it yourself
Use an AI tool as your pair programmer — to learn, not just generate

Here's my call-to-action for you. Don't leave here without a plan:

First, start with browser DevTools — right-click any element and inspect it. This is the lowest barrier to entry and you can do it right now.
Second, get the application running locally — ask an engineer to help you with the setup. This is where the real magic happens.
Third, find one small UI change — a color, some spacing, a label — and try to make it yourself. Start small and build confidence.
Fourth, use an AI tool like Claude or Cursor as your pair programmer. These tools are incredible for learning — ask them to explain what you're looking at, why something works the way it does, or what alternatives exist. Treat it as a patient teacher who's always available, not just a code generator.

Remember the levels of entry we discussed: browser inspect tools, CodePen/demo apps, and running locally. Pick the level that feels right for you and start there.

Resources

Your friendly neighborhood engineer
AI tools as your pair programmer and patient educator
MDN Web Docs for fundamentals
Your own curiosity

Key takeaways

The browser grounds your design in reality
Figma and browser work best together in a hybrid workflow
The skill gap is real, but attainable
Start small and build gradually
AI tools + browser workflow = faster time-to-value

To recap the key takeaways from this presentation:

The browser grounds your design in reality — you're working with the actual medium, not a simulation of it. This leads to better designs and fewer surprises during implementation.
Figma and browser work best together — use Figma for early exploration, stakeholder alignment, and documentation. Use the browser for iteration, interaction design, testing, and final refinement.
The skill gap is real, but attainable — you don't need to become a senior engineer. The basics of HTML and CSS are within reach, and AI tools can help fill the gaps.
Start small and build gradually — pick the level of entry that works for you, whether that's browser DevTools, CodePen, or running locally. Every step forward is progress.
The combination of AI-assisted development and browser-based design dramatically reduces the time from idea to shipped feature. This is increasingly what organizations will expect from modern product designers.

Questions?

Open it up for Q&A. Be prepared for questions like:

Tools and workflows: "What specific tools do you use?" — Browser DevTools, VS Code/Cursor, local dev environment, AI assistants like Claude.
Pushback on premise: "Isn't this just for design engineers?" — No, this is about expanding your skillset and getting closer to the final product. The level of depth is up to you.
Time investment: "How long does it take to learn?" — Start with DevTools today, basic HTML/CSS in a few weeks, local development in a few months. It's a gradual process.
Team dynamics: "How do engineers feel about this?" — In my experience, engineers appreciate designers who understand the medium and can speak their language.

Thank everyone for their time and remind them of the key takeaway: start small, stay curious, and embrace the hybrid workflow.