Last week we had our OneSignal company offsite in San Diego, where I hosted a workshop with our design team focused on how our process is evolving as we head into 2026.

The goal wasn’t to define a new, rigid framework. It was to reflect honestly on how design is actually getting done today, and what needs to change as AI reshapes the pace and shape of our work.

As part of the session, we watched Why Designers Can No Longer Trust the Design Process by Jenny Wen at Anthropic. The talk challenged the idea that design happens in a clean, linear sequence of steps, and argued that designers often confuse process artifacts with real progress.

That framing resonated. AI has accelerated prototyping to the point where following a step by step process by default can slow learning rather than support it. The work now requires more judgment, not more ceremony.

A recurring theme in our discussion was agency. Designers have more leverage than ever to explore ideas, test assumptions, and shape direction early. I wrote about this previously in Empowering Design Agency: How AI Is Revolutionizing Early-Stage Prototyping, and that same idea came up again in this workshop. With faster tools comes greater responsibility. Designers are making more decisions earlier, and those decisions matter.

In practice, this often means skipping or compressing parts of the traditional process. Sometimes going straight to high fidelity or building a vibe coded prototype is the fastest way to learn. Lo-fi wireframes are still useful, but they’re no longer required for every problem.

At the same time, this is not an argument for abandoning process entirely. Speed without clarity leads to thrash. As designers take on more agency, decision quality becomes even more important. We still need guardrails, clear ownership, and shared expectations around when ideas are exploratory versus when they’re becoming real commitments.

We also talked about craft and quality. In a world where AI can generate decent UI instantly, “good enough” is no longer a differentiator. Taste, clarity, and coherence matter more than ever. Human judgment is what turns output into a product people trust.

Tooling came up as well. We’ve been experimenting with v0, FigmaMake, Replit, Lovable, Claude Code, and Cursor. They’re all improving quickly, and part of the challenge is knowing when to explore new tools and when to focus. Not everything that can be automated should be.

Cross functional collaboration was another important thread. Faster design should not reduce collaboration. It changes how it happens. A vibe coded prototype might never ship to production, but it can be a powerful way to get early feedback, align teams, and validate assumptions with users. Part of our responsibility is teaching others how and when they can contribute, even as the artifacts look different than they did before.

The takeaway for me is that while we may no longer be able to blindly trust the traditional design process, some structure still matters. The process needs to support learning, decision making, and quality, not exist for its own sake.

Overall, I’m excited about what 2026 brings. Design has more leverage now, which makes judgment and quality matter more.

p.s. we’re hiring at OneSignal

Using your own product might be the single most powerful habit a product team can build.

Sounds obvious, but how often is everyone on your team actually using your product?

At OneSignal, we’ve been leaning hard into dogfooding — using our own product exactly as our customers do, with their goals in mind.

It’s not just about testing for bugs. It’s about feeling what our users feel, understanding their goals, and experiencing the product as they do.

Why We Dogfood

When we dogfood, we:

• ✨ Build empathy by walking through real customer goals and workflows
• 💪 Strengthen confidence in our product’s quality and reliability
• 🔍 Spot the small UX or performance issues that only show up in real use
• 🧩 Deepen understanding of how all the pieces fit together
• 🛠️ Create a culture of continuous improvement — if you see something broken, you fix it

This simple habit helps us build trust in our product and stay close to the details that matter.

How It Started

We started running dogfooding sessions during our company onsites, and they quickly became one of the most valuable sessions of the week.

They’re equal parts testing and reflection. We walk through real user journeys, capture friction points, and discuss how to make them better.

Now, our EPD teams run regular friction logging sessions throughout the quarter using FigJam to capture screenshots and notes, which are triaged into Asana for prioritization.

It’s lightweight, visual, and fast, and it’s surfaced dozens of improvements that have made the experience smoother for everyone.

How It’s Growing

Dogfooding has expanded beyond product and engineering. It’s now a shared ritual across EPD and other cross-functional teams including Support, Marketing, and Solutions Engineering.

Marketing uses OneSignal for our own campaigns and promotions. Product & Engineering uses OneSignal for many of our own transactional emails.

I use it personally to send my newsletter. Some teammates use OneSignal for their own apps and side projects.

It’s helped everyone understand the product from different angles and built empathy across disciplines.

Building a Culture of Continuous Improvement

The biggest outcome isn’t the bug fixes — it’s the mindset. Dogfooding reinforces a culture where everyone feels ownership of the product experience.

It reminds us that great products are built when the people behind them truly understand what it’s like to be a customer.

Quality becomes a shared responsibility. Improvement becomes part of the routine.

Because if you don’t love using your own product, how can you expect your customers to?

We’re hiring across Product & Engineering, come join us! onesignal.com/careers

Every two weeks at OneSignal, we run one of my favorite rituals: the UI Power Hour.

A designer and engineer team up, set a one-hour timer, and hammer through small but meaningful UX or UI updates, the kinds of things that often don’t make it into a sprint or roadmap.

Why We Do It

In isolation, these changes may feel trivial; fixing misaligned components, rewriting a confusing label, cleaning up spacing. But stack them up, and the difference is huge.

You can tell immediately when a product team invests in polish: every click feels smoother, every interaction feels intentional. Those small UX “papercuts” add up, and clearing them out makes for a noticeably better product.

How It Works

• Every two weeks: A designer + engineer pair for one focused hour.
• Scope: Sometimes one larger item, sometimes three or four smaller ones.
• Backlog: We keep a list (in Asana) of potential tasks, groomed during design syncs.
• Prep: Any design decisions happen beforehand — Power Hour is for execution, not debate.
• Team size: Two people max. Keeps it lean and avoids overthinking.

This started when we were a small team. Every other Wednesday, myself and one engineer would hop on a call at the start of the day and fix one thing.

Since then, it’s scaled. More designers and engineers now run their own sessions, and the “Power Hour” concept has spread across our org.

The Benefits

• Reduces UX debt before it snowballs.
• Protects the design system — one misused component caught early prevents it from spreading everywhere.
• Builds empathy between design and engineering. Designers see the coding tradeoffs; engineers feel the design intent.
• Immediate gratification — we ship and see results live that same day.

The Shift With AI

Lately, we’ve noticed something new. With tools like Cursor and Claude Code, even designers who don’t typically write code can contribute directly to the codebase.

That means copy edits, design system tweaks, spacing adjustments — all the “small but meaningful” fixes — can often be handled by designers themselves.

It doesn’t replace the value of pairing with engineers, but it supercharges the Power Hour and lowers the barrier for making polish part of the workflow.

Why I Love It

It’s hands-down one of my favorite meetings. There’s something deeply satisfying about starting your day, pairing up, and shipping something that makes the product better right away.

As our design leader, I see Power Hour as more than just fixing UI polish. It’s a signal to the team that details matter. That investing in small improvements can have as much impact on customer happiness as a big new feature launch.

👉 Does your team do anything similar? How do you address UX debt & polish?

My team has been diving deep into the AI playground lately. We’re seeing a real shift in our initial design approach — jumping straight into ideation and rapid AI prototyping before Figma, or even pen & paper. It feels like a significant leap forward in how we, as designers, can truly explore the boundaries and take more agency right from the start.

It reminds me of when I was first introduced to Ruby on Rails scaffolding (circa 2007), famously demonstrated by DHH’s “how to build a blog in 15 minutes”. Instantly building a basic CRUD app, actually clicking through real forms that saved to a DB, and getting fast feedback from clients and users.

That rapid iteration was just gold. It fundamentally changed how I viewed early-stage exploration and hammered home the importance of seeing and feeling a concept quickly. That sparked a real curiosity about what could be built fast.

That early RoR experience taught me to explore what’s possible first. Design could then be informed by tangible functionality. Now, these AI “vibe coding” tools are putting that rapid exploration power directly into the hands of more designers, regardless of their coding chops, giving them even greater agency in the creative process.

Tools like Cursor, Replit, v0, Lovable, Polymet, Bolt and more — are democratizing code-based prototyping on a whole new level. This accessibility is fueling a designer’s natural curiosity to play with interactive elements much earlier in the game.

Listening to Ridd’s recent interviews with various design leaders, he draws a similar parallel to the 2013/2014 wave of advanced prototyping tools including Origami and Framer. These tools were game-changers for mobile prototyping, and Ridd highlights a similar window of opportunity with AI now.

“There’s a window open right now for designers who want to roll up their sleeves and figure out how AI can be a catalyst for their career”

What’s truly exciting now with these AI tools is that it’s opening doors for more designers to actually prototype in code, rapidly see what’s achievable, get it in front of customers faster, and then refine the experience in Figma with a much deeper understanding of its potential. This hands-on exploration breeds a stronger sense of ownership and agency.

Imagine being able to quickly test a OneSignal push notification flow and see its real-world impact. Or rapidly mock up a Stripe checkout page to truly grasp the user journey. Or picture being able to connect a form to Supabase and understand how to save and lookup data. Or explore the live capabilities of UI libraries like Tailwind, or visualizing data with Chart.js, or a workflow UI with ReactFlow — AI tools are enabling this direct engagement and really feeding a designer’s curiosity about how things actually work.

This new era of AI-powered design prototyping isn’t just about spitting out visuals; it’s about rapidly validating concepts with real functionality, user flows, and even API integrations. It’s a genuine game-changer for making truly informed design decisions and empowers us, as designers, to have more agency in shaping the product’s core functionality.

Ultimately, this AI-driven prototyping is empowering designers to be more strategic, more informed, and more collaborative much earlier in the product lifecycle. It’s about bringing tangible experiences to the table faster, driven by our inherent agency to explore and our fundamental curiosity to innovate and create better products.

p.s. we’re hiring Product Engineers at OneSignal

Yet most tech companies overlook the importance of having people that excel at “front-of-the-front-end” work.

I come from a web development background, & always struggled with my title. Back in the day I would switch between calling myself a Web Developer and Web Designer. I would design (in Photoshop) and then code (in FrontPage) then “deploy” via FTP 🕺

As tech has evolved, so have roles and org structures. Designers code less. But also software engineers rarely write their own HTML & CSS. At most companies you have design on one side, software engineering on the other. In this world, what ultimately happens is designs get “handed off” to engineers (typically “full-stack” engineers), and the final product ends up looking and feeling quite different from what was originally intended.

That’s where Design Engineers come in — and why they’re so valuable.

What is a Design Engineer?

Brad Frost describes the great divide:

a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.

InVision (RIP) have this Design Engineering handbook, with a great quote from Natalya Shelburne:

Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimise product development and innovation.

Design Engineers typically care about accessibility (a11y), pixels, grid systems, semantic markup, design tokens. They work hands-on with design systems, tools like Storybook and React, as well as CSS, SCSS, Figma, and Chromatic to rapidly prototype and enhance UX. They also optimize developer workflows, ensuring designers and engineers collaborate effectively.

They’re also extremely good at managing, or preventing, design debt. Either getting ahead of it (with a well documented design system), or cleaning up issues that other engineers can’t prioritize, they ensure that both design and code are scalable and sustainable.

Are you a Design Engineer?

If you’ve ever found yourself asking, “Am I a Product Designer or a Software Engineer?” — you might just be a Design Engineer. Many people in this role don’t fit neatly into conventional job titles or organizational structures.

Does this sound like you? If yes, we’re growing the team at OneSignal and hiring.

Yet most companies are really bad at following through with the details.

Companies doing it well

I’m impressed with companies like Linear, Lattice, Railway, Attio, Folk, Pitch

You can tell they care a lot about design & ensure the polish makes it out of their design artifacts & into the hands of the user.

I found this post by @radilson inspiring:

In digital product design, ‘craft’ refers to technical skill, strategic creativity, care, attention to detail, and commitment to producing a high-quality product for users

Reasons craft gets left behind

1/ Move fast & break things, speed & experimentation

2/ Team scale, as teams grow more energy needed to be consistent & maintain quality

3/ Conflicting visions, needs leadership sponsorship for design craft to be fundamental

4/ Undervaluation of visual design, sites like Dribbble make it seem design is all about making things pretty

The examples I mentioned, you can tell there was a decision at the top that it was essential to care about the details so users feel those emotions when experiencing the product.

This approach to product development is an excellent example of caring about craft at every level

Pushing for craft and details on our design team

At OneSignal we recently shipped an update to our navigation. The icons subtly animate on hover.

This was a design team initiative that visual design and design engineering executed on.

This update won’t directly map to dollars, but it shows that we care deeply about design.

We believe that this, along with the many other tiny details that we bake into the experience, will show our users that we care, and they experience delight when using the product.

p.s. we’re hiring

Who else does this well?

Who else is doing it well? What companies and products manage to stay true to their craft and ship the details?

Share more examples for inspiration.

I recently developed my first Figma plugin.

It wasn’t hard, and my whole team joined in, exposing us to what is possible with the Figma API.

Here’s a quick tutorial…

Background

First off, at OneSignal the design team do occasional weekly “themed” weeks, where we set an objective outside the typical weekly workload.

Learn something new, code something, read a book etc.

This week the goal was to create a Figma plugin.

This was a great way to get non-coders involved in development.

Most of the team don’t code. None of us, including myself, had tried to created a Figma plugin before.

Everyone was starting from scratch & learned something new.

Kudos Brian Gaus for his really simple tutorial which we followed to help get us started.

This plugin simply sets the colors of different shapes based on how they are named.

Once we had a simple plugin that turned shapes different colors, we moved on to more adventurous things.

Step 1: Create a new plugin

Create a new Figma Design file

Right click > Plugins > Development > New plugin…

Name your plugin and select Figma design

Select Custom UI

Select a location on your computer to save it

Plugin created — open the folder to see what files exist

We’re not going to use Typescript for this so delete those 2 files

code.js — this is where your plugin code lives

manifest.json — describes your plugin, Figma uses this to get the name of your plugin etc.

package.json — where your dependencies live, not required for this tutorial

README.md — describes your project for other developers, not required for this tutorial

ui.html — the UI for your plugin that can interact with code.js

Step 2: Code your plugin UI

Now to get your hands dirty with code. You’ll want to use a code editor for this (I use Visual Studio Code).

Open code.js and replace it with this:

//Tells Figma to display your custom UI
figma.showUI(__html__);

//Resizes your plugin UI in pixels
figma.ui.resize(400, 400)

/*
This is our custom function
When a user submits an input from our plugin UI,
this will take care of it
*/
function activateWhenUserClicksSubmit(msg){

    //extracts the message's vairables
    const {keyword, hex} = msg;

    //tests for keyword
    function testForKeyWord(node){
        //a regular expression that tests if the keyword is in the title
        const isKeyword = new RegExp(keyword, 'gi');
        if(node.name){
            return isKeyword.test(node.name);
        }
        return false;
    }
  
    //Gets the node for the current Figma Page
    const currentPage = figma.currentPage;
    const nodes = currentPage.findAll(testForKeyWord)

    //fills all our code with the selected color
    for(const node of nodes){
        node.fills = [{type:"SOLID", color: colorConverter(hex)}]
    }
}

/*
This is an event listener
Whenever the UI makes a call
to our main code
*/
figma.ui.onmessage = activateWhenUserClicksSubmit;


function colorConverter(hexColor){

    //a regular expression. It will test if the hex is proper
    const isHex = /[0-9abcdef]/i;

    //Throws an error if the hex is improper
    if(hexColor.length !== 6 && isHex.test(hexColor)){
        throw Error('hex colors must have 6 characters');
    }

    //converts hex code into RGB coloring
    const r = parseInt(hexColor.slice(0,2), 16)/255;
    const g = parseInt(hexColor.slice(2,4), 16)/255;
    const b = parseInt(hexColor.slice(4,6), 16)/255;

    return {r,g,b};
}

Open ui.html and replace it with this:

<!--Header-->
<h1> Change Widgets Color </h1>

<!-- Short app explanation -->
<p>
  Will change the color of all objects with the key word in their title
</p>

<!--Asks user for a hex color value-->
<label for = 'hex-input'>
  New Hex Color
  <input
    required
    id = "hex-input"
    type = "text"
    max = "6"
    min = "6"
    placeholder = "fafa1d"
  />
</label>

<!--Asks user for a key word-->
<label for = 'keyword-input'>
  Key Word
  <input
    required
    id = "keyword-input"
    type = "text"
    placeholder = "title"
  />
</label>

<!--Submit button-->
<button id = "button">
  Change Color
</button>

<style>
  body{
    font-family: sans-serif;
  }
  p{
    color: #777777;
  }
  label{
    margin-top: 20px;
    display: flex;
    flex-direction: column;
    margin-bottom:10px;
    width: 75%;
    font-weight: 600;
  }

  input{
    font-size: 14px;
    margin-top: 3px;
    border-style: none;
    border-bottom-style: solid;
    outline: none;
    font-weight: 600;
  }
  button{
    margin-top: 20px;
    padding: 10px;
    font-weight: 700;
  }
</style>

<script>
  //Creates variables that allow us to access the HTML components
  const hexInput = document.getElementById('hex-input');
  const keywordInput = document.getElementById('keyword-input');
  const button = document.getElementById('button');

  //Takes input values and shares them with your Figma code
  function whenButtonIsClicked(){
    const hex = hexInput.value;
    const keyword = keywordInput.value;
    //Sends your values to your Figma code. * is the code's worker address
    parent.postMessage({ pluginMessage: { hex, keyword } }, '*')
  }

  //creates a listener that will activate whenever the button is clicked
  button.addEventListener('click', whenButtonIsClicked)
</script>

For a more detailed walkthrough of what is happening in this code, check out Brian’s tutorial which goes into more detail.

Step 3: Run your plugin

Right click > Plugins > Development > [select your plugin]

Draw some shapes

Change the layer name of the shapes to different colors (red, green, purple etc.)

Enter the hex color value and the key word (layer name) then hit “Change Color” to start seeing your shapes turn color

That’s it, you have your first Figma plugin!

Next steps

Obviously this is very basic and just to get you started.

I recommend checking the Figma API and GitHub plugin samples to discover what else you can do.

I opened up ChatGPT and utilized this to help me build more plugins.

My team ended up with a diverse set of plugins that went above and beyond this tutorial, all within a couple of hours.

Follow us on Dribbble and X for more, or subscribe to my newsletter for more content like this.

p.s. we’re hiring designers at OneSignal

10 years ago I put this really simple responsive HTML email template on GitHub.

It now has ⭐️12,700 stars & 🍴4,500 forks.

This was the original tweet: https://twitter.com/leemunroe/status/414062802836267008

Not a lot of engagement at first, but then it featured on the Hacker News homepage that attracted some attention: https://news.ycombinator.com/item?id=6946361

Over the last decade it has been used in lots of applications. Often you’ll see it when signing up to a new website, or when you need to reset your password.

It was the second thing I open-sourced on GitHub. The first was this HTML5/SCSS boilerplate I called “Motherplate”.

I recently tweaked the design of the template to modernize it and address some accessibility issues.

There is an email design system available on the Figma community that I just updated and has this simple template along with other “premium” email templates.

And if you like those templates and want the HTML, that is available at http://htmlemail.io

—

If you like content like this, subscribe to my newsletter https://leemunroe.com/subscribe

Get the simple responsive HTML email template on GitHub here https://github.com/leemunroe/responsive-html-email-template

When interviewing designers, PMs or engineers, I’ll usually get asked “how do you all work together?”. How does engineering work with PMs? PMs with design? Design with engineering?

My response goes something like this…

p.s. if you like this content, subscribe to my newsletter, or follow me on X/Twitter

When building great products, collaboration between designers, product managers and engineers is crucial. Often referred to as the trifecta, triad, EPD or 3 legged stool. I like to call it “Triforce”.

I love this talk by Marty Cagan on the root causes of product failure. He highlights why companies slide into waterfall, & products fail. Instead the best teams are learning together, focused on continuous discovery & delivery, responsible for outcomes.

At OneSignal we have cross-functional product teams that have focus areas.

Each team has at least a PM, DL (Design Lead) and TL (Tech Lead).

Each of these represents important aspects of the product. The business value, the user experience, the technical feasibility.

Examples of things teams do together to ensure shared understanding:

• Engineers join customer calls & usability tests
• Engineers take part in design studios & early brainstorms
• Designers join sprint planning
• PMs join architecture reviews
• Collectively review customer insights & roadmap in Productboard
• Collectively conduct retrospectives to improve how we work together
• Collectively measure and iterate on what was shipped, tracking adoption, addressing polish & enhancements

We have a “How we build” doc, as well as “How to work with…” guidelines.

For new team members this is required reading as part of onboarding.

These are just a few examples of the things that give us that shared understanding, enable us to make decisions together & ship product.

If you like this content, follow @OneSignalDesign and subscribe to my newsletter http://leemunroe.com/subscribe

p.s. we’re hiring designers at OneSignal