Last year, a study found that cars are steadily getting less colourful. In the US, around 80% of cars are now black, white, gray, or silver, up from 60% in 2004. This trend has been attributed to cost savings and consumer preferences. Whatever the reasons, the result is hard to deny: a big part of daily life isn’t as colourful as it used to be.

The colourfulness of mass consumer products is hardly the bellwether for how vibrant life is as a whole, but the study captures a trend a lot of us recognise — offline and on. From colour to design to public discourse, a lot of life is getting less varied, more grayscale.

The web is caught in the same current. There is plenty right with it — it retains plenty of its founding principles — but its state is not healthy. From AI slop to shoddy service providers to enshittification, the digital world faces its own grayscale problem.

This bears talking about. One of life’s great fallacies is that things get better over time on their own. They can, but it’s certainly not a given. I don’t think the moral arc of the universe does not bend towards justice, not on its own; I think it bends wherever it is dragged, kicking and screaming, by those with the will and the means to do so.

Much of the modern web, and the forces of optimisation and standardisation that drive it, bear an uncanny resemblance to the trend of car colours. Processes like market research and A/B testing — the process by which two options are compared to see which ‘performs’ better on clickthrough, engagement, etc. — have their value, but they don’t lend themselves to particularly stimulating design choices.

The spirit of free expression that made the formative years of the internet so exciting — think GeoCities, personal blogging, and so on — is on the slide.

The ongoing transition to a more decentralised, privacy-aware Web3 holds some promise. Two-thirds of the world’s population now has online access — though that still leaves plenty of work to do — with a wealth of platforms allowing billions of people to connect. The dream of a digital world that is open, connected, and flat endures, but is tainted.

Monopolies

One of the main sources of concern for me is that although more people are online than ever, they are concentrating on fewer and fewer sites. A study published in 2021 found that activity is concentrated in a handful of websites. Think Google, Amazon, Facebook, Instagram, and, more recently, ChatGPT:

“So, while there is still growth in the functions, features, and applications offered on the web, the number of entities providing these functions is shrinking. [...] The authority, influence, and visibility of the top 1,000 global websites (as measured by network centrality or PageRank) is growing every month, at the expense of all other sites.”

Monopolies by nature reduce variance, both through their domination of the market and (understandably in fairness) internal preferences for consistency. And, let’s be frank, they have a vested interest in crushing any potential upstarts.

• “Readability Algorithms Should Be Tools, Not Targets”
• “Towards An Ad-Free Web: Diversifying The Online Economy”

Dominant websites often fall victim to what I like to call Internet Explorer Syndrome, where their dominance breeds a certain amount of complacency. Why improve your quality when you’re sitting on 90% market share? No wonder the likes of Google are getting worse.

The most immediate sign of this is obviously how sites are designed and how they look. A lot of the big players look an awful lot like each other. Even personal websites are built atop third-party website builders. Millions of people wind up using the same handful of templates, and that’s if they have their own website at all. On social media, we are little more than a profile picture and a pithy tagline. The rest is boilerplate.

Should there be sleek, minimalist, ‘grayscale’ design systems and websites? Absolutely. But there should be colourful, kooky ones too, and if anything, they’re fading away. Do we really want to spend our online lives in the digital equivalent of Levittowns? Even logos are contriving to be less eye-catching. It feels like a matter of time before every major logo is a circle in a pastel colour.

The arrival of Artificial Intelligence into our everyday lives (and a decent chunk of the digital services we use) has put all of this into overdrive. Amalgamating — and hallucinating from — content that was already trending towards a perfect average, it is grayscale in its purest form.

Mix all the colours together, and what do you get? A muddy gray gloop.

I’m not railing against best practice. A lot of conventions have become the standard for good reason. One could just as easily shake their fist at the sky and wonder why all newspapers look the same, or all books. I hope the difference here is clear, though.

The web is a flexible enough domain that I think it belongs in the realm of architecture. A city where all buildings look alike has a soul-crushing quality about it. The same is true, I think, of the web.

“

In the Oscar Wilde play Lady Windermere’s Fan, a character quips that a cynic “knows the price of everything and the value of nothing.” In fairness, another quips back that a sentimentalist “sees an absurd value in everything, and doesn’t know the market price of any single thing.”

The sweet spot is somewhere in between. Structure goes a long way, but life needs a bit of variety too.

So, how do we go about bringing that variety? We probably shouldn’t hold our breath on big players to lead the way. They have the most to lose, after all. Why risk being colourful or dynamic if it impacts the bottom line?

We, the citizens of the web, have more power than we realise. This is the web, remember, a place where if you can imagine it, odds are you can make it. And at zero cost. No materials to buy and ship, no shareholders to appease. A place as flexible — and limitless — as the web has no business being boring.

There are plenty of ways, big and small, of keeping this place colourful. Whether our digital footprints are on third-party websites or ones we build ourselves, we needn’t toe the line.

Colour seems an appropriate place to start. When given the choice, try something audacious rather than safe. The worst that can happen is that it doesn’t work. It’s not like the sunk cost of painting a room; if you don’t like the palette, you simply change the hex codes. The same is true of fonts, icons, and other building blocks of the web.

As an example, a couple of friends and I listen to and review albums occasionally as a hobby. On the website, the palette of each review page reflects the album artwork:

I couldn’t tell you if reviews ‘perform’ better or worse than if they had a grayscale palette, because I don’t care. I think it’s a lot nicer to look at. And for those wondering, yes, I have tried to make every page meet AA Web Accessibility standards. Vibrant and accessible aren’t mutually exclusive.

Another great way of bringing vibrancy to the web is a degree of randomisation. Bruno Simon of Three Journey and awesome portfolio fame weaves random generation into a lot of his projects, and the results are gorgeous. What’s more, they feel familiar, natural, because life is full of wildcards.

This needn’t be in fancy 3D models. You could lightly rotate images to create a more informal, photo album mood, or chuck in the occasional random link in a list of recommended articles, just to shake things up.

In a lot of ways, it boils down to an attitude of just trying stuff out. Make your own font, give the site a sepia filter, and add that easter egg you keep thinking about. Just because someone, somewhere has already done it doesn’t mean you can’t do it your own way. And who knows, maybe your way stumbles onto someplace wholly new.

I’m wary of being too prescriptive. I don’t have the keys to a colourful web. No one person does. A vibrant community is the sum total of its people. What keeps things interesting is individuals trying wacky ideas and putting them out there. Expression for expression’s sake. Experimentation for experimentation’s sake. Tinkering for tinkering’s sake.

As users, there’s also plenty of room to be adventurous and try out open source alternatives to the software monopolies that shape so much of today’s Web. Being active in the communities that shape those tools helps to sustain a more open, collaborative digital world.

Although there are lessons to be taken from it, we won’t get a more colourful web by idealising the past or pining to get back to the ‘90s. Nor is there any point in resisting new technologies. AI is here; the choice is whether we use it or it uses us. We must have the courage to carry forward what still holds true, drop what doesn’t, and explore new ideas with a spirit of play.

Here are a few more Smashing articles in that spirit:

• “Playfulness In Code: Supercharge Your Learning By Having Fun” by Jhey Tompkins
• “The Psychology Of Color In UX And Digital Products” by Rodolpho Henrique
• “Creativity In A World Of Technology: Does It Exist?” By Maggie Mackenzie
• “What Zen And The Art Of Motorcycle Maintenance Can Teach Us About Web Design”
• “An Ode To Side Project Time”

I do think there’s a broader discussion to be had about the extent to which A/B tests, bottom lines, and focus groups seem to dictate much of how the modern web looks and feels. With sites being squeezed tighter and tighter by dwindling advertising revenues, and AI answers muscling in on search traffic, the corporate entities behind larger websites can’t justify doing anything other than what is safe and proven, for fear of shrinking their slice of the pie.

Lest we forget, though, most of the web isn’t beholden to those types of pressure. From pet projects to wikis to forums to community news outlets to all manner of other things, there are countless reasons for websites to exist, and they needn’t take design cues from the handful of sites slugging it out at the top.

Connected with this is the dire need for digital literacy (PDF) — ‘the confident and critical use of a full range of digital technologies for information, communication and basic problem-solving in all aspects of life.’ For as long as using third-party platforms is a necessity rather than a choice, the needle’s only going to move so much.

There’s a reason why Minecraft is the world’s best-selling game. People are creative. When given the tools — and the opportunity — that creativity will manifest in weird and wonderful ways. That game is a lot of things, but gray ain’t one of them.

The web has all of that flexibility and more. It is a manifestation of imagination. Imagination trends towards colour, not grayness. It doesn’t always feel like it, but where the internet goes is decided by its citizens. The internet is ours. If we want to, we can make it technicolor.

(yk)

I’ve written quite a lot recently about how I prepare and optimise SVG code to use as static graphics or in animations. I love working with SVG, but there’s always been something about them that bugs me.

To illustrate how I build adaptive SVGs, I’ve selected an episode of The Quick Draw McGraw Show called “Bow Wow Bandit,” first broadcast in 1959.

In it, Quick Draw McGraw enlists his bloodhound Snuffles to rescue his sidekick Baba Looey. Like most Hanna-Barbera title cards of the period, the artwork was made by Lawrence (Art) Goble.

Let’s say I’ve designed an SVG scene like that one that’s based on Bow Wow Bandit, which has a 16:9 aspect ratio with a viewBox size of 1920×1080. This SVG scales up and down (the clue’s in the name), so it looks sharp when it’s gigantic and when it’s minute.

But on small screens, the 16:9 aspect ratio (live demo) might not be the best format, and the image loses its impact. Sometimes, a portrait orientation, like 3:4, would suit the screen size better.

But, herein lies the problem, as it’s not easy to reposition internal elements for different screen sizes using just viewBox. That’s because in SVG, internal element positions are locked to the coordinate system from the original viewBox, so you can’t easily change their layout between, say, desktop and mobile. This is a problem because animations and interactivity often rely on element positions, which break when the viewBox changes.

My challenge was to serve a 1080×1440 version of Bow Wow Bandit to smaller screens and a different one to larger ones. I wanted the position and size of internal elements — like Quick Draw McGraw and his dawg Snuffles — to change to best fit these two layouts. To solve this, I experimented with several alternatives.

Note: Why are we not just using the <picture> with external SVGs? The <picture> element is brilliant for responsive images, but it only works with raster formats (like JPEG or WebP) and external SVG files treated as images. That means that you can’t animate or style internal elements using CSS.

Showing And Hiding SVG

The most obvious choice was to include two different SVGs in my markup, one for small screens, the other for larger ones, then show or hide them using CSS and Media Queries:

<svg id="svg-small" viewBox="0 0 1080 1440">
  <!-- ... -->
</svg>

<svg id="svg-large" viewBox="0 0 1920 1080">
  <!--... -->
</svg>


#svg-small { display: block; }
#svg-large { display: none; }

@media (min-width: 64rem) {
  #svg-small { display: none; }
  #svg-mobile { display: block; }
}

But using this method, both SVG versions are loaded, which, when the graphics are complex, means downloading lots and lots and lots of unnecessary code.

Replacing SVGs Using JavaScript

I thought about using JavaScript to swap in the larger SVG at a specified breakpoint:

if (window.matchMedia('(min-width: 64rem)').matches) {
  svgContainer.innerHTML = desktopSVG; 
} else {
  svgContainer.innerHTML = mobileSVG;
}

Leaving aside the fact that JavaScript would now be critical to how the design is displayed, both SVGs would usually be loaded anyway, which adds DOM complexity and unnecessary weight. Plus, maintenance becomes a problem as there are now two versions of the artwork to maintain, doubling the time it would take to update something as small as the shape of Quick Draw’s tail.

The Solution: One SVG Symbol Library And Multiple Uses

Remember, my goal is to:

• Serve one version of Bow Wow Bandit to smaller screens,
• Serve a different version to larger screens,
• Define my artwork just once (DRY), and
• Be able to resize and reposition elements.

I don’t read about it enough, but the <symbol> element lets you define reusable SVG elements that can be hidden and reused to improve maintainability and reduce code bloat. They’re like components for SVG: create once and use wherever you need them:

<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
  <symbol id="quick-draw-body" viewBox="0 0 620 700">
    <g class="quick-draw-body">[…]</g>
  </symbol>
  <!-- ... -->
</svg>

<use href="#quick-draw-body" />

A <symbol> is like storing a character in a library. I can reference it as many times as I need, to keep my code consistent and lightweight. Using <use> elements, I can insert the same symbol multiple times, at different positions or sizes, and even in different SVGs.

Each <symbol> must have its own viewBox, which defines its internal coordinate system. That means paying special attention to how SVG elements are exported from apps like Sketch.

Exporting For Individual Viewboxes

I wrote before about how I export elements in layers to make working with them easier. That process is a little different when creating symbols.

Ordinarily, I would export all my elements using the same viewBoxsize. But when I’m creating a symbol, I need it to have its own specific viewBox.

So I export each element as an individually sized SVG, which gives me the dimensions I need to convert its content into a symbol. Let’s take the SVG of Quick Draw McGraw’s hat, which has a viewBox size of 294×182:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 294 182">
  <!-- ... -->
</svg>

I swap the SVG tags for <symbol> and add its artwork to my SVG library:

<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
  <symbol id="quick-draw-hat" viewBox="0 0 294 182">
    <g class="quick-draw-hat">[…]</g>
  </symbol>
</svg>

Then, I repeat the process for all the remaining elements in my artwork. Now, if I ever need to update any of my symbols, the changes will be automatically applied to every instance it’s used.

Using A <symbol> In Multiple SVGs

I wanted my elements to appear in both versions of Bow Wow Bandit, one arrangement for smaller screens and an alternative arrangement for larger ones. So, I create both SVGs:

<svg class="svg-small" viewBox="0 0 1080 1440">
  <!-- ... -->
</svg>

<svg class="svg-large" viewBox="0 0 1920 1080">
  <!-- ... -->
</svg>

…and insert links to my symbols in both:

<svg class="svg-small" viewBox="0 0 1080 1440">
  <use href="#quick-draw-hat" />
</svg>

<svg class="svg-large" viewBox="0 0 1920 1080">
  <use href="#quick-draw-hat" />
</svg>

Positioning Symbols

Once I’ve placed symbols into my layout using <use>, my next step is to position them, which is especially important if I want alternative layouts for different screen sizes. Symbols behave like <g> groups, so I can scale and move them using attributes like width, height, and transform:

<svg class="svg-small" viewBox="0 0 1080 1440">
  <use href="#quick-draw-hat" width="294" height="182" transform="translate(-30,610)"/>
</svg>

<svg class="svg-large" viewBox="0 0 1920 1080">
  <use href="#quick-draw-hat" width="294" height="182" transform="translate(350,270)"/>
</svg>

I can place each <use> element independently using transform. This is powerful because rather than repositioning elements inside my SVGs, I move the <use> references. My internal layout stays clean, and the file size remains small because I’m not duplicating artwork. A browser only loads it once, which reduces bandwidth and speeds up page rendering. And because I’m always referencing the same symbol, their appearance stays consistent, whatever the screen size.

Animating <use> Elements

Here’s where things got tricky. I wanted to animate parts of my characters — like Quick Draw’s hat tilting and his legs kicking. But when I added CSS animations targeting internal elements inside a <symbol>, nothing happened.

Tip: You can animate the <use> element itself, but not elements inside the <symbol>. If you want individual parts to move, make them their own symbols and animate each <use>.

Turns out, you can’t style or animate a <symbol>, because <use> creates shadow DOM clones that aren’t easily targetable. So, I had to get sneaky. Inside each <symbol> in my library SVG, I added a <g> element around the part I wanted to animate:

<symbol id="quick-draw-hat" viewBox="0 0 294 182">
  <g class="quick-draw-hat">
    <!-- ... -->
  </g>
</symbol>

…and animated it using an attribute substring selector, targeting the href attribute of the use element:

use[href="#quick-draw-hat"] {
  animation-delay: 0.5s;
  animation-direction: alternate;
  animation-duration: 1s;
  animation-iteration-count: infinite;
  animation-name: hat-rock;
  animation-timing-function: ease-in-out;
  transform-origin: center bottom;
}

@keyframes hat-rock {
from { transform: rotate(-2deg); }
to   { transform: rotate(2deg); } }

Media Queries For Display Control

Once I’ve created my two visible SVGs — one for small screens and one for larger ones — the final step is deciding which version to show at which screen size. I use CSS Media Queries to hide one SVG and show the other. I start by showing the small-screen SVG by default:

.svg-small { display: block; }
.svg-large { display: none; }

Then I use a min-width media query to switch to the large-screen SVG at 64rem and above:

@media (min-width: 64rem) {
  .svg-small { display: none; }
  .svg-large { display: block; }
}

This ensures there’s only ever one SVG visible at a time, keeping my layout simple and the DOM free from unnecessary clutter. And because both visible SVGs reference the same hidden <symbol> library, the browser only downloads the artwork once, regardless of how many <use> elements appear across the two layouts.

Wrapping Up

By combining <symbol>, <use>, CSS Media Queries, and specific transforms, I can build adaptive SVGs that reposition their elements without duplicating content, loading extra assets, or relying on JavaScript. I need to define each graphic only once in a hidden symbol library. Then I can reuse those graphics, as needed, inside several visible SVGs. With CSS doing the layout switching, the result is fast and flexible.

It’s a reminder that some of the most powerful techniques on the web don’t need big frameworks or complex tooling — just a bit of SVG know-how and a clever use of the basics.

(gg, yk)

In Part 1 of this series, we explored the “lopsided horse” problem born from mockup-centric design and demonstrated how the seductive promise of vibe coding often leads to structural flaws. The main question remains:

How might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one, without getting caught in the ambiguity trap?

In other words, we need a way to build prototypes that are both fast to create and founded on a clear, unambiguous blueprint.

The answer is a more disciplined process I call Intent Prototyping (kudos to Marco Kotrotsos, who coined Intent-Oriented Programming). This method embraces the power of AI-assisted coding but rejects ambiguity, putting the designer’s explicit intent at the very center of the process. It receives a holistic expression of intent (sketches for screen layouts, conceptual model description, boxes-and-arrows for user flows) and uses it to generate a live, testable prototype.

This method solves the concerns we’ve discussed in Part 1 in the best way possible:

• Unlike static mockups, the prototype is fully interactive and can be easily populated with a large amount of realistic data. This lets us test the system’s underlying logic as well as its surface.
• Unlike a vibe-coded prototype, it is built from a stable, unambiguous specification. This prevents the conceptual model failures and design debt that happen when things are unclear. The engineering team doesn’t need to reverse-engineer a black box or become “code archaeologists” to guess at the designer’s vision, as they receive not only a live prototype but also a clearly documented design intent behind it.

This combination makes the method especially suited for designing complex enterprise applications. It allows us to test the system’s most critical point of failure, its underlying structure, at a speed and flexibility that was previously impossible. Furthermore, the process is built for iteration. You can explore as many directions as you want simply by changing the intent and evolving the design based on what you learn from user testing.

My Workflow

To illustrate this process in action, let’s walk through a case study. It’s the very same example I’ve used to illustrate the vibe coding trap: a simple tool to track tests to validate product ideas. You can find the complete project, including all the source code and documentation files discussed below, in this GitHub repository.

Step 1: Expressing An Intent

Imagine we’ve already done proper research, and having mused on the defined problem, I begin to form a vague idea of what the solution might look like. I need to capture this idea immediately, so I quickly sketch it out:

In this example, I used Excalidraw, but the tool doesn’t really matter. Note that we deliberately keep it rough, as visual details are not something we need to focus on at this stage. And we are not going to be stuck here: we want to make a leap from this initial sketch directly to a live prototype that we can put in front of potential users. Polishing those sketches would not bring us any closer to achieving our goal.

What we need to move forward is to add to those sketches just enough details so that they may serve as a sufficient input for a junior frontend developer (or, in our case, an AI assistant). This requires explaining the following:

• Navigational paths (clicking here takes you to).
• Interaction details that can’t be shown in a static picture (e.g., non-scrollable areas, adaptive layout, drag-and-drop behavior).
• What parts might make sense to build as reusable components.
• Which components from the design system (I’m using Ant Design Library) should be used.
• Any other comments that help understand how this thing should work (while sketches illustrate how it should look).

Having added all those details, we end up with such an annotated sketch:

As you see, this sketch covers both the Visualization and Flow aspects. You may ask, what about the Conceptual Model? Without that part, the expression of our intent will not be complete. One way would be to add it somewhere in the margins of the sketch (for example, as a UML Class Diagram), and I would do so in the case of a more complex application, where the model cannot be simply derived from the UI. But in our case, we can save effort and ask an LLM to generate a comprehensive description of the conceptual model based on the sketch.

For tasks of this sort, the LLM of my choice is Gemini 2.5 Pro. What is important is that this is a multimodal model that can accept not only text but also images as input (GPT-5 and Claude-4 also fit that criteria). I use Google AI Studio, as it gives me enough control and visibility into what’s happening:

Note: All the prompts that I use here and below can be found in the Appendices. The prompts are not custom-tailored to any particular project; they are supposed to be reused as they are.

As a result, Gemini gives us a description and the following diagram:

The diagram might look technical, but I believe that a clear understanding of all objects, their attributes, and relationships between them is key to good design. That’s why I consider the Conceptual Model to be an essential part of expressing intent, along with the Flow and Visualization.

As a result of this step, our intent is fully expressed in two files: Sketch.png and Model.md. This will be our durable source of truth.

Step 2: Preparing A Spec And A Plan

The purpose of this step is to create a comprehensive technical specification and a step-by-step plan. Most of the work here is done by AI; you just need to keep an eye on it.

I separate the Data Access Layer and the UI layer, and create specifications for them using two different prompts (see Appendices 2 and 3). The output of the first prompt (the Data Access Layer spec) serves as an input for the second one. Note that, as an additional input, we give the guidelines tailored for prototyping needs (see Appendices 8, 9, and 10). They are not specific to this project. The technical approach encoded in those guidelines is out of the scope of this article.

As a result, Gemini provides us with content for DAL.md and UI.md. Although in most cases this result is quite reliable enough, you might want to scrutinize the output. You don’t need to be a real programmer to make sense of it, but some level of programming literacy would be really helpful. However, even if you don’t have such skills, don’t get discouraged. The good news is that if you don’t understand something, you always know who to ask. Do it in Google AI Studio before refreshing the context window. If you believe you’ve spotted a problem, let Gemini know, and it will either fix it or explain why the suggested approach is actually better.

It’s important to remember that by their nature, LLMs are not deterministic and, to put it simply, can be forgetful about small details, especially when it comes to details in sketches. Fortunately, you don’t have to be an expert to notice that the “Delete” button, which is in the upper right corner of the sketch, is not mentioned in the spec.

Don’t get me wrong: Gemini does a stellar job most of the time, but there are still times when it slips up. Just let it know about the problems you’ve spotted, and everything will be fixed.

Once we have Sketch.png, Model.md, DAL.md, UI.md, and we have reviewed the specs, we can grab a coffee. We deserve it: our technical design documentation is complete. It will serve as a stable foundation for building the actual thing, without deviating from our original intent, and ensuring that all components fit together perfectly, and all layers are stacked correctly.

One last thing we can do before moving on to the next steps is to prepare a step-by-step plan. We split that plan into two parts: one for the Data Access Layer and another for the UI. You can find prompts I use to create such a plan in Appendices 4 and 5.

Step 3: Executing The Plan

To start building the actual thing, we need to switch to another category of AI tools. Up until this point, we have relied on Generative AI. It excels at creating new content (in our case, specifications and plans) based on a single prompt. I’m using Google Gemini 2.5 Pro in Google AI Studio, but other similar tools may also fit such one-off tasks: ChatGPT, Claude, Grok, and DeepSeek.

However, at this step, this wouldn’t be enough. Building a prototype based on specs and according to a plan requires an AI that can read context from multiple files, execute a sequence of tasks, and maintain coherence. A simple generative AI can’t do this. It would be like asking a person to build a house by only ever showing them a single brick. What we need is an agentic AI that can be given the full house blueprint and a project plan, and then get to work building the foundation, framing the walls, and adding the roof in the correct sequence.

My coding agent of choice is Google Gemini CLI, simply because Gemini 2.5 Pro serves me well, and I don’t think we need any middleman like Cursor or Windsurf (which would use Claude, Gemini, or GPT under the hood anyway). If I used Claude, my choice would be Claude Code, but since I’m sticking with Gemini, Gemini CLI it is. But if you prefer Cursor or Windsurf, I believe you can apply the same process with your favourite tool.

Before tasking the agent, we need to create a basic template for our React application. I won’t go into this here. You can find plenty of tutorials on how to scaffold an empty React project using Vite.

Then we put all our files into that project:

Once the basic template with all our files is ready, we open Terminal, go to the folder where our project resides, and type “gemini”:

And we send the prompt to build the Data Access Layer (see Appendix 6). That prompt implies step-by-step execution, so upon completion of each step, I send the following:

Thank you! Now, please move to the next task.
Remember that you must not make assumptions based on common patterns; always verify them with the actual data from the spec. 
After each task, stop so that I can test it. Don’t move to the next task before I tell you to do so.

As the last task in the plan, the agent builds a special page where we can test all the capabilities of our Data Access Layer, so that we can manually test it. It may look like this:

It doesn’t look fancy, to say the least, but it allows us to ensure that the Data Access Layer works correctly before we proceed with building the final UI.

And finally, we clear the Gemini CLI context window to give it more headspace and send the prompt to build the UI (see Appendix 7). This prompt also implies step-by-step execution. Upon completion of each step, we test how it works and how it looks, following the “Manual Testing Plan” from UI-plan.md. I have to say that despite the fact that the sketch has been uploaded to the model context and, in general, Gemini tries to follow it, attention to visual detail is not one of its strengths (yet). Usually, a few additional nudges are needed at each step to improve the look and feel:

Once I’m happy with the result of a step, I ask Gemini to move on:

Thank you! Now, please move to the next task.
Make sure you build the UI according to the sketch; this is very important. Remember that you must not make assumptions based on common patterns; always verify them with the actual data from the spec and the sketch.  
After each task, stop so that I can test it. Don’t move to the next task before I tell you to do so.

Before long, the result looks like this, and in every detail it works exactly as we intended:

The prototype is up and running and looking nice. Does it mean that we are done with our work? Surely not, the most fascinating part is just beginning.

Step 4: Learning And Iterating

It’s time to put the prototype in front of potential users and learn more about whether this solution relieves their pain or not.

And as soon as we learn something new, we iterate. We adjust or extend the sketches and the conceptual model, based on that new input, we update the specifications, create plans to make changes according to the new specifications, and execute those plans. In other words, for every iteration, we repeat the steps I’ve just walked you through.

Is This Workflow Too Heavy?

This four-step workflow may create an impression of a somewhat heavy process that requires too much thinking upfront and doesn’t really facilitate creativity. But before jumping to that conclusion, consider the following:

• In practice, only the first step requires real effort, as well as learning in the last step. AI does most of the work in between; you just need to keep an eye on it.
• Individual iterations don’t need to be big. You can start with a Walking Skeleton: the bare minimum implementation of the thing you have in mind, and add more substance in subsequent iterations. You are welcome to change your mind about the overall direction in between iterations.
• And last but not least, maybe the idea of “think before you do” is not something you need to run away from. A clear and unambiguous statement of intent can prevent many unnecessary mistakes and save a lot of effort down the road.

Intent Prototyping Vs. Other Methods

There is no method that fits all situations, and Intent Prototyping is not an exception. Like any specialized tool, it has a specific purpose. The most effective teams are not those who master a single method, but those who understand which approach to use to mitigate the most significant risk at each stage. The table below gives you a way to make this choice clearer. It puts Intent Prototyping next to other common methods and tools and explains each one in terms of the primary goal it helps achieve and the specific risks it is best suited to mitigate.

The key takeaway is that each method is a specialized tool for mitigating a specific type of risk. For example, Figma de-risks the visual presentation. ProtoPie de-risks the feel of an interaction. Intent Prototyping is in a unique position to tackle the most foundational risk in complex applications: building on a flawed or incoherent conceptual model.

Bringing It All Together

The era of the “lopsided horse” design, sleek on the surface but structurally unsound, is a direct result of the trade-off between fidelity and flexibility. This trade-off has led to a process filled with redundant effort and misplaced focus. Intent Prototyping, powered by modern AI, eliminates that conflict. It’s not just a shortcut to building faster — it’s a fundamental shift in how we design. By putting a clear, unambiguous intent at the heart of the process, it lets us get rid of the redundant work and focus on architecting a sound and robust system.

There are three major benefits to this renewed focus. First, by going straight to live, interactive prototypes, we shift our validation efforts from the surface to the deep, testing the system’s actual logic with users from day one. Second, the very act of documenting the design intent makes us clear about our ideas, ensuring that we fully understand the system’s underlying logic. Finally, this documented intent becomes a durable source of truth, eliminating the ambiguous handoffs and the redundant, error-prone work of having engineers reverse-engineer a designer’s vision from a black box.

Ultimately, Intent Prototyping changes the object of our work. It allows us to move beyond creating pictures of a product and empowers us to become architects of blueprints for a system. With the help of AI, we can finally make the live prototype the primary canvas for ideation, not just a high-effort afterthought.

Appendices

You can find the full Intent Prototyping Starter Kit, which includes all those prompts and guidelines, as well as the example from this article and a minimal boilerplate project, in this GitHub repository.

(yk)

In “A Week In The Life Of An AI-Augmented Designer”, Kate stumbled her way through an AI-augmented sprint (coffee was chugged, mistakes were made). In “Prompting Is A Design Act”, we introduced WIRE+FRAME, a framework to structure prompts like designers structure creative briefs. Now we’ll take the next step: packaging those structured prompts into AI assistants you can design, reuse, and share.

AI assistants go by different names: CustomGPTs (ChatGPT), Agents (Copilot), and Gems (Gemini). But they all serve the same function — allowing you to customize the default AI model for your unique needs. If we carry over our smart intern analogy, think of these as interns trained to assist you with specific tasks, eliminating the need for repeated instructions or information, and who can support not just you, but your entire team.

Why Build Your Own Assistant?

If you’ve ever copied and pasted the same mega-prompt for the n^th time, you’ve experienced the pain. An AI assistant turns a one-off “great prompt” into a dependable teammate. And if you’ve used any of the publicly available AI Assistants, you’ve realized quickly that they’re usually generic and not tailored for your use.

Public AI assistants are great for inspiration, but nothing beats an assistant that solves a repeated problem for you and your team, in your voice, with your context and constraints baked in. Instead of reinventing the wheel by writing new prompts each time, or repeatedly copy-pasting your structured prompts every time, or spending cycles trying to make a public AI Assistant work the way you need it to, your own AI Assistant allows you and others to easily get better, repeatable, consistent results faster.

Benefits Of Reusing Prompts, Even Your Own

Some of the benefits of building your own AI Assistant over writing or reusing your prompts include:

• Focused on a real repeating problem
  A good AI Assistant isn’t a general-purpose “do everything” bot that you need to keep tweaking. It focuses on a single, recurring problem that takes a long time to complete manually and often results in varying quality depending on who’s doing it (e.g., analyzing customer feedback).
• Customized for your context
  Most large language models (LLMs, such as ChatGPT) are designed to be everything to everyone. An AI Assistant changes that by allowing you to customize it to automatically work like you want it to, instead of a generic AI.
• Consistency at scale
  You can use the WIRE+FRAME prompt framework to create structured, reusable prompts. An AI Assistant is the next logical step: instead of copy-pasting that fine-tuned prompt and sharing contextual information and examples each time, you can bake it into the assistant itself, allowing you and others achieve the same consistent results every time.
• Codifying expertise
  Every time you turn a great prompt into an AI Assistant, you’re essentially bottling your expertise. Your assistant becomes a living design guide that outlasts projects (and even job changes).
• Faster ramp-up for teammates
  Instead of new designers starting from a blank slate, they can use pre-tuned assistants. Think of it as knowledge transfer without the long onboarding lecture.
  

Reasons For Your Own AI Assistant Instead Of Public AI Assistants

Public AI assistants are like stock templates. While they serve a specific purpose compared to the generic AI platform, and are useful starting points, if you want something tailored to your needs and team, you should really build your own.

A few reasons for building your AI Assistant instead of using a public assistant someone else created include:

• Fit: Public assistants are built for the masses. Your work has quirks, tone, and processes they’ll never quite match.
• Trust & Security: You don’t control what instructions or hidden guardrails someone else baked in. With your own assistant, you know exactly what it will (and won’t) do.
• Evolution: An AI Assistant you design and build can grow with your team. You can update files, tweak prompts, and maintain a changelog — things a public bot won’t do for you.

Your own AI Assistants allow you to take your successful ways of interacting with AI and make them repeatable and shareable. And while they are tailored to your and your team’s way of working, remember that they are still based on generic AI models, so the usual AI disclaimers apply:

Don’t share anything you wouldn’t want screenshotted in the next company all-hands. Keep it safe, private, and user-respecting. A shared AI Assistant can potentially reveal its inner workings or data.

Note: We will be building an AI assistant using ChatGPT, aka a CustomGPT, but you can try the same process with any decent LLM sidekick. As of publication, a paid account is required to create CustomGPTs, but once created, they can be shared and used by anyone, regardless of whether they have a paid or free account. Similar limitations apply to the other platforms. Just remember that outputs can vary depending on the LLM model used, the model’s training, mood, and flair for creative hallucinations.

When Not to Build An AI Assistant (Yet)

An AI Assistant is great when the same audience has the same problem often. When the fit isn’t there, the risk is high; you should skip building an AI Assistant for now, as explained below:

• One-off or rare tasks
  If it won’t be reused at least monthly, I’d recommend keeping it as a saved WIRE+FRAME prompt. For example, something for a one-time audit or creating placeholder content for a specific screen.
• Sensitive or regulated data
  If you need to build in personally identifiable information (PII), health, finance, legal, or trade secrets, err on the side of not building an AI Assistant. Even if the AI platform promises not to use your data, I’d strongly suggest using redaction or an approved enterprise tool with necessary safeguards in place (company-approved enterprise versions of Microsoft Copilot, for instance).
• Heavy orchestration or logic
  Multi-step workflows, API calls, database writes, and approvals go beyond the scope of an AI Assistant into Agentic territory (as of now). I’d recommend not trying to build an AI Assistant for these cases.
• Real-time information
  AI Assistants may not be able to access real-time data like prices, live metrics, or breaking news. If you need these, you can upload near-real-time data (as we do below) or connect with data sources that you or your company controls, rather than relying on the open web.
• High-stakes outputs
  For cases related to compliance, legal, medical, or any other area requiring auditability, consider implementing process guardrails and training to keep humans in the loop for proper review and accountability.
• No measurable win
  If you can’t name a success metric (such as time saved, first-draft quality, or fewer re-dos), I’d recommend keeping it as a saved WIRE+FRAME prompt.

Just because these are signs that you should not build your AI Assistant now, doesn’t mean you shouldn’t ever. Revisit this decision when you notice that you’re starting to repeatedly use the same prompt weekly, multiple teammates ask for it, or manual time copy-pasting and refining start exceeding ~15 minutes. Those are some signs that an AI Assistant will pay back quickly.

In a nutshell, build an AI Assistant when you can name the problem, the audience, frequency, and the win. The rest of this article shows how to turn your successful WIRE+FRAME prompt into a CustomGPT that you and your team can actually use. No advanced knowledge, coding skills, or hacks needed.

As Always, Start with the User

This should go without saying to UX professionals, but it’s worth a reminder: if you’re building an AI assistant for anyone besides yourself, start with the user and their needs before you build anything.

• Who will use this assistant?
• What’s the specific pain or task they struggle with today?
• What language, tone, and examples will feel natural to them?

Building without doing this first is a sure way to end up with clever assistants nobody actually wants to use. Think of it like any other product: before you build features, you understand your audience. The same rule applies here, even more so, because AI assistants are only as helpful as they are useful and usable.

From Prompt To Assistant

You’ve already done the heavy lifting with WIRE+FRAME. Now you’re just turning that refined and reliable prompt into a CustomGPT you can reuse and share. You can use MATCH as a checklist to go from a great prompt to a useful AI assistant.

• M: Map your prompt
  Port your successful WIRE+FRAME prompt into the AI assistant.
• A: Add knowledge and training
  Ground the assistant in your world. Upload knowledge files, examples, or guides that make it uniquely yours.
• T: Tailor for audience
  Make it feel natural to the people who will use it. Give it the right capabilities, but also adjust its settings, tone, examples, and conversation starters so they land with your audience.
• C: Check, test, and refine
  Test the preview with different inputs and refine until you get the results you expect.
• H: Hand off and maintain
  Set sharing options and permissions, share the link, and maintain it.

A few weeks ago, we invited readers to share their ideas for AI assistants they wished they had. The top contenders were:

• Prototype Prodigy: Transform rough ideas into prototypes and export them into Figma to refine.
• Critique Coach: Review wireframes or mockups and point out accessibility and usability gaps.

But the favorite was an AI assistant to turn tons of customer feedback into actionable insights. Readers replied with variations of: “An assistant that can quickly sort through piles of survey responses, app reviews, or open-ended comments and turn them into themes we can act on.”

And that’s the one we will build in this article — say hello to Insight Interpreter.

Walkthrough: Insight Interpreter

Having lots of customer feedback is a nice problem to have. Companies actively seek out customer feedback through surveys and studies (solicited), but also receive feedback that may not have been asked for through social media or public reviews (unsolicited). This is a goldmine of information, but it can be messy and overwhelming trying to make sense of it all, and it’s nobody’s idea of fun. Here’s where an AI assistant like the Insight Interpreter can help. We’ll turn the example prompt created using the WIRE+FRAME framework in Prompting Is A Design Act into a CustomGPT.

When you start building a CustomGPT by visiting https://chat.openai.com/gpts/editor, you’ll see two paths:

• Conversational interface
  Vibe-chat your way — it’s easy and quick, but similar to unstructured prompts, your inputs get baked in a little messily, so you may end up with vague or inconsistent instructions.
• Configure interface
  The structured form where you type instructions, upload files, and toggle capabilities. Less instant gratification, less winging it, but more control. This is the option you’ll want for assistants you plan to share or depend on regularly.

The good news is that MATCH works for both. In conversational mode, you can use it as a mental checklist, and we’ll walk through using it in configure mode as a more formal checklist in this article.

M: Map Your Prompt

Paste your full WIRE+FRAME prompt into the Instructions section exactly as written. As a refresher, I’ve included the mapping and snippets of the detailed prompt from before:

• Who & What: The AI persona and the core deliverable (“…senior UX researcher and customer insights analyst… specialize in synthesizing qualitative data from diverse sources…”).
• Input Context: Background or data scope to frame the task (“…analyzing customer feedback uploaded from sources such as…”).
• Rules & Constraints: Boundaries (“…do not fabricate pain points, representative quotes, journey stages, or patterns…”).
• Expected Output: Format and fields of the deliverable (“…a structured list of themes. For each theme, include…”).
• Flow: Explicit, ordered sub-tasks (“Recommended flow of tasks: Step 1…”).
• Reference Voice: Tone, mood, or reference (“…concise, pattern-driven, and objective…”).
• Ask for Clarification: Ask questions if unclear (“…if data is missing or unclear, ask before continuing…”).
• Memory: Memory to recall earlier definitions (“Unless explicitly instructed otherwise, keep using this process…”).
• Evaluate & Iterate: Have the AI self-critique outputs (“…critically evaluate…suggest improvements…”).

If you’re building Copilot Agents or Gemini Gems instead of CustomGPTs, you still paste your WIRE+FRAME prompt into their respective Instructions sections.

A: Add Knowledge And Training

In the knowledge section, upload up to 20 files, clearly labeled, that will help the CustomGPT respond effectively. Keep files small and versioned: reviews_Q2_2025.csv beats latestfile_final2.csv. For this prompt for analyzing customer feedback, generating themes organized by customer journey, rating them by severity and effort, files could include:

• Taxonomy of themes;
• Instructions on parsing uploaded data;
• Examples of real UX research reports using this structure;
• Scoring guidelines for severity and effort, e.g., what makes something a 3 vs. a 5 in severity;
• Customer journey map stages;
• Customer feedback file templates (not actual data).

An example of a file to help it parse uploaded data is shown below:

T: Tailor For Audience

• Audience tailoring
  If you are building this for others, your prompt should have addressed tone in the “Reference Voice” section. If you didn’t, do it now, so the CustomGPT can be tailored to the tone and expertise level of users who will use it. In addition, use the Conversation starters section to add a few examples or common prompts for users to start using the CustomGPT, again, worded for your users. For instance, we could use “Analyze feedback from the attached file” for our Insights Interpreter to make it more self-explanatory for anyone, instead of “Analyze data,” which may be good enough if you were using it alone. For my Designerly Curiosity GPT, assuming that users may not know what it could do, I use “What are the types of curiosity?” and “Give me a micro-practice to spark curiosity”.
• Functional tailoring
  Fill in the CustomGPT name, icon, description, and capabilities.
  • Name: Pick one that will make it clear what the CustomGPT does. Let’s use “Insights Interpreter — Customer Feedback Analyzer”. If needed, you can also add a version number. This name will show up in the sidebar when people use it or pin it, so make the first part memorable and easily identifiable.
  • Icon: Upload an image or generate one. Keep it simple so it can be easily recognized in a smaller dimension when people pin it in their sidebar.
  • Description: A brief, yet clear description of what the CustomGPT can do. If you plan to list it in the GPT store, this will help people decide if they should pick yours over something similar.
  • Recommended Model: If your CustomGPT needs the capabilities of a particular model (e.g., needs GPT-5 thinking for detailed analysis), select it. In most cases, you can safely leave it up to the user or select the most common model.
  • Capabilities: Turn off anything you won’t need. We’ll turn off “Web Search” to allow the CustomGPT to focus only on uploaded data, without expanding the search online, and we will turn on “Code Interpreter & Data Analysis” to allow it to understand and process uploaded files. “Canvas” allows users to work on a shared canvas with the GPT to edit writing tasks; “Image generation” - if the CustomGPT needs to create images.
  • Actions: Making third-party APIs available to the CustomGPT, advanced functionality we don’t need.
  • Additional Settings: Sneakily hidden and opted in by default, I opt out of training OpenAI’s models.

C: Check, Test & Refine

Do one last visual check to make sure you’ve filled in all applicable fields and the basics are in place: is the concept sharp and clear (not a do-everything bot)? Are the roles, goals, and tone clear? Do we have the right assets (docs, guides) to support it? Is the flow simple enough that others can get started easily? Once those boxes are checked, move into testing.

Use the Preview panel to verify that your CustomGPT performs as well, or better, than your original WIRE+FRAME prompt, and that it works for your intended audience. Try a few representative inputs and compare the results to what you expected. If something worked before but doesn’t now, check whether new instructions or knowledge files are overriding it.

When things don’t look right, here are quick debugging fixes:

• Generic answers?
  Tighten Input Context or update the knowledge files.
• Hallucinations?
  Revisit your Rules section. Turn off web browsing if you don’t need external data.
• Wrong tone?
  Strengthen Reference Voice or swap in clearer examples.
• Inconsistent?
  Test across models in preview and set the most reliable one as “Recommended.”

H: Hand Off And Maintain

When your CustomGPT is ready, you can publish it via the “Create” option. Select the appropriate access option:

• Only me: Private use. Perfect if you’re still experimenting or keeping it personal.
• Anyone with the link: Exactly what it means. Shareable but not searchable. Great for pilots with a team or small group. Just remember that links can be reshared, so treat them as semi-public.
• GPT Store: Fully public. Your assistant is listed and findable by anyone browsing the store. (This is the option we’ll use.)
• Business workspace (if you’re on GPT Business): Share with others within your business account only — the easiest way to keep it in-house and controlled.

But hand off doesn’t end with hitting publish, you should maintain it to keep it relevant and useful:

• Collect feedback: Ask teammates what worked, what didn’t, and what they had to fix manually.
• Iterate: Apply changes directly or duplicate the GPT if you want multiple versions in play. You can find all your CustomGPTs at: https://chatgpt.com/gpts/mine
• Track changes: Keep a simple changelog (date, version, updates) for traceability.
• Refresh knowledge: Update knowledge files and examples on a regular cadence so answers don’t go stale.

And that’s it! Our Insights Interpreter is now live!

Since we used the WIRE+FRAME prompt from the previous article to create the Insights Interpreter CustomGPT, I compared the outputs:

The results are similar, with slight differences, and that’s expected. If you compare the results carefully, the themes, issues, journey stages, frequency, severity, and estimated effort match with some differences in wording of the theme, issue summary, and problem statement. The opportunities and quotes have more visible differences. Most of it is because of the CustomGPT knowledge and training files, including instructions, examples, and guardrails, now live as always-on guidance.

Keep in mind that in reality, Generative AI is by nature generative, so outputs will vary. Even with the same data, you won’t get identical wording every time. In addition, underlying models and their capabilities rapidly change. If you want to keep things as consistent as possible, recommend a model (though people can change it), track versions of your data, and compare for structure, priorities, and evidence rather than exact wording.

While I’d love for you to use Insights Interpreter, I strongly recommend taking 15 minutes to follow the steps above and create your own. That is exactly what you or your team needs — including the tone, context, output formats, and get the real AI Assistant you need!

Inspiration For Other AI Assistants

We just built the Insight Interpreter and mentioned two contenders: Critique Coach and Prototype Prodigy. Here are a few other realistic uses that can spark ideas for your own AI Assistant:

• Workshop Wizard: Generates workshop agendas, produces icebreaker questions, and follows up survey drafts.
• Research Roundup Buddy: Summarizes raw transcripts into key themes, then creates highlight reels (quotes + visuals) for team share-outs.
• Persona Refresher: Updates stale personas with the latest customer feedback, then rewrites them in different tones (boardroom formal vs. design-team casual).
• Content Checker: Proofs copy for tone, accessibility, and reading level before it ever hits your site.
• Trend Tamer: Scans competitor reviews and identifies emerging patterns you can act on before they reach your roadmap.
• Microcopy Provocateur: Tests alternate copy options by injecting different tones (sassy, calm, ironic, nurturing) and role-playing how users might react, especially useful for error states or Call to Actions.
• Ethical UX Debater: Challenges your design decisions and deceptive designs by simulating the voice of an ethics board or concerned user.

The best AI Assistants come from carefully inspecting your workflow and looking for areas where AI can augment your work regularly and repetitively. Then follow the steps above to build a team of customized AI assistants.

Ask Me Anything About Assistants

• What are some limitations of a CustomGPT?
  Right now, the best parallels for AI are a very smart intern with access to a lot of information. CustomGPTs are still running on LLM models that are basically trained on a lot of information and programmed to predictively generate responses based on that data, including possible bias, misinformation, or incomplete information. Keeping that in mind, you can make that intern provide better and more relevant results by using your uploads as onboarding docs, your guardrails as a job description, and your updates as retraining.
• Can I copy someone else’s public CustomGPT and tweak it?
  Not directly, but if you get inspired by another CustomGPT, you can look at how it’s framed and rebuild your own using WIRE+FRAME & MATCH. That way, you make it your own and have full control of the instructions, files, and updates. But you can do that with Google’s equivalent — Gemini Gems. Shared Gems behave similarly to shared Google Docs, so once shared, any Gem instructions and files that you have uploaded can be viewed by any user with access to the Gem. Any user with edit access to the Gem can also update and delete the Gem.
• How private are my uploaded files?
  The files you upload are stored and used to answer prompts to your CustomGPT. If your CustomGPT is not private or you didn’t disable the hidden setting to allow CustomGPT conversations to improve the model, that data could be referenced. Don’t upload sensitive, confidential, or personal data you wouldn’t want circulating. Enterprise accounts do have some protections, so check with your company.
• How many files can I upload, and does size matter?
  Limits vary by platform, but smaller, specific files usually perform better than giant docs. Think “chapter” instead of “entire book.” At the time of publishing, CustomGPTs allow up to 20 files, Copilot Agents up to 200 (if you need anywhere near that many, chances are your agent is not focused enough), and Gemini Gems up to 10.
• What’s the difference between a CustomGPT and a Project?
  A CustomGPT is a focused assistant, like an intern trained to do one role well (like “Insight Interpreter”). A Project is more like a workspace where you can group multiple prompts, files, and conversations together for a broader effort. CustomGPTs are specialists. Projects are containers. If you want something reusable, shareable, and role-specific, go to CustomGPT. If you want to organize broader work with multiple tools and outputs, and shared knowledge, Projects are the better fit.

From Reading To Building

In this AI x Design series, we’ve gone from messy prompting (“A Week In The Life Of An AI-Augmented Designer”) to a structured prompt framework, WIRE+FRAME (“Prompting Is A Design Act”). And now, in this article, your very own reusable AI sidekick.

CustomGPTs don’t replace designers but augment them. The real magic isn’t in the tool itself, but in how you design and manage it. You can use public CustomGPTs for inspiration, but the ones that truly fit your workflow are the ones you design yourself. They extend your craft, codify your expertise, and give your team leverage that generic AI models can’t.

Build one this week. Even better, today. Train it, share it, stress-test it, and refine it into an AI assistant that can augment your team.

(yk)

There is a spectrum of opinions on how dramatically all creative professions will be changed by the coming wave of agentic AI, from the very skeptical to the wildly optimistic and even apocalyptic. I think that even if you are on the “skeptical” end of the spectrum, it makes sense to explore ways this new technology can help with your everyday work. As for my everyday work, I’ve been doing UX and product design for about 25 years now, and I’m always keen to learn new tricks and share them with colleagues. Right now, I’m interested in AI-assisted prototyping, and I’m here to share my thoughts on how it can change the process of designing digital products.

To set your expectations up front: this exploration focuses on a specific part of the product design lifecycle. Many people know about the Double Diamond framework, which shows the path from problem to solution. However, I think it’s the Triple Diamond model that makes an important point for our needs. It explicitly separates the solution space into two phases: Solution Discovery (ideating and validating the right concept) and Solution Delivery (engineering the validated concept into a final product). This article is focused squarely on that middle diamond: Solution Discovery.

How AI can help with the preceding (Problem Discovery) and the following (Solution Delivery) stages is out of the scope of this article. Problem Discovery is less about prototyping and more about research, and while I believe AI can revolutionize the research process as well, I’ll leave that to people more knowledgeable in the field. As for Solution Delivery, it is more about engineering optimization. There’s no doubt that software engineering in the AI era is undergoing dramatic changes, but I’m not an engineer — I’m a designer, so let me focus on my “sweet spot”.

And my “sweet spot” has a specific flavor: designing enterprise applications. In this world, the main challenge is taming complexity: dealing with complicated data models and guiding users through non-linear workflows. This background has had a big impact on my approach to design, putting a lot of emphasis on the underlying logic and structure. This article explores the potential of AI through this lens.

I’ll start by outlining the typical artifacts designers create during Solution Discovery. Then, I’ll examine the problems with how this part of the process often plays out in practice. Finally, we’ll explore whether AI-powered prototyping can offer a better approach, and if so, whether it aligns with what people call “vibe coding,” or calls for a more deliberate and disciplined way of working.

What We Create During Solution Discovery

The Solution Discovery phase begins with the key output from the preceding research: a well-defined problem and a core hypothesis for a solution. This is our starting point. The artifacts we create from here are all aimed at turning that initial hypothesis into a tangible, testable concept.

Traditionally, at this stage, designers can produce artifacts of different kinds, progressively increasing fidelity: from napkin sketches, boxes-and-arrows, and conceptual diagrams to hi-fi mockups, then to interactive prototypes, and in some cases even live prototypes. Artifacts of lower fidelity allow fast iteration and enable the exploration of many alternatives, while artifacts of higher fidelity help to understand, explain, and validate the concept in all its details.

It’s important to think holistically, considering different aspects of the solution. I would highlight three dimensions:

1. Conceptual model: Objects, relations, attributes, actions;
2. Visualization: Screens, from rough sketches to hi-fi mockups;
3. Flow: From the very high-level user journeys to more detailed ones.

One can argue that those are layers rather than dimensions, and each of them builds on the previous ones (for example, according to Semantic IxD by Daniel Rosenberg), but I see them more as different facets of the same thing, so the design process through them is not necessarily linear: you may need to switch from one perspective to another many times.

This is how different types of design artifacts map to these dimensions:

As Solution Discovery progresses, designers move from the left part of this map to the right, from low-fidelity to high-fidelity, from ideating to validating, from diverging to converging.

Note that at the beginning of the process, different dimensions are supported by artifacts of different types (boxes-and-arrows, sketches, class diagrams, etc.), and only closer to the end can you build a live prototype that encompasses all three dimensions: conceptual model, visualization, and flow.

This progression shows a classic trade-off, like the difference between a pencil drawing and an oil painting. The drawing lets you explore ideas in the most flexible way, whereas the painting has a lot of detail and overall looks much more realistic, but is hard to adjust. Similarly, as we go towards artifacts that integrate all three dimensions at higher fidelity, our ability to iterate quickly and explore divergent ideas goes down. This inverse relationship has long been an accepted, almost unchallenged, limitation of the design process.

The Problem With The Mockup-Centric Approach

Faced with this difficult trade-off, often teams opt for the easiest way out. On the one hand, they need to show that they are making progress and create things that appear detailed. On the other hand, they rarely can afford to build interactive or live prototypes. This leads them to over-invest in one type of artifact that seems to offer the best of both worlds. As a result, the neatly organized “bento box” of design artifacts we saw previously gets shrunk down to just one compartment: creating static high-fidelity mockups.

This choice is understandable, as several forces push designers in this direction. Stakeholders are always eager to see nice pictures, while artifacts representing user flows and conceptual models receive much less attention and priority. They are too high-level and hardly usable for validation, and usually, not everyone can understand them.

On the other side of the fidelity spectrum, interactive prototypes require too much effort to create and maintain, and creating live prototypes in code used to require special skills (and again, effort). And even when teams make this investment, they do so at the end of Solution Discovery, during the convergence stage, when it is often too late to experiment with fundamentally different ideas. With so much effort already sunk, there is little appetite to go back to the drawing board.

It’s no surprise, then, that many teams default to the perceived safety of static mockups, seeing them as a middle ground between the roughness of the sketches and the overwhelming complexity and fragility that prototypes can have.

As a result, validation with users doesn’t provide enough confidence that the solution will actually solve the problem, and teams are forced to make a leap of faith to start building. To make matters worse, they do so without a clear understanding of the conceptual model, the user flows, and the interactions, because from the very beginning, designers’ attention has been heavily skewed toward visualization.

The result is often a design artifact that resembles the famous “horse drawing” meme: beautifully rendered in the parts everyone sees first (the mockups), but dangerously underdeveloped in its underlying structure (the conceptual model and flows).

While this is a familiar problem across the industry, its severity depends on the nature of the project. If your core challenge is to optimize a well-understood, linear flow (like many B2C products), a mockup-centric approach can be perfectly adequate. The risks are contained, and the “lopsided horse” problem is unlikely to be fatal.

However, it’s different for the systems I specialize in: complex applications defined by intricate data models and non-linear, interconnected user flows. Here, the biggest risks are not on the surface but in the underlying structure, and a lack of attention to the latter would be a recipe for disaster.

Transforming The Design Process

This situation makes me wonder:

How might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one?

“

If we were able to answer this question, we would:

• Learn faster.
  By going straight from intent to a testable artifact, we cut the feedback loop from weeks to days.
• Gain more confidence.
  Users interact with real logic, which gives us more proof that the idea works.
• Enforce conceptual clarity.
  A live prototype cannot hide a flawed or ambiguous conceptual model.
• Establish a clear and lasting source of truth.
  A live prototype, combined with a clearly documented design intent, provides the engineering team with an unambiguous specification.

Of course, the desire for such a process is not new. This vision of a truly prototype-driven workflow is especially compelling for enterprise applications, where the benefits of faster learning and forced conceptual clarity are the best defense against costly structural flaws. But this ideal was still out of reach because prototyping in code took so much work and specialized talents. Now, the rise of powerful AI coding assistants changes this equation in a big way.

The Seductive Promise Of “Vibe Coding”

And the answer seems to be obvious: vibe coding!

“Vibe coding is an artificial intelligence-assisted software development style popularized by Andrej Karpathy in early 2025. It describes a fast, improvisational, collaborative approach to creating software where the developer and a large language model (LLM) tuned for coding is acting rather like pair programmers in a conversational loop.”

— Wikipedia

The original tweet by Andrej Karpathy:

The allure of this approach is undeniable. If you are not a developer, you are bound to feel awe when you describe a solution in plain language, and moments later, you can interact with it. This seems to be the ultimate fulfillment of our goal: a direct, frictionless path from an idea to a live prototype. But is this method reliable enough to build our new design process around it?

The Trap: A Process Without A Blueprint

Vibe coding mixes up a description of the UI with a description of the system itself, resulting in a prototype based on changing assumptions rather than a clear, solid model.

The pitfall of vibe coding is that it encourages us to express our intent in the most ambiguous way possible: by having a conversation.

“

This is like hiring a builder and telling them what to do one sentence at a time without ever presenting them a blueprint. They could make a wall that looks great, but you can’t be sure that it can hold weight.

I’ll give you one example illustrating problems you may face if you try to jump over the chasm between your idea and a live prototype relying on pure vibe coding in the spirit of Andrej Karpathy’s tweet. Imagine I want to prototype a solution to keep track of tests to validate product ideas. I open my vibe coding tool of choice (I intentionally don’t disclose its name, as I believe they all are awesome yet prone to similar pitfalls) and start with the following prompt:

I need an app to track tests. For every test, I need to fill out the following data:
- Hypothesis (we believe that...) 
- Experiment (to verify that, we will...)
- When (a single date, or a period) 
- Status (New/Planned/In Progress/Proven/Disproven)

And in a minute or so, I get a working prototype:

Inspired by success, I go further:

Please add the ability to specify a product idea for every test. Also, I want to filter tests by product ideas and see how many tests each product idea has in each status.

And the result is still pretty good:

But then I want to extend the functionality related to product ideas:

Okay, one more thing. For every product idea, I want to assess the impact score, the confidence score, and the ease score, and get the overall ICE score. Perhaps I need a separate page focused on the product idea, with all the relevant information and related tests.

And from this point on, the results are getting more and more confusing.

The flow of creating tests hasn’t changed much. I can still create a bunch of tests, and they seem to be organized by product ideas. But when I click “Product Ideas” in the top navigation, I see nothing:

I need to create my ideas from scratch, and they are not connected to the tests I created before:

Moreover, when I go back to “Tests”, I see that they are all gone. Clearly something went wrong, and my AI assistant confirms that:

No, this is not expected behavior — it’s a bug! The issue is that tests are being stored in two separate places (local state in the Index page and App state), so tests created on the main page don’t sync with the product ideas page.

Sure, eventually it fixed that bug, but note that we encountered this just on the third step, when we asked to slightly extend the functionality of a very simple app. The more layers of complexity we add, the more roadblocks of this sort we are bound to face.

Also note that this specific problem of a not fully thought-out relationship between two entities (product ideas and tests) is not isolated at the technical level, and therefore, it didn’t go away once the technical bug was fixed. The underlying conceptual model is still broken, and it manifests in the UI as well.

For example, you can still create “orphan” tests that are not connected to any item from the “Product Ideas” page. As a result, you may end up with different numbers of ideas and tests on different pages of the app:

Let’s diagnose what really happened here. The AI’s response that this is a “bug” is only half the story. The true root cause is a conceptual model failure. My prompts never explicitly defined the relationship between product ideas and tests. The AI was forced to guess, which led to the broken experience. For a simple demo, this might be a fixable annoyance. But for a data-heavy enterprise application, this kind of structural ambiguity is fatal. It demonstrates the fundamental weakness of building without a blueprint, which is precisely what vibe coding encourages.

Don’t take this as a criticism of vibe coding tools. They are creating real magic. However, the fundamental truth about “garbage in, garbage out” is still valid. If you don’t express your intent clearly enough, chances are the result won’t fulfill your expectations.

Another problem worth mentioning is that even if you wrestle it into a state that works, the artifact is a black box that can hardly serve as reliable specifications for the final product. The initial meaning is lost in the conversation, and all that’s left is the end result. This makes the development team “code archaeologists,” who have to figure out what the designer was thinking by reverse-engineering the AI’s code, which is frequently very complicated. Any speed gained at the start is lost right away because of this friction and uncertainty.

From Fast Magic To A Solid Foundation

Pure vibe coding, for all its allure, encourages building without a blueprint. As we’ve seen, this results in structural ambiguity, which is not acceptable when designing complex applications. We are left with a seemingly quick but fragile process that creates a black box that is difficult to iterate on and even more so to hand off.

This leads us back to our main question: how might we close the gap between our design intent and a live prototype, so that we can iterate on real functionality from day one, without getting caught in the ambiguity trap? The answer lies in a more methodical, disciplined, and therefore trustworthy process.

In Part 2 of this series, “A Practical Guide to Building with Clarity”, I will outline the entire workflow for Intent Prototyping. This method places the explicit intent of the designer at the forefront of the process while embracing the potential of AI-assisted coding.

Thank you for reading, and I look forward to seeing you in Part 2.

(yk)

Unlike timeline-based animations, which tell stories across a sequence of events, or interaction animations that are triggered when someone touches something, ambient animations are the kind of passive movements you might not notice at first. But, they make a design look alive in subtle ways.

In an ambient animation, elements might subtly transition between colours, move slowly, or gradually shift position. Elements can appear and disappear, change size, or they could rotate slowly.

Ambient animations aren’t intrusive; they don’t demand attention, aren’t distracting, and don’t interfere with what someone’s trying to achieve when they use a product or website. They can be playful, too, making someone smile when they catch sight of them. That way, ambient animations add depth to a brand’s personality.

To illustrate the concept of ambient animations, I’ve recreated the cover of a Quick Draw McGraw comic book (PDF) as a CSS/SVG animation. The comic was published by Charlton Comics in 1971, and, being printed, these characters didn’t move, making them ideal candidates to transform into ambient animations.

FYI: Original cover artist Ray Dirgo was best known for his work drawing Hanna-Barbera characters for Charlton Comics during the 1970s. Ray passed away in 2000 at the age of 92. He outlived Charlton Comics, which went out of business in 1986, and DC Comics acquired its characters.

Tip: You can view the complete ambient animation code on CodePen.

Choosing Elements To Animate

Not everything on a page or in a graphic needs to move, and part of designing an ambient animation is knowing when to stop. The trick is to pick elements that lend themselves naturally to subtle movement, rather than forcing motion into places where it doesn’t belong.

Natural Motion Cues

When I’m deciding what to animate, I look for natural motion cues and think about when something would move naturally in the real world. I ask myself: “Does this thing have weight?”, “Is it flexible?”, and “Would it move in real life?” If the answer’s “yes,” it’ll probably feel right if it moves. There are several motion cues in Ray Dirgo’s cover artwork.

For example, the peace pipe Quick Draw’s puffing on has two feathers hanging from it. They swing slightly left and right by three degrees as the pipe moves, just like real feathers would.

#quick-draw-pipe {
  animation: quick-draw-pipe-rotate 6s ease-in-out infinite alternate;
}

@keyframes quick-draw-pipe-rotate {
  0% { transform: rotate(3deg); }
  100% { transform: rotate(-3deg); }
}

#quick-draw-feather-1 {
  animation: quick-draw-feather-1-rotate 3s ease-in-out infinite alternate;
}

#quick-draw-feather-2 {
  animation: quick-draw-feather-2-rotate 3s ease-in-out infinite alternate;
}

@keyframes quick-draw-feather-1-rotate {
  0% { transform: rotate(3deg); }
  100% { transform: rotate(-3deg); }
}

@keyframes quick-draw-feather-2-rotate {
  0% { transform: rotate(-3deg); }
  100% { transform: rotate(3deg); }
}

Atmosphere, Not Action

I often choose elements or decorative details that add to the vibe but don’t fight for attention.

Ambient animations aren’t about signalling to someone where they should look; they’re about creating a mood.

“

Here, the chief slowly and subtly rises and falls as he puffs on his pipe.

#chief {
  animation: chief-rise-fall 3s ease-in-out infinite alternate;
}

@keyframes chief-group-rise-fall {
  0% { transform: translateY(0); }
  100% { transform: translateY(-20px); }
}

For added effect, the feather on his head also moves in time with his rise and fall:

#chief-feather-1 {
  animation: chief-feather-1-rotate 3s ease-in-out infinite alternate;
}

#chief-feather-2 {
  animation: chief-feather-2-rotate 3s ease-in-out infinite alternate;
}

@keyframes chief-feather-1-rotate {
  0% { transform: rotate(0deg); }
  100% { transform: rotate(-9deg); }
}

@keyframes chief-feather-2-rotate {
  0% { transform: rotate(0deg); }
  100% { transform: rotate(9deg); }
}

Playfulness And Fun

One of the things I love most about ambient animations is how they bring fun into a design. They’re an opportunity to demonstrate personality through playful details that make people smile when they notice them.

Take a closer look at the chief, and you might spot his eyebrows raising and his eyes crossing as he puffs hard on his pipe. Quick Draw’s eyebrows also bounce at what look like random intervals.

#quick-draw-eyebrow {
  animation: quick-draw-eyebrow-raise 5s ease-in-out infinite;
}

@keyframes quick-draw-eyebrow-raise {
  0%, 20%, 60%, 100% { transform: translateY(0); }
  10%, 50%, 80% { transform: translateY(-10px); }
}

Keep Hierarchy In Mind

Motion draws the eye, and even subtle movements have a visual weight. So, I reserve the most obvious animations for elements that I need to create the biggest impact.

Smoking his pipe clearly has a big effect on Quick Draw McGraw, so to demonstrate this, I wrapped his elements — including his pipe and its feathers — within a new SVG group, and then I made that wobble.

#quick-draw-group {
  animation: quick-draw-group-wobble 6s ease-in-out infinite;
}

@keyframes quick-draw-group-wobble {
  0% { transform: rotate(0deg); }
  15% { transform: rotate(2deg); }
  30% { transform: rotate(-2deg); }
  45% { transform: rotate(1deg); }
  60% { transform: rotate(-1deg); }
  75% { transform: rotate(0.5deg); }
  100% { transform: rotate(0deg); }
}

Then, to emphasise this motion, I mirrored those values to wobble his shadow:

#quick-draw-shadow {
  animation: quick-draw-shadow-wobble 6s ease-in-out infinite;
}

@keyframes quick-draw-shadow-wobble {
  0% { transform: rotate(0deg); }
  15% { transform: rotate(-2deg); }
  30% { transform: rotate(2deg); }
  45% { transform: rotate(-1deg); }
  60% { transform: rotate(1deg); }
  75% { transform: rotate(-0.5deg); }
  100% { transform: rotate(0deg); }
}

Apply Restraint

Just because something can be animated doesn’t mean it should be. When creating an ambient animation, I study the image and note the elements where subtle motion might add life. I keep in mind the questions: “What’s the story I’m telling? Where does movement help, and when might it become distracting?”

Remember, restraint isn’t just about doing less; it’s about doing the right things less often.

Layering SVGs For Export

In “Smashing Animations Part 4: Optimising SVGs,” I wrote about the process I rely on to “prepare, optimise, and structure SVGs for animation.” When elements are crammed into a single SVG file, they can be a nightmare to navigate. Locating a specific path or group can feel like searching for a needle in a haystack.

That’s why I develop my SVGs in layers, exporting and optimising one set of elements at a time — always in the order they’ll appear in the final file. This lets me build the master SVG gradually by pasting it in each cleaned-up section.

I start by exporting background elements, optimising them, adding class and ID attributes, and pasting their code into my SVG file.

Then, I export elements that often stay static or move as groups, like the chief and Quick Draw McGraw.

Before finally exporting, naming, and adding details, like Quick Draw’s pipe, eyes, and his stoned sparkles.

Since I export each layer from the same-sized artboard, I don’t need to worry about alignment or positioning issues as they all slot into place automatically.

Implementing Ambient Animations

You don’t need an animation framework or library to add ambient animations to a project. Most of the time, all you’ll need is a well-prepared SVG and some thoughtful CSS.

But, let’s start with the SVG. The key is to group elements logically and give them meaningful class or ID attributes, which act as animation hooks in the CSS. For this animation, I gave every moving part its own identifier like #quick-draw-tail or #chief-smoke-2. That way, I could target exactly what I needed without digging through the DOM like a raccoon in a trash can.

Once the SVG is set up, CSS does most of the work. I can use @keyframes for more expressive movement, or animation-delay to simulate randomness and stagger timings. The trick is to keep everything subtle and remember I’m not animating for attention, I’m animating for atmosphere.

Remember that most ambient animations loop continuously, so they should be lightweight and performance-friendly. And of course, it’s good practice to respect users who’ve asked for less motion. You can wrap your animations in an @media prefers-reduced-motion query so they only run when they’re welcome.

@media (prefers-reduced-motion: no-preference) {
  #quick-draw-shadow {
    animation: quick-draw-shadow-wobble 6s ease-in-out infinite;
  }
}

It’s a small touch that’s easy to implement, and it makes your designs more inclusive.

Ambient Animation Design Principles

If you want your animations to feel ambient, more like atmosphere than action, it helps to follow a few principles. These aren’t hard and fast rules, but rather things I’ve learned while animating smoke, sparkles, eyeballs, and eyebrows.

Keep Animations Slow And Smooth

Ambient animations should feel relaxed, so use longer durations and choose easing curves that feel organic. I often use ease-in-out, but cubic Bézier curves can also be helpful when you want a more relaxed feel and the kind of movements you might find in nature.

Loop Seamlessly And Avoid Abrupt Changes

Hard resets or sudden jumps can ruin the mood, so if an animation loops, ensure it cycles smoothly. You can do this by matching start and end keyframes, or by setting the animation-direction to alternate the value so the animation plays forward, then back.

Use Layering To Build Complexity

A single animation might be boring. Five subtle animations, each on separate layers, can feel rich and alive. Think of it like building a sound mix — you want variation in rhythm, tone, and timing. In my animation, sparkles twinkle at varying intervals, smoke curls upward, feathers sway, and eyes boggle. Nothing dominates, and each motion plays its small part in the scene.

Avoid Distractions

The point of an ambient animation is that it doesn’t dominate. It’s a background element and not a call to action. If someone’s eyes are drawn to a raised eyebrow, it’s probably too much, so dial back the animation until it feels like something you’d only catch if you’re really looking.

Consider Accessibility And Performance

Check prefers-reduced-motion, and don’t assume everyone’s device can handle complex animations. SVG and CSS are light, but things like blur filters and drop shadows, and complex CSS animations can still tax lower-powered devices. When an animation is purely decorative, consider adding aria-hidden="true" to keep it from cluttering up the accessibility tree.

Quick On The Draw

Ambient animation is like seasoning on a great dish. It’s the pinch of salt you barely notice, but you’d miss when it’s gone. It doesn’t shout, it whispers. It doesn’t lead, it lingers. It’s floating smoke, swaying feathers, and sparkles you catch in the corner of your eye. And when it’s done well, ambient animation adds personality to a design without asking for applause.

Now, I realise that not everyone needs to animate cartoon characters. So, in part two, I’ll share how I created animations for several recent client projects. Until next time, if you’re crafting an illustration or working with SVG, ask yourself: What would move if this were real? Then animate just that. Make it slow and soft. Keep it ambient.

You can view the complete ambient animation code on CodePen.

(gg, yk)

Misuse and misplaced trust of AI is becoming an unfortunate common event. For example, lawyers trying to leverage the power of generative AI for research submit court filings citing multiple compelling legal precedents. The problem? The AI had confidently, eloquently, and completely fabricated the cases cited. The resulting sanctions and public embarrassment can become a viral cautionary tale, shared across social media as a stark example of AI’s fallibility.

This goes beyond a technical glitch; it’s a catastrophic failure of trust in AI tools in an industry where accuracy and trust are critical. The trust issue here is twofold — the law firms are submitting briefs in which they have blindly over-trusted the AI tool to return accurate information. The subsequent fallout can lead to a strong distrust in AI tools, to the point where platforms featuring AI might not be considered for use until trust is reestablished.

Issues with trusting AI aren’t limited to the legal field. We are seeing the impact of fictional AI-generated information in critical fields such as healthcare and education. On a more personal scale, many of us have had the experience of asking Siri or Alexa to perform a task, only to have it done incorrectly or not at all, for no apparent reason. I’m guilty of sending more than one out-of-context hands-free text to an unsuspecting contact after Siri mistakenly pulls up a completely different name than the one I’d requested.

With digital products moving to incorporate generative and agentic AI at an increasingly frequent rate, trust has become the invisible user interface. When it works, our interactions are seamless and powerful. When it breaks, the entire experience collapses, with potentially devastating consequences. As UX professionals, we’re on the front lines of a new twist on a common challenge. How do we build products that users can rely on? And how do we even begin to measure something as ephemeral as trust in AI?

Trust isn’t a mystical quality. It is a psychological construct built on predictable factors. I won’t dive deep into academic literature on trust in this article. However, it is important to understand that trust is a concept that can be understood, measured, and designed for. This article will provide a practical guide for UX researchers and designers. We will briefly explore the psychological anatomy of trust, offer concrete methods for measuring it, and provide actionable strategies for designing more trustworthy and ethical AI systems.

The Anatomy of Trust: A Psychological Framework for AI

To build trust, we must first understand its components. Think of trust like a four-legged stool. If any one leg is weak, the whole thing becomes unstable. Based on classic psychological models, we can adapt these “legs” for the AI context.

1. Ability (or Competence)

This is the most straightforward pillar: Does the AI have the skills to perform its function accurately and effectively? If a weather app is consistently wrong, you stop trusting it. If an AI legal assistant creates fictitious cases, it has failed the basic test of ability. This is the functional, foundational layer of trust.

2. Benevolence

This moves from function to intent. Does the user believe the AI is acting in their best interest? A GPS that suggests a toll-free route even if it’s a few minutes longer might be perceived as benevolent. Conversely, an AI that aggressively pushes sponsored products feels self-serving, eroding this sense of benevolence. This is where user fears, such as concerns about job displacement, directly challenge trust—the user starts to believe the AI is not on their side.

3. Integrity

Does AI operate on predictable and ethical principles? This is about transparency, fairness, and honesty. An AI that clearly states how it uses personal data demonstrates integrity. A system that quietly changes its terms of service or uses dark patterns to get users to agree to something violates integrity. An AI job recruiting tool that has subtle yet extremely harmful social biases, existing in the algorithm, violates integrity.

4. Predictability & Reliability

Can the user form a stable and accurate mental model of how the AI will behave? Unpredictability, even if the outcomes are occasionally good, creates anxiety. A user needs to know, roughly, what to expect. An AI that gives a radically different answer to the same question asked twice is unpredictable and, therefore, hard to trust.

The Trust Spectrum: The Goal of a Well-Calibrated Relationship

Our goal as UX professionals shouldn’t be to maximize trust at all costs. An employee who blindly trusts every email they receive is a security risk. Likewise, a user who blindly trusts every AI output can be led into dangerous situations, such as the legal briefs referenced at the beginning of this article. The goal is well-calibrated trust.

Think of it as a spectrum where the upper-mid level is the ideal state for a truly trustworthy product to achieve:

• Active Distrust
  The user believes the AI is incompetent or malicious. They will avoid it or actively work against it.
• Suspicion & Scrutiny
  The user interacts cautiously, constantly verifying the AI’s outputs. This is a common and often healthy state for users of new AI.
• Calibrated Trust (The Ideal State)
  This is the sweet spot. The user has an accurate understanding of the AI’s capabilities—its strengths and, crucially, its weaknesses. They know when to rely on it and when to be skeptical.
• Over-trust & Automation Bias
  The user unquestioningly accepts the AI’s outputs. This is where users follow flawed AI navigation into a field or accept a fictional legal brief as fact.

Our job is to design experiences that guide users away from the dangerous poles of Active Distrust and Over-trust and toward that healthy, realistic middle ground of Calibrated Trust.

“

The Researcher’s Toolkit: How to Measure Trust In AI

Trust feels abstract, but it leaves measurable fingerprints. Academics in the social sciences have done much to define both what trust looks like and how it might be measured. As researchers, we can capture these signals through a mix of qualitative, quantitative, and behavioral methods.

Qualitative Probes: Listening For The Language Of Trust

During interviews and usability tests, go beyond “Was that easy to use?” and listen for the underlying psychology. Here are some questions you can start using tomorrow:

• To measure Ability:
  “Tell me about a time this tool’s performance surprised you, either positively or negatively.”
• To measure Benevolence:
  “Do you feel this system is on your side? What gives you that impression?”
• To measure Integrity:
  “If this AI made a mistake, how would you expect it to handle it? What would be a fair response?”
• To measure Predictability:
  “Before you clicked that button, what did you expect the AI to do? How closely did it match your expectation?”

Investigating Existential Fears (The Job Displacement Scenario)

One of the most potent challenges to an AI’s Benevolence is the fear of job displacement. When a participant expresses this, it is a critical research finding. It requires a specific, ethical probing technique.

Imagine a participant says, “Wow, it does that part of my job pretty well. I guess I should be worried.”

An untrained researcher might get defensive or dismiss the comment. An ethical, trained researcher validates and explores:

“Thank you for sharing that; it’s a vital perspective, and it’s exactly the kind of feedback we need to hear. Can you tell me more about what aspects of this tool make you feel that way? In an ideal world, how would a tool like this work with you to make your job better, not to replace it?”

This approach respects the participant, validates their concern, and reframes the feedback into an actionable insight about designing a collaborative, augmenting tool rather than a replacement. Similarly, your findings should reflect the concern users expressed about replacement. We shouldn’t pretend this fear doesn’t exist, nor should we pretend that every AI feature is being implemented with pure intention. Users know better than that, and we should be prepared to argue on their behalf for how the technology might best co-exist within their roles.

Quantitative Measures: Putting A Number On Confidence

You can quantify trust without needing a data science degree. After a user completes a task with an AI, supplement your standard usability questions with a few simple Likert-scale items:

• “The AI’s suggestion was reliable.” (1-7, Strongly Disagree to Strongly Agree)
• “I am confident in the AI’s output.” (1-7)
• “I understood why the AI made that recommendation.” (1-7)
• “The AI responded in a way that I expected.” (1-7)
• “The AI provided consistent responses over time.” (1-7)

Over time, these metrics can track how trust is changing as your product evolves.

Note: If you want to go beyond these simple questions that I’ve made up, there are numerous scales (measurements) of trust in technology that exist in academic literature. It might be an interesting endeavor to measure some relevant psychographic and demographic characteristics of your users and see how that correlates with trust in AI/your product. Table 1 at the end of the article contains four examples of current scales you might consider using to measure trust. You can decide which is best for your application, or you might pull some of the items from any of the scales if you aren’t looking to publish your findings in an academic journal, yet want to use items that have been subjected to some level of empirical scrutiny.

Behavioral Metrics: Observing What Users Do, Not Just What They Say

People’s true feelings are often revealed in their actions. You can use behaviors that reflect the specific context of use for your product. Here are a few general metrics that might apply to most AI tools that give insight into users’ behavior and the trust they place in your tool.

• Correction Rate
  How often do users manually edit, undo, or ignore the AI’s output? A high correction rate is a powerful signal of low trust in its Ability.
• Verification Behavior
  Do users switch to Google or open another application to double-check the AI’s work? This indicates they don’t trust it as a standalone source of truth. It can also potentially be positive that they are calibrating their trust in the system when they use it up front.
• Disengagement
  Do users turn the AI feature off? Do they stop using it entirely after one bad experience? This is the ultimate behavioral vote of no confidence.

Designing For Trust: From Principles to Pixels

Once you’ve researched and measured trust, you can begin to design for it. This means translating psychological principles into tangible interface elements and user flows.

Designing for Competence and Predictability

• Set Clear Expectations
  Use onboarding, tooltips, and empty states to honestly communicate what the AI is good at and where it might struggle. A simple “I’m still learning about [topic X], so please double-check my answers” can work wonders.
• Show Confidence Levels
  Instead of just giving an answer, have the AI signal its own uncertainty. A weather app that says “70% chance of rain” is more trustworthy than one that just says “It will rain” and is wrong. An AI could say, “I’m 85% confident in this summary,” or highlight sentences it’s less sure about.

The Role of Explainability (XAI) and Transparency

Explainability isn’t about showing users the code. It’s about providing a useful, human-understandable rationale for a decision.

Instead of:
“Here is your recommendation.”

Try:
“Because you frequently read articles about UX research methods, I’m recommending this new piece on measuring trust in AI.”

This addition transforms AI from an opaque oracle to a transparent logical partner.

Many of the popular AI tools (e.g., ChatGPT and Gemini) show the thinking that went into the response they provide to a user. Figure 3 shows the steps Gemini went through to provide me with a non-response when I asked it to help me generate the masterpiece displayed above in Figure 2. While this might be more information than most users care to see, it provides a useful resource for a user to audit how the response came to be, and it has provided me with instructions on how I might proceed to address my task.

Figure 4 shows an example of a scorecard OpenAI makes available as an attempt to increase users’ trust. These scorecards are available for each ChatGPT model and go into the specifics of how the models perform as it relates to key areas such as hallucinations, health-based conversations, and much more. In reading the scorecards closely, you will see that no AI model is perfect in any area. The user must remain in a trust but verify mode to make the relationship between human reality and AI work in a way that avoids potential catastrophe. There should never be blind trust in an LLM.

Designing For Trust Repair (Graceful Error Handling) And Not Knowing an Answer

Your AI will make mistakes.

Trust is not determined by the absence of errors, but by how those errors are handled.

• Acknowledge Errors Humbly.
  When the AI is wrong, it should be able to state that clearly. “My apologies, I misunderstood that request. Could you please rephrase it?” is far better than silence or a nonsensical answer.
• Provide an Easy Path to Correction.
  Make feedback mechanisms (like thumbs up/down or a correction box) obvious. More importantly, show that the feedback is being used. A “Thank you, I’m learning from your correction” can help rebuild trust after a failure. As long as this is true.

Likewise, your AI can’t know everything. You should acknowledge this to your users.

UX practitioners should work with the product team to ensure that honesty about limitations is a core product principle.

“

This can include the following:

• Establish User-Centric Metrics: Instead of only measuring engagement or task completion, UXers can work with product managers to define and track metrics like:
  • Hallucination Rate: The frequency with which the AI provides verifiably false information.
  • Successful Fallback Rate: How often the AI correctly identifies its inability to answer and provides a helpful, honest alternative.
• Prioritize the “I Don’t Know” Experience: UXers should frame the “I don’t know” response not as an error state, but as a critical feature. They must lobby for the engineering and content resources needed to design a high-quality, helpful fallback experience.

UX Writing And Trust

All of these considerations highlight the critical role of UX writing in the development of trustworthy AI. UX writers are the architects of the AI’s voice and tone, ensuring that its communication is clear, honest, and empathetic. They translate complex technical processes into user-friendly explanations, craft helpful error messages, and design conversational flows that build confidence and rapport. Without thoughtful UX writing, even the most technologically advanced AI can feel opaque and untrustworthy.

The words and phrases an AI uses are its primary interface with users. UX writers are uniquely positioned to shape this interaction, ensuring that every tooltip, prompt, and response contributes to a positive and trust-building experience. Their expertise in human-centered language and design is indispensable for creating AI systems that not only perform well but also earn and maintain the trust of their users.

A few key areas for UX writers to focus on when writing for AI include:

• Prioritize Transparency
  Clearly communicate the AI’s capabilities and limitations, especially when it’s still learning or if its responses are generated rather than factual. Use phrases that indicate the AI’s nature, such as “As an AI, I can…” or “This is a generated response.”
• Design for Explainability
  When the AI provides a recommendation, decision, or complex output, strive to explain the reasoning behind it in an understandable way. This builds trust by showing the user how the AI arrived at its conclusion.
• Emphasize User Control
  Empower users by providing clear ways to provide feedback, correct errors, or opt out of certain AI features. This reinforces the idea that the user is in control and the AI is a tool to assist them.

The Ethical Tightrope: The Researcher’s Responsibility

As the people responsible for understanding and advocating for users, we walk an ethical tightrope. Our work comes with profound responsibilities.

The Danger Of “Trustwashing”

We must draw a hard line between designing for calibrated trust and designing to manipulate users into trusting a flawed, biased, or harmful system. For example, if an AI system designed for loan approvals consistently discriminates against certain demographics but presents a user interface that implies fairness and transparency, this would be an instance of trustwashing.

Another example of trustwashing would be if an AI medical diagnostic tool occasionally misdiagnoses conditions, but the user interface makes it seem infallible. To avoid trustwashing, the system should clearly communicate the potential for error and the need for human oversight.

Our goal must be to create genuinely trustworthy systems, not just the perception of trust. Using these principles to lull users into a false sense of security is a betrayal of our professional ethics.

To avoid and prevent trustwashing, researchers and UX teams should:

• Prioritize genuine transparency.
  Clearly communicate the limitations, biases, and uncertainties of AI systems. Don’t overstate capabilities or obscure potential risks.
• Conduct rigorous, independent evaluations.
  Go beyond internal testing and seek external validation of system performance, fairness, and robustness.
• Engage with diverse stakeholders.
  Involve users, ethics experts, and impacted communities in the design, development, and evaluation processes to identify potential harms and build genuine trust.
• Be accountable for outcomes.
  Take responsibility for the societal impact of AI systems, even if unintended. Establish mechanisms for redress and continuous improvement.
• Be accountable for outcomes.
  Establish clear and accessible mechanisms for redress when harm occurs, ensuring that individuals and communities affected by AI decisions have avenues for recourse and compensation.
• Educate the public.
  Help users understand how AI works, its limitations, and what to look for when evaluating AI products.
• Advocate for ethical guidelines and regulations.
  Support the development and implementation of industry standards and policies that promote responsible AI development and prevent deceptive practices.
• Be wary of marketing hype.
  Critically assess claims made about AI systems, especially those that emphasize “trustworthiness” without clear evidence or detailed explanations.
• Publish negative findings.
  Don’t shy away from reporting challenges, failures, or ethical dilemmas encountered during research. Transparency about limitations is crucial for building long-term trust.
• Focus on user empowerment.
  Design systems that give users control, agency, and understanding rather than just passively accepting AI outputs.

The Duty To Advocate

When our research uncovers deep-seated distrust or potential harm — like the fear of job displacement — our job has only just begun. We have an ethical duty to advocate for that user. In my experience directing research teams, I’ve seen that the hardest part of our job is often carrying these uncomfortable truths into rooms where decisions are made. We must champion these findings and advocate for design and strategy shifts that prioritize user well-being, even when it challenges the product roadmap.

I personally try to approach presenting this information as an opportunity for growth and improvement, rather than a negative challenge.

For example, instead of stating “Users don’t trust our AI because they fear job displacement,” I might frame it as “Addressing user concerns about job displacement presents a significant opportunity to build deeper trust and long-term loyalty by demonstrating our commitment to responsible AI development and exploring features that enhance human capabilities rather than replace them.” This reframing can shift the conversation from a defensive posture to a proactive, problem-solving mindset, encouraging collaboration and innovative solutions that ultimately benefit both the user and the business.

It’s no secret that one of the more appealing areas for businesses to use AI is in workforce reduction. In reality, there will be many cases where businesses look to cut 10–20% of a particular job family due to the perceived efficiency gains of AI. However, giving users the opportunity to shape the product may steer it in a direction that makes them feel safer than if they do not provide feedback. We should not attempt to convince users they are wrong if they are distrustful of AI. We should appreciate that they are willing to provide feedback, creating an experience that is informed by the human experts who have long been doing the task being automated.

Conclusion: Building Our Digital Future On A Foundation Of Trust

The rise of AI is not the first major technological shift our field has faced. However, it presents one of the most significant psychological challenges of our current time. Building products that are not just usable but also responsible, humane, and trustworthy is our obligation as UX professionals.

Trust is not a soft metric. It is the fundamental currency of any successful human-technology relationship. By understanding its psychological roots, measuring it with rigor, and designing for it with intent and integrity, we can move from creating “intelligent” products to building a future where users can place their confidence in the tools they use every day. A trust that is earned and deserved.

Table 1: Published Academic Scales Measuring Trust In Automated Systems

Appendix A: Trust-Building Tactics Checklist

To design for calibrated trust, consider implementing the following tactics, organized by the four pillars of trust:

1. Ability (Competence) & Predictability

• ✅ Set Clear Expectations: Use onboarding, tooltips, and empty states to honestly communicate the AI’s strengths and weaknesses.
• ✅ Show Confidence Levels: Display the AI’s uncertainty (e.g., “70% chance,” “85% confident”) or highlight less certain parts of its output.
• ✅ Provide Explainability (XAI): Offer useful, human-understandable rationales for the AI’s decisions or recommendations (e.g., “Because you frequently read X, I’m recommending Y”).
• ✅ Design for Graceful Error Handling:
  • ✅ Acknowledge errors humbly (e.g., “My apologies, I misunderstood that request.”).
  • ✅ Provide easy paths to correction (e. ] g., prominent feedback mechanisms like thumbs up/down).
  • ✅ Show that feedback is being used (e.g., “Thank you, I’m learning from your correction”).
• ✅ Design for “I Don’t Know” Responses:
  • ✅ Acknowledge limitations honestly.
  • ✅ Prioritize a high-quality, helpful fallback experience when the AI cannot answer.
• ✅ Prioritize Transparency: Clearly communicate the AI’s capabilities and limitations, especially if responses are generated.

2. Benevolence

• ✅ Address Existential Fears: When users express concerns (e.g., job displacement), validate their concerns and reframe the feedback into actionable insights about collaborative tools.
• ✅ Prioritize User Well-being: Advocate for design and strategy shifts that prioritize user well-being, even if it challenges the product roadmap.
• ✅ Emphasize User Control: Provide clear ways for users to give feedback, correct errors, or opt out of AI features.

3. Integrity

• ✅ Adhere to Ethical Principles: Ensure the AI operates on predictable, ethical principles, demonstrating fairness and honesty.
• ✅ Prioritize Genuine Transparency: Clearly communicate the limitations, biases, and uncertainties of AI systems; avoid overstating capabilities or obscuring risks.
• ✅ Conduct Rigorous, Independent Evaluations: Seek external validation of system performance, fairness, and robustness to mitigate bias.
• ✅ Engage Diverse Stakeholders: Involve users, ethics experts, and impacted communities in the design and evaluation processes.
• ✅ Be Accountable for Outcomes: Establish clear mechanisms for redress and continuous improvement for societal impacts, even if unintended.
• ✅ Educate the Public: Help users understand how AI works, its limitations, and how to evaluate AI products.
• ✅ Advocate for Ethical Guidelines: Support the development and implementation of industry standards and policies that promote responsible AI.
• ✅ Be Wary of Marketing Hype: Critically assess claims about AI “trustworthiness” and demand verifiable data.
• ✅ Publish Negative Findings: Be transparent about challenges, failures, or ethical dilemmas encountered during research.

4. Predictability & Reliability

• ✅ Set Clear Expectations: Use onboarding, tooltips, and empty states to honestly communicate what the AI is good at and where it might struggle.
• ✅ Show Confidence Levels: Instead of just giving an answer, have the AI signal its own uncertainty.
• ✅ Provide Explainability (XAI) and Transparency: Offer a useful, human-understandable rationale for AI decisions.
• ✅ Design for Graceful Error Handling: Acknowledge errors humbly and provide easy paths to correction.
• ✅ Prioritize the “I Don’t Know” Experience: Frame “I don’t know” as a feature and design a high-quality fallback experience.
• ✅ Prioritize Transparency (UX Writing): Clearly communicate the AI’s capabilities and limitations, especially when it’s still learning or if responses are generated.
• ✅ Design for Explainability (UX Writing): Explain the reasoning behind AI recommendations, decisions, or complex outputs.

(yk)

This article is sponsored by Expressive

In the world of modern web design, SVG images are used everywhere, from illustrations to icons to background effects, and are universally prized for their crispness and lightweight size. While static SVG images play an important role in web design, most of the time their true potential is unlocked only when they are combined with motion.

Few things add more life and personality to a website than a well-executed SVG animation. But not all animations have the same impact in terms of digital experience. For example, elastic and bounce effects have a unique appeal in motion design because they bring a sense of realism into movement, making animations more engaging and memorable.

However, anyone who has dived into animating SVGs knows the technical hurdles involved. Creating a convincing elastic or bounce effect traditionally requires handling complex CSS keyframes or wrestling with JavaScript animation libraries. Even when using an SVG animation editor, it will most likely require you to manually add the keyframes and adjust the easing functions between them, which can become a time-consuming process of trial and error, no matter the level of experience you have.

This is where Expressive Animator shines. It allows creators to apply elastic and bounce effects in seconds, bypassing the tedious work of manual keyframe editing. And the result is always exceptional: animations that feel alive, produced with a fraction of the effort.

Using Expressive Animator To Create An Elastic Effect

Creating an elastic effect in Expressive Animator is remarkably simple, fast, and intuitive, since the effect is built right into the software as an easing function. This means you only need two keyframes (start and end) to make the effect, and the software will automatically handle the springy motion in between. Even better, the elastic easing can be applied to any animatable property (e.g., position, scale, rotation, opacity, morph, etc.), giving you a consistent way to add it to your animations.

Before we dive into the tutorial, take a look at the video below to see what you will learn to create and the entire process from start to finish.

First things first, let’s set the scene. For this, we’ll create a new project by pressing Ctrl/Cmd + P and configuring it in the “Create New Project” dialog that pops up. For frame size, we’ll choose 1080×1080, for a duration of 00:01:30, and we’ll let the frame rate remain unchanged at 60 frames per second (fps).

Once you hit the “Create project” button, you can use the Pen and Ellipse tools to create the artwork that will be animated, or you can simply copy and paste the artwork below.

Now that everything has been set up, let’s create the animation. Make sure that snapping and auto-record are enabled, then move the playhead to 01:00f. By enabling snapping, you will be able to perfectly align nodes and graphic objects on the canvas. On the other hand, as the name suggests, auto-record tracks every change you make to the artwork and adds the appropriate keyframes on the timeline.

Press the A key on your keyboard to switch to the Node tool, then select the String object and move its handle to the center-right point of the artboard. Don’t worry about precision, as the snapping will do all the heavy lifting for you. This will bend the shape and add keyframes for the Morph animator.

Next, press the V key on your keyboard to switch to the Selection tool. With this tool enabled, select the Ball, move it to the right, and place it in the middle of the string. Once again, snapping will do all the hard work, allowing you to position the ball exactly where you want to, while auto-recording automatically adds the appropriate keyframes.

You can now replay the animation and disable auto-recording by clicking on the Auto-Record button again.

As you can see when replaying, the direction in which the String and Ball objects are moving is wrong. Fortunately, we can fix this extremely easily just by reversing the keyframes. To do this, select the keyframes in the timeline and right-click to open the context menu and choose Reverse. This will reverse the keyframes, and if you replay the animation, you will see that the direction is now correct.

With this out of the way, we can finally add the elastic effect. Select all the keyframes in the timeline and click on the Custom easing button to open a dialog with easing options. From the dialog, choose Elastic and set the oscillations to 4 and the stiffness to 2.5.

That’s it! Click anywhere outside the easing dialog to close it and replay the animation to see the result.

The animation can be exported as well. Press Cmd/Ctrl + E on your keyboard to open the export dialog and choose from various export options, ranging from vectorized formats, such as SVG and Lottie, to rasterized formats, such as GIF and video.

For this specific animation, we’re going to choose the SVG export format. Expressive Animator allows you to choose between three different types of SVG, depending on the technology used for animation: SMIL, CSS, or JavaScript.

Each of these technologies has different strengths and weaknesses, but for this tutorial, we are going to choose SMIL. This is because SMIL-based animations are widely supported, even on Safari browsers, and can be used as background images or embedded in HTML pages using the <img> tag. In fact, Andy Clarke recently wrote all about SMIL animations here at Smashing Magazine if you want a full explanation of how it works.

You can visualize the exported SVG in the following CodePen demo:

Expressive Animator For Bounce And Other Effects

Adding a bounce effect to an animation is very similar to the process we just covered for creating an elastic effect, since both are built into Expressive Animator as easing functions. Just like elastic, bounce easing can be applied to any animatable property, giving you quick ways to create realistic motion.

Beyond these two effects, Expressive Animator also offers other easing options that can shape the personality of your animation, like Back, Steps, Sinc, just to name a few.

Conclusion

Elastic and bounce effects have long been among the most desirable but time-consuming techniques in motion design. By integrating them directly into its easing functions, Expressive Animator removes the complexity of manual keyframe manipulation and transforms what used to be a technical challenge into a creative opportunity.

The best part is that getting started with Expressive Animator comes with zero risk. The software offers a full 7–day free trial without requiring an account, so you can download it instantly and begin experimenting with your own designs right away. After the trial ends, you can buy Expressive Animator with a one-time payment, no subscription required. This will give you a perpetual license covering both Windows and macOS.

To help you get started even faster, I’ve prepared some extra resources for you. You’ll find the source files for the animations created in this tutorial, along with a curated list of useful links that will guide you further in exploring Expressive Animator and SVG animation. These materials are meant to give you a solid starting point so you can learn, experiment, and build on your own with confidence.

• Grumpy Egg: The .eaf source file for the sample animation presented at the beginning of this article.
• Elastic Effect: Another .eaf file, this time for the animation we made in this tutorial.
• Get started with Expressive Animator
• Expressive Animator Documentation

(gg, yk)

I once worked with a fleet operations team that monitored dozens of vehicles in multiple cities. Their dashboard showed fuel consumption, live GPS locations, and real-time driver updates. Yet the team struggled to see what needed urgent attention. The problem was not a lack of data but a lack of clear indicators to support decision-making. There were no priorities, alerts, or context to highlight what mattered most at any moment.

Real-time dashboards are now critical decision-making tools in industries like logistics, manufacturing, finance, and healthcare. However, many of them fail to help users make timely and confident decisions, even when they show live data.

Designing for real-time use is very different from designing static dashboards. The challenge is not only presenting metrics but enabling decisions under pressure. Real-time users face limited time and a high cognitive load. They need clarity on actions, not just access to raw data.

This requires interface elements that support quick scanning, pattern recognition, and guided attention. Layout hierarchy, alert colors, grouping, and motion cues all help, but they must be driven by a deeper strategy: understanding what the user must decide in that moment.

This article explores practical UX strategies for real-time dashboards that enable real decisions. Instead of focusing only on visual best practices, it looks at how user intent, personalization, and cognitive flow can turn raw data into meaningful, timely insights.

Designing for Real-Time Comprehension: Helping Users Stay Focused Under Pressure

A GPS app not only shows users their location but also helps them decide where to go next. In the same way, a real-time dashboard should go beyond displaying the latest data. Its purpose is to help users quickly understand complex information and make informed decisions, especially in fast-paced environments with short attention spans.

How Users Process Real-Time Updates

Humans have limited cognitive capacity, so they can only process a small amount of data at once. Without proper context or visual cues, rapidly updating dashboards can overwhelm users and shift attention away from key information.

To address this, I use the following approaches:

• Delta Indicators and Trend Sparklines
  Delta indicators show value changes at a glance, while sparklines are small line charts that reveal trends over time in a compact space. For example, a sales dashboard might show a green upward arrow next to revenue to indicate growth, along with a sparkline displaying sales trends over the past week.
• Subtle Micro-Animations
  Small animations highlight changes without distracting users. Research in cognitive psychology shows that such animations effectively draw attention, helping users notice updates while staying focused. For instance, a soft pulse around a changing metric can signal activity without overwhelming the viewer.
• Mini-History Views
  Showing a short history of recent changes reduces reliance on memory. For example, a dashboard might let users scroll back a few minutes to review updates, supporting better understanding and verification of data trends.
  

Common Challenges In Real-Time Dashboards

Many live dashboards fail when treated as static reports instead of dynamic tools for quick decision-making.

In my early projects, I made this mistake, resulting in cluttered layouts, distractions, and frustrated users.

Typical errors include the following:

• Overcrowded Interfaces: Presenting too many metrics competes for users’ attention, making it hard to focus.
• Flat Visual Hierarchy: Without clear emphasis on critical data, users might focus on less important information.
• No Record of Changes: When numbers update instantly with no explanation, users can feel lost or confused.
• Excessive Refresh Rates: Not all data needs constant updates. Updating too frequently can create unnecessary motion and cognitive strain.

Managing Stress And Cognitive Overload

Under stress, users depend on intuition and focus only on immediately relevant information. If a dashboard updates too quickly or shows conflicting alerts, users may delay actions or make mistakes. It is important to:

• Prioritize the most important data first to avoid overwhelming the user.
• Offer snapshot or pause options so users can take time to process information.
• Use clear indicators to show if an action is required or if everything is operating normally.

In real-time environments, the best dashboards balance speed with calmness and clarity. They are not just data displays but tools that promote live thinking and better decisions.

“

Enabling Personalization For Effective Data Consumption

Many analytics tools let users build custom dashboards, but these design principles guide layouts that support decision-making. Personalization options such as custom metric selection, alert preferences, and update pacing help manage cognitive load and improve data interpretation.

Common Cognitive Challenges in Real-Time Dashboards and UX Strategies to Overcome Them.

Designing For Focus: Using Layout, Color, And Animation To Drive Real-Time Decisions

Layout, color, and animation do more than improve appearance. They help users interpret live data quickly and make decisions under time pressure. Since users respond to rapidly changing information, these elements must reduce cognitive load and highlight key insights immediately.

• Creating a Visual Hierarchy to Guide Attention.
  A clear hierarchy directs users’ eyes to key metrics. Arrange elements so the most important data stands out. For example, place critical figures like sales volume or system health in the upper left corner to match common scanning patterns. Limit visible elements to about five to prevent overload and ease processing—group related data into cards to improve scannability and help users focus without distraction.
• Using Color Purposefully to Convey Meaning.
  Color communicates meaning in data visualization. Red or orange indicates critical alerts or negative trends, signaling urgency. Blue and green represent positive or stable states, offering reassurance. Neutral tones like gray support background data and make key colors stand out. Ensure accessibility with strong contrast and pair colors with icons or labels. For example, bright red can highlight outages while muted gray marks historical logs, keeping attention on urgent issues.
• Supporting Comprehension with Subtle Animation.
  Animation should clarify, not distract. Smooth transitions of 200 to 400 milliseconds communicate changes effectively. For instance, upward motion in a line chart reinforces growth. Hover effects and quick animations provide feedback and improve interaction. Thoughtful motion makes changes noticeable while maintaining focus.

Layout, color, and animation create an experience that enables fast, accurate interpretation of live data. Real-time dashboards support continuous monitoring and decision-making by reducing mental effort and highlighting anomalies or trends. Personalization allows users to tailor dashboards to their roles, improving relevance and efficiency. For example, operations managers may focus on system health metrics while sales directors prioritize revenue KPIs. This adaptability makes dashboards dynamic, strategic tools.

Design Elements, Placement, Color, and Motion Strategies for Effective Real-Time Dashboards.

Clarity In Motion: Designing Dashboards That Make Change Understandable

If users cannot interpret changes quickly, the dashboard fails regardless of its visual design. Over time, I have developed methods that reduce confusion and make change feel intuitive rather than overwhelming.

One of the most effective tools I use is the sparkline, a compact line chart that shows a trend over time and is typically placed next to a key performance indicator. Unlike full charts, sparklines omit axes and labels. Their simplicity makes them powerful, since they instantly show whether a metric is trending up, down, or steady. For example, placing a sparkline next to monthly revenue immediately reveals if performance is improving or declining, even before the viewer interprets the number.

When using sparklines effectively, follow these principles:

• Pair sparklines with metrics such as revenue, churn rate, or user activity so users can see both the value and its trajectory at a glance.
• Simplify by removing clutter like axis lines or legends unless they add real value.
• Highlight the latest data point with a dot or accent color since current performance often matters more than historical context.
• Limit the time span. Too many data points compress the sparkline and hurt readability. A focused window, such as the last 7 or 30 days, keeps the trend clear.
• Use sparklines in comparative tables. When placed in rows (for example, across product lines or regions), they reveal anomalies or emerging patterns that static numbers may hide.

I combine sparklines with directional indicators like arrows and percentage deltas to support quick interpretation.

For example, pairing “▲ +3.2%” with a rising sparkline shows both the direction and scale of change. I do not rely only on color to convey meaning.

Since 1 in 12 men is color-blind, using red and green alone can exclude some users. To ensure accessibility, I add shapes and icons alongside color cues.

Micro-animations provide subtle but effective signals. This counters change blindness — our tendency to miss non-salient changes.

• When numbers update, I use fade-ins or count-up transitions to indicate change without distraction.
• If a list reorders, such as when top-performing teams shift positions, a smooth slide animation under 300 milliseconds helps users maintain spatial memory. These animations reduce cognitive friction and prevent disorientation.

Layout is critical for clarifying change:

• I use modular cards with consistent spacing, alignment, and hierarchy to highlight key metrics.
• Cards are arranged in a sortable grid, allowing filtering by severity, recency, or relevance.
• Collapsible sections manage dense information while keeping important data visible for quick scanning and deeper exploration.

For instance, in a logistics dashboard, a card labeled “On-Time Deliveries” may display a weekly sparkline. If performance dips, the line flattens or turns slightly red, a downward arrow appears with a −1.8% delta, and the updated number fades in. This gives instant clarity without requiring users to open a detailed chart.

All these design choices support fast, informed decision-making. In high-velocity environments like product analytics, logistics, or financial operations, dashboards must do more than present data. They must reduce ambiguity and help teams quickly detect change, understand its impact, and take action.

Making Reliability Visible: Designing for Trust In Real-Time Data Interfaces

In real-time data environments, reliability is not just a technical feature. It is the foundation of user trust. Dashboards are used in high-stakes, fast-moving contexts where decisions depend on timely, accurate data. Yet these systems often face less-than-ideal conditions such as unreliable networks, API delays, and incomplete datasets. Designing for these realities is not just damage control. It is essential for making data experiences usable and trustworthy.

When data lags or fails to load, it can mislead users in serious ways:

• A dip in a trendline may look like a market decline when it is only a delay in the stream.
• Missing categories in a bar chart, if not clearly signaled, can lead to flawed decisions.

To mitigate this:

• Every data point should be paired with its condition.
• Interfaces must show not only what the data says but also how current or complete it is.

One effective strategy is replacing traditional spinners with skeleton UIs. These are greyed-out, animated placeholders that suggest the structure of incoming data. They set expectations, reduce anxiety, and show that the system is actively working. For example, in a financial dashboard, users might see the outline of a candlestick chart filling in as new prices arrive. This signals that data is being refreshed, not stalled.

Handling Data Unavailability

When data is unavailable, I show cached snapshots from the most recent successful load, labeled with timestamps such as “Data as of 10:42 AM.” This keeps users aware of what they are viewing.

In operational dashboards such as logistics or monitoring systems, this approach lets users act confidently even when real-time updates are temporarily out of sync.

Managing Connectivity Failures

To handle connectivity failures, I use auto-retry mechanisms with exponential backoff, giving the system several chances to recover quietly before notifying the user.

If retries fail, I maintain transparency with clear banners such as “Offline… Reconnecting…” In one product, this approach prevented users from reloading entire dashboards unnecessarily, especially in areas with unreliable Wi-Fi.

Ensuring Reliability with Accessibility

Reliability strongly connects with accessibility:

• Real-time interfaces must announce updates without disrupting user focus, beyond just screen reader compatibility.
• ARIA live regions quietly narrate significant changes in the background, giving screen reader users timely updates without confusion.
• All controls remain keyboard-accessible.
• Animations follow motion-reduction preferences to support users with vestibular sensitivities.

Data Freshness Indicator

A compact but powerful pattern I often implement is the Data Freshness Indicator, a small widget that:

• Shows sync status,
• Displays the last updated time,
• Includes a manual refresh button.

This improves transparency and reinforces user control. Since different users interpret these cues differently, advanced systems allow personalization. For example:

• Analysts may prefer detailed logs of update attempts.
• Business users might see a simple status such as “Live”, “Stale”, or “Paused”.

Reliability in data visualization is not about promising perfection. It is about creating a resilient, informative experience that supports human judgment by revealing the true state of the system.

“

When users understand what the dashboard knows, what it does not, and what actions it is taking, they are more likely to trust the data and make smarter decisions.

Real-World Case Study

In my work across logistics, hospitality, and healthcare, the challenge has always been to distill complexity into clarity. A well-designed dashboard is more than functional; it serves as a trusted companion in decision-making, embedding clarity, speed, and confidence from the start.

1. Fleet Management Dashboard

A client in the car rental industry struggled with fragmented operational data. Critical details like vehicle locations, fuel usage, maintenance schedules, and downtime alerts were scattered across static reports, spreadsheets, and disconnected systems. Fleet operators had to manually cross-reference data sources, even for basic dispatch tasks, which caused missed warnings, inefficient routing, and delays in response.

We solved these issues by redesigning the dashboard strategically, focusing on both layout improvements and how users interpret and act on information.

Strategic Design Improvements and Outcomes:

• Instant visibility of KPIs
  High-contrast cards at the top of the dashboard made key performance indicators instantly visible.
  Example: Fuel consumption anomalies that previously went unnoticed for days were flagged within hours, enabling quick corrective action.
• Clear trend and pattern visualization
  Booking forecasts, utilization graphs, and city-by-city comparisons highlighted performance trends.
  Example: A weekday-weekend booking chart helped a regional manager spot underperformance in one city and plan targeted vehicle redistribution.
• Unified operational snapshot
  Cost, downtime, and service schedules were grouped into one view.
  Result: The operations team could assess fleet health in under five minutes each morning instead of using multiple tools.
• Predictive context for planning
  Visual cues showed peak usage periods and historical demand curves.
  Result: Dispatchers prepared for forecasted spikes, reducing customer wait times and improving resource availability.
• Live map with real-time status
  A color-coded map displays vehicle status: green for active, red for urgent attention, gray for idle.
  Result: Supervisors quickly identified inactive or delayed vehicles and rerouted resources as needed.
• Role-based personalization
  Personalization options were built in, allowing each role to customize dashboard views.
  Example: Fleet managers prioritized financial KPIs, while technicians filtered for maintenance alerts and overdue service reports.

Strategic Impact: The dashboard redesign was not only about improving visuals. It changed how teams interacted with data. Operators no longer needed to search for insights, as the system presented them in line with tasks and decision-making. The dashboard became a shared reference for teams with different goals, enabling real-time problem solving, fewer manual checks, and stronger alignment across roles. Every element was designed to build both understanding and confidence in action.

2. Hospitality Revenue Dashboard

One of our clients, a hospitality group with 11 hotels in the UAE, faced a growing strategic gap. They had data from multiple departments, including bookings, events, food and beverage, and profit and loss, but it was spread across disconnected dashboards.

Strategic Design Improvements and Outcomes:

• All revenue streams (rooms, restaurants, bars, and profit and loss) were consolidated into a single filterable dashboard.
  Example: A revenue manager could filter by property to see if a drop in restaurant revenue was tied to lower occupancy or was an isolated issue. The structure supported daily operations, weekly reviews, and quarterly planning.
• Disconnected charts and metrics were replaced with a unified visual narrative showing how revenue streams interacted.
  Example: The dashboard revealed how event bookings influenced bar sales or staffing. This shifted teams from passive data consumption to active interpretation.
• AI modules for demand forecasting, spend prediction, and pricing recommendations were embedded in the dashboard.
  Result: Managers could test rate changes with interactive sliders and instantly view effects on occupancy, revenue per available room, and food and beverage income. This enabled proactive scenario planning.
• Compact, color-coded sparklines were placed next to each key metric to show short- and long-term trends.
  Result: These visuals made it easy to spot seasonal shifts or channel-specific patterns without switching views or opening separate reports.
• Predictive overlays such as forecast bands and seasonality markers were added to performance graphs.
  Example: If occupancy rose but lagged behind seasonal forecasts, the dashboard surfaced the gap, prompting early action such as promotions or issue checks.

Strategic Impact: By aligning the dashboard structure with real pricing and revenue strategies, the client shifted from static reporting to forward-looking decision-making. This was not a cosmetic interface update. It was a complete rethinking of how data could support business goals. The result enabled every team, from finance to operations, to interpret data based on their specific roles and responsibilities.

3. Healthcare Interoperability Dashboard

In healthcare, timely and accurate access to patient information is essential. A multi-specialist hospital client struggled with fragmented data. Doctors had to consult separate platforms such as electronic health records, lab results, and pharmacy systems to understand a patient’s condition. This fragmented process slowed decision-making and increased risks to patient safety.

Strategic Design Improvements and Outcomes:

• Patient medical history was integrated to unify lab reports, medications, and allergy information in one view.
  Example: A cardiologist, for example, could review recent cardiac markers with active medications and allergy alerts in the same place, enabling faster diagnosis and treatment.
• Lab report tracking was upgraded to show test type, date, status, and a clear summary with labels such as Pending, Completed, and Awaiting Review.
  Result: Trends were displayed with sparklines and color-coded indicators, helping clinicians quickly spot abnormalities or improvements.
• A medication management module was added for prescription entry, viewing, and exporting. It included dosage, frequency, and prescribing physician details.
  Example: Specialists could customize it to highlight drugs relevant to their practice, reducing overload and focusing on critical treatments.
• Rapid filtering options were introduced to search by patient name, medical record number, date of birth, gender, last visit, insurance company, or policy number.
  Example: Billing staff could locate patients by insurance details, while clinicians filtered records by visits or demographics.
• Visual transparency was provided through interactive tooltips explaining alert rationales and flagged data points.
  Result: Clinicians gained immediate context, such as the reason a lab value was marked as critical, supporting informed and timely decisions.

Strategic Impact: Our design encourages active decision-making instead of passive data review. Interactive tooltips ensure visual transparency by explaining the rationale behind alerts and flagged data points. These information boxes give clinicians immediate context, such as why a lab value is marked critical, helping them understand implications and next steps without delay.

Key UX Insights from the Above 3 Examples

• Design should drive conclusions, not just display data.
  Contextualized data enabled faster and more confident decisions. For example, a logistics dashboard flagged high-risk delays so dispatchers could act immediately.
• Complexity should be structured, not eliminated.
  Tools used timelines, layering, and progressive disclosure to handle dense information. A financial tool groups transactions by time blocks, easing cognitive load without losing detail.
• Trust requires clear system logic.
  Users trusted predictive alerts only after understanding their triggers. A healthcare interface added a “Why this alert?” option that explained the reasoning.
• The aim is clarity and action, not visual polish.
  Redesigns improved speed, confidence, and decision-making. In real-time contexts, confusion delays are more harmful than design flaws.

Final Takeaways

Real-time dashboards are not about overwhelming users with data. They are about helping them act quickly and confidently. The most effective dashboards reduce noise, highlight the most important metrics, and support decision-making in complex environments. Success lies in balancing visual clarity with cognitive ease while accounting for human limits like memory, stress, and attention alongside technical needs.

Do:

• Prioritize key metrics in a clear order so priorities are obvious. For instance, a support manager may track open tickets before response times.
• Use subtle micro-animations and small visual cues to indicate changes, helping users spot trends without distraction.
• Display data freshness and sync status to build trust.
• Plan for edge cases like incomplete or offline data to keep the experience consistent.
• Ensure accessibility with high contrast, ARIA labels, and keyboard navigation.

Don’t:

• Overcrowd the interface with too many metrics.
• Rely only on color to communicate critical information.
• Update all data at once or too often, which can cause overload.
• Hide failures or delays; transparency helps users adapt.

Over time, I’ve come to see real-time dashboards as decision assistants rather than control panels. When users say, “This helps me stay in control,” it reflects a design built on empathy that respects cognitive limits and enhances decision-making. That is the true measure of success.

(yk)

Having covered the developmental history and legacy of TV in Part 1, let’s now delve into more practical matters. As a quick reminder, the “10-foot experience” and its reliance on the six core buttons of any remote form the basis of our efforts, and as you’ll see, most principles outlined simply reinforce the unshakeable foundations.

In this article, we’ll sift through the systems, account for layout constraints, and distill the guidelines to understand the essence of TV interfaces. Once we’ve collected all the main ingredients, we’ll see what we can do to elevate these inherently simplistic experiences.

Let’s dig in, and let’s get practical!

The Systems

When it comes to hardware, TVs and set-top boxes are usually a few generations behind phones and computers. Their components are made to run lightweight systems optimised for viewing, energy efficiency, and longevity. Yet even within these constraints, different platforms offer varying performance profiles, conventions, and price points.

Some notable platforms/systems of today are:

• Roku, the most affordable and popular, but severely bottlenecked by weak hardware.
• WebOS, most common on LG devices, relies on web standards and runs well on modest hardware.
• Android TV, considered very flexible and customisable, but relatively demanding hardware-wise.
• Amazon Fire, based on Android but with a separate ecosystem. It offers great smooth performance, but is slightly more limited than stock Android.
• tvOS, by Apple, offering a high-end experience followed by a high-end price with extremely low customizability.

Despite their differences, all of the platforms above share something in common, and by now you’ve probably guessed that it has to do with the remote. Let’s take a closer look:

If these remotes were stripped down to just the D-pad, OK, and BACK buttons, they would still be capable of successfully navigating any TV interface. It is this shared control scheme that allows for the agnostic approach of this article with broadly applicable guidelines, regardless of the manufacturer.

Having already discussed the TV remote in detail in Part 1, let’s turn to the second part of the equation: the TV screen, its layout, and the fundamental building blocks of TV-bound experiences.

TV Design Fundamentals

The Screen

With almost one hundred years of legacy, TV has accumulated quite some baggage. One recurring topic in modern articles on TV design is the concept of “overscan” — a legacy concept from the era of cathode ray tube (CRT) screens. Back then, the lack of standards in production meant that television sets would often crop the projected image at its edges. To address this inconsistency, broadcasters created guidelines to keep important content from being cut off.

While overscan gets mentioned occasionally, we should call it what it really is — a thing of the past. Modern panels display content with greater precision, making thinking in terms of title and action safe areas rather archaic. Today, we can simply consider the margins and get the same results.

Google calls for a 5% margin layout and Apple advises a 60-point margin top and bottom, and 80 points on the sides in their Layout guidelines. The standard is not exactly clear, but the takeaway is simple: leave some breathing room between screen edge and content, like you would in any thoughtful layout.

Having left some baggage behind, we can start considering what to put within and outside the defined bounds.

The Layout

Considering the device is made for content consumption, streaming apps such as Netflix naturally come to mind. Broadly speaking, all these interfaces share a common layout structure where a vast collection of content is laid out in a simple grid.

These horizontally scrolling groups (sometimes referred to as “shelves”) resemble rows of a bookcase. Typically, they’ll contain dozens of items that don’t fit into the initial “fold”, so we’ll make sure the last visible item “peeks” from the edge, subtly indicating to the viewer there’s more content available if they continue scrolling.

If we were to define a standard 12-column layout grid, with a 2-column-wide item, we’d end up with something like this:

As you can see, the last item falls outside the “safe” zone.

Tip: A useful trick I discovered when designing TV interfaces was to utilise an odd number of columns. This allows the last item to fall within the defined margins and be more prominent while having little effect on the entire layout. We’ve concluded that overscan is not a prominent issue these days, yet an additional column in the layout helps completely circumvent it. Food for thought!

Typography

TV design requires us to practice restraint, and this becomes very apparent when working with type. All good typography practices apply to TV design too, but I’d like to point out two specific takeaways.

First, accounting for the distance, everything (including type) needs to scale up. Where 16–18px might suffice for web baseline text, 24px should be your starting point on TV, with the rest of the scale increasing proportionally.

“Typography can become especially tricky in 10-ft experiences. When in doubt, go larger.”

— Molly Lafferty (Marvel Blog)

With that in mind, the second piece of advice would be to start with a small 5–6 size scale and adjust if necessary. The simplicity of a TV experience can, and should, be reflected in the typography itself, and while small, such a scale will do all the “heavy lifting” if set correctly.

What you see in the example above is a scale I reduced from Google and Apple guidelines, with a few size adjustments. Simple as it is, this scale served me well for years, and I have no doubt it could do the same for you.

Freebie

If you’d like to use my basic reduced type scale Figma design file for kicking off your own TV project, feel free to do so!

Color

Imagine watching TV at night with the device being the only source of light in the room. You open up the app drawer and select a new streaming app; it loads into a pretty splash screen, and — bam! — a bright interface opens up, which, amplified by the dark surroundings, blinds you for a fraction of a second. That right there is our main consideration when using color on TV.

Built for cinematic experiences and often used in dimly lit environments, TVs lend themselves perfectly to darker and more subdued interfaces. Bright colours, especially pure white (#ffffff), will translate to maximum luminance and may be straining on the eyes. As a general principle, you should rely on a more muted color palette. Slightly tinting brighter elements with your brand color, or undertones of yellow to imitate natural light, will produce less visually unsettling results.

Finally, without a pointer or touch capabilities, it’s crucial to clearly highlight interactive elements. While using bright colors as backdrops may be overwhelming, using them sparingly to highlight element states in a highly contrasting way will work perfectly.

This highlighting of UI elements is what TV leans on heavily — and it is what we’ll discuss next.

Focus

In Part 1, we have covered how interacting through a remote implies a certain detachment from the interface, mandating reliance on a focus state to carry the burden of TV interaction. This is done by visually accenting elements to anchor the user’s eyes and map any subsequent movement within the interface.

If you have ever written HTML/CSS, you might recall the use of the :focus CSS pseudo-class. While it’s primarily an accessibility feature on the web, it’s the core of interaction on TV, with more flexibility added in the form of two additional directions thanks to a dedicated D-pad.

Focus Styles

There are a few standard ways to style a focus state. Firstly, there’s scaling — enlarging the focused element, which creates the illusion of depth by moving it closer to the viewer.

Another common approach is to invert background and text colors.

Finally, a border may be added around the highlighted element.

These styles, used independently or in various combinations, appear in all TV interfaces. While execution may be constrained by the specific system, the purpose remains the same: clear and intuitive feedback, even from across the room.

Having set the foundations of interaction, layout, and movement, we can start building on top of them. The next chapter will cover the most common elements of a TV interface, their variations, and a few tips and tricks for button-bound navigation.

Common TV UI Components

Nowadays, the core user journey on television revolves around browsing (or searching through) a content library, selecting an item, and opening a dedicated screen to watch or listen.

This translates into a few fundamental screens:

• Library (or Home) for content browsing,
• Search for specific queries, and
• A player screen focused on content playback.

These screens are built with a handful of components optimized for the 10-foot experience, and while they are often found on other platforms too, it’s worth examining how they differ on TV.

Menus

Appearing as a horizontal bar along the top edge of the screen, or as a vertical sidebar, the menu helps move between the different screens of an app. While its orientation mostly depends on the specific system, it does seem TV favors the side menu a bit more.

Both menu types share a common issue: the farther the user navigates away from the menu (vertically, toward the bottom for top-bars; and horizontally, toward the right for sidebars), the more button presses are required to get back to it. Fortunately, usually a Back button shortcut is added to allow for immediate menu focus, which greatly improves usability.

That said, the problem will arise a lot sooner for top menus, which, paired with the issue of having to hide or fade the element, makes a persistent sidebar a more common pick in TV user interfaces, and allows for a more consistent experience.

Shelves, Posters, And Cards

We’ve already mentioned shelves when covering layouts; now let’s shed some more light on this topic. The “shelves” (horizontally scrolling groups) form the basis of TV content browsing and are commonly populated with posters in three different aspect ratios: 2:3, 16:9, and 1:1.

2:3 posters are common in apps specializing in movies and shows. Their vertical orientation references traditional movie posters, harkening back to the cinematic experiences TVs are built for. Moreover, their narrow shape allows more items to be immediately visible in a row, and they rarely require any added text, with titles baked into the poster image.

16:9 posters abide by the same principles but with a horizontal orientation. They are often paired with text labels, which effectively turn them into cards, commonly seen on platforms like YouTube. In the absence of dedicated poster art, they show stills or playback from the videos, matching the aspect ratio of the media itself.

1:1 posters are often found in music apps like Spotify, their shape reminiscent of album art and vinyl sleeves. These squares often get used in other instances, like representing channel links or profile tiles, giving more visual variety to the interface.

All of the above can co-exist within a single app, allowing for richer interfaces and breaking up otherwise uniform content libraries.

And speaking of breaking up content, let’s see what we can do with spotlights!

Spotlights

Typically taking up the entire width of the screen, these eye-catching components will highlight a new feature or a promoted piece of media. In a sea of uniform shelves, they can be placed strategically to introduce aesthetic diversity and disrupt the monotony.

A spotlight can be a focusable element by itself, or it could expose several actions thanks to its generous space. In my ventures into TV design, I relied on a few different spotlight sizes, which allowed me to place multiples into a single row, all with the purpose of highlighting different aspects of the app, without breaking the form to which viewers were used.

Posters, cards, and spotlights shape the bulk of the visual experience and content presentation, but viewers still need a way to find specific titles. Let’s see how search and input are handled on TV.

Search And Entering Text

Manually browsing through content libraries can yield results, but having the ability to search will speed things up — though not without some hiccups.

TVs allow for text input in the form of on-screen keyboards, similar to the ones found in modern smartphones. However, inputting text with a remote control is quite inefficient given the restrictiveness of its control scheme. For example, typing “hey there” on a mobile keyboard requires 9 keystrokes, but about 38 on a TV (!) due to the movement between characters and their selection.

Typing with a D-pad may be an arduous task, but at the same time, having the ability to search is unquestionably useful.

Luckily for us, keyboards are accounted for in all systems and usually come in two varieties. We’ve got the grid layouts used by most platforms and a horizontal layout in support of the touch-enabled and gesture-based controls on tvOS. Swiping between characters is significantly faster, but this is yet another pattern that can only be enhanced, not replaced.

Modernization has made things significantly easier, with search autocomplete suggestions, device pairing, voice controls, and remotes with physical keyboards, but on-screen keyboards will likely remain a necessary fallback for quite a while. And no matter how cumbersome this fallback may be, we as designers need to consider it when building for TV.

“

Players And Progress Bars

While all the different sections of a TV app serve a purpose, the Player takes center stage. It’s where all the roads eventually lead to, and where viewers will spend the most time. It’s also one of the rare instances where focus gets lost, allowing for the interface to get out of the way of enjoying a piece of content.

Arguably, players are the most complex features of TV apps, compacting all the different functionalities into a single screen. Take YouTube, for example, its player doesn’t just handle expected playback controls but also supports content browsing, searching, reading comments, reacting, and navigating to channels, all within a single screen.

Compared to YouTube, Netflix offers a very lightweight experience guided by the nature of the app.

Still, every player has a basic set of controls, the foundation of which is the progress bar.

The progress bar UI element serves as a visual indicator for content duration. During interaction, focus doesn’t get placed on the bar itself, but on a movable knob known as the “scrubber.” It is by moving the scrubber left and right, or stopping it in its tracks, that we can control playback.

Another indirect method of invoking the progress bar is with the good old Play and Pause buttons. Rooted in the mechanical era of tape players, the universally understood triangle and two vertical bars are as integral to the TV legacy as the D-pad. No matter how minimalist and sleek the modern player interface may be, these symbols remain a staple of the viewing experience.

The presence of a scrubber may also indicate the type of content. Video on demand allows for the full set of playback controls, while live streams (unless DVR is involved) will do away with the scrubber since viewers won’t be able to rewind or fast-forward.

Earlier iterations of progress bars often came bundled with a set of playback control buttons, but as viewers got used to the tools available, these controls often got consolidated into the progress bar and scrubber themselves.

Bringing It All Together

With the building blocks out of the box, we’ve got everything necessary for a basic but functional TV app. Just as the six core buttons make remote navigation possible, the components and principles outlined above help guide purposeful TV design. The more context you bring, the more you’ll be able to expand and combine these basic principles, creating an experience unique to your needs.

Before we wrap things up, I’d like to share a few tips and tricks I discovered along the way — tips and tricks which I wish I had known from the start. Regardless of how simple or complex your idea may be, these may serve you as useful tools to help add depth, polish, and finesse to any TV experience.

Thinking Beyond The Basics

Like any platform, TV has a set of constraints that we abide by when designing. But sometimes these norms are applied without question, making the already limited capabilities feel even more restraining. Below are a handful of less obvious ideas that can help you design more thoughtfully and flexibly for the big screen.

Long Press

Most modern remotes support press-and-hold gestures as a subtle way to enhance the functionality, especially on remotes with fewer buttons available.

For example, holding directional buttons when browsing content speeds up scrolling, while holding Left/Right during playback speeds up timeline seeking. In many apps, a single press of the OK button opens a video, but holding it for longer opens a contextual menu with additional actions.

While not immediately apparent, press-and-hold is often used in many instances of TV experiences, essentially doubling the capabilities of a single button. Depending on context, you can map certain buttons to have an additional action and give more depth to the interface without making it convoluted.

And speaking of mapping, let’s see how we can utilize it to our benefit.

Remapping Keys And The Importance Of Context

While not as flexible as long-press, button functions can be contextually remapped. For example, Amazon’s Prime Video maps the Up button to open its X-Ray feature during playback. Typically, all directional buttons open video controls, so repurposing one for a custom feature cleverly adds interactivity with little tradeoff.

With limited input, context becomes a powerful tool. It not only declutters the interface to allow for more focus on specific tasks, but also enables the same set of buttons to trigger different actions based on the viewer’s location within an app.

“

Another great example is YouTube’s scrubber interaction. Once the scrubber is moved, every other UI element fades. This cleans up the viewer’s working area, so to speak, narrowing the interface to a single task. In this state — and only in this state — pressing Up one more time moves away from scrubbing and into browsing by chapter.

This is such an elegant example of expanding restraint, and adding more only when necessary. I hope it inspires similar interactions in your TV app designs.

Efficient Movement On TV

At its best, every action on TV “costs” at least one click. There’s no such thing as aimless cursor movement — if you want to move, you must press a button. We’ve seen how cumbersome it can be inside a keyboard, but there’s also something we can learn about efficient movement in these restrained circumstances.

Going back to the Homescreen, we can note that vertical and horizontal movement serve two distinct roles. Vertical movement switches between groups, while horizontal movement switches items within these groups. No matter how far you’ve gone inside a group, a single vertical click will move you into another.

This subtle difference — two axes with separate roles — is the most efficient way of moving in a TV interface. Reversing the pattern: horizontal to switch groups, and vertical to drill down, will work like a charm as long as you keep the role of each axis well defined.

Quietly brilliant and easy to overlook, this pattern powers almost every step of the TV experience. Remember it, and use it well.

Thinking Beyond JPGs

After covering in detail many of the technicalities, let’s finish with some visual polish.

Most TV interfaces are driven by tightly packed rows of cover and poster art. While often beautifully designed, this type of content and layouts leave little room for visual flair. For years, the flat JPG, with its small file size, has been a go-to format, though contemporary alternatives like WebP are slowly taking its place.

Meanwhile, we can rely on the tried and tested PNG to give a bit more shine to our TV interfaces. The simple fact that it supports transparency can help the often-rigid UIs feel more sophisticated. Used strategically and paired with simple focus effects such as background color changes, PNGs can bring subtle moments of delight to the interface.

Moreover, if transformations like scaling and rotating are supported, you can really make those rectangular shapes come alive with layering multiple assets.

As you probably understand by now, these little touches of finesse don’t go out of bounds of possibility. They simply find more room to breathe within it. But with such limited capabilities, it’s best to learn all the different tricks that can help make your TV experiences stand out.

Closing Thoughts

Rooted in legacy, with a limited control scheme and a rather “shallow” interface, TV design reminds us to do the best with what we have at our disposal. The restraints I outlined are not meant to induce claustrophobia and make you feel limited in your design choices, but rather to serve you as guides. It is by accepting that fact that we can find freedom and new avenues to explore.

This two-part series of articles, just like my experience designing for TV, was not about reinventing the wheel with radical ideas. It was about understanding its nuances and contributing to what’s already there with my personal touch.

If you find yourself working in this design field, I hope my guide will serve as a warm welcome and will help you do your finest work. And if you have any questions, do leave a comment, and I will do my best to reply and help.

Good luck!

Further Reading

• “Design for TV,” by Android Developers
  Great TV design is all about putting content front and center. It’s about creating an interface that’s easier to use and navigate, even from a distance. It’s about making it easier to find the content you love, and to enjoy it in the best possible quality.
• “TV Guidelines: A quick kick-off on designing for Television Experiences,” by Andrea Pacheco
  Just like designing a mobile app, designing a TV application can be a fun and complex thing to do, due to the numerous guidelines and best practices to follow. Below, I have listed the main best practices to keep in mind when designing an app for a 10-foot screen.
• “Designing for Television – TV Ui design,” by Molly Lafferty
  We’re no longer limited to a remote and cable box to control our TVs; we’re using Smart TVs, or streaming from set-top boxes like Roku and Apple TV, or using video game consoles like Xbox and PlayStation. And each of these devices allows a user interface that’s much more powerful than your old-fashioned on-screen guide.
• “Rethinking User Interface Design for the TV Platform,” by Pascal Potvin
  Designing for television has become part of the continuum of devices that require a rethink of how we approach user interfaces and user experiences.
• “Typography for TV,” by Android Developers
  As television screens are typically viewed from a distance, interfaces that use larger typography are more legible and comfortable for users. TV Design’s default type scale includes contrasting and flexible type styles to support a wide range of use cases.
• “Typography,” by Apple Developer docs
  Your typographic choices can help you display legible text, convey an information hierarchy, communicate important content, and express your brand or style.
• “Color on TV,” by Android Developers
  Color on TV design can inspire, set the mood, and even drive users to make decisions. It’s a powerful and tangible element that users notice first. As a rich way to connect with a wide audience, it’s no wonder color is an important step in crafting a high-quality TV interface.
• “Designing for Television — TV UI Design,” by Molly Lafferty (Marvel Blog)
  Today, we’re no longer limited to a remote and cable box to control our TVs; we’re using Smart TVs, or streaming from set-top boxes like Roku and Apple TV, or using video game consoles like Xbox and PlayStation. And each of these devices allows a user interface that’s much more powerful than your old-fashioned on-screen guide.

(mb, yk)

Television sets have been the staple of our living rooms for decades. We watch, we interact, and we control, but how often do we design for them? TV design flew under my “radar” for years, until one day I found myself in the deep, designing TV-specific user interfaces. Now, after gathering quite a bit of experience in the area, I would like to share my knowledge on this rather rare topic. If you’re interested in learning more about the user experience and user interfaces of television, this article should be a good starting point.

Just like any other device or use case, TV has its quirks, specifics, and guiding principles. Before getting started, it will be beneficial to understand the core ins and outs. In Part 1, we’ll start with a bit of history, take a close look at the fundamentals, and review the evolution of television. In Part 2, we’ll dive into the depths of practical aspects of designing for TV, including its key principles and patterns.

Let’s start with the two key paradigms that dictate the process of designing TV interfaces.

Mind The Gap, Or The 10-foot-experience

Firstly, we have the so-called “10-foot experience,” referring to the fact that interaction and consumption on TV happens from a distance of roughly three or more meters. This is significantly different than interacting with a phone or a computer and implies having some specific approaches in the TV user interface design. For example, we’ll need to make text and user interface (UI) elements larger on TV to account for the bigger distance to the screen.

Furthermore, we’ll take extra care to adhere to contrast standards, primarily relying on dark interfaces, as light ones may be too blinding in darker surroundings. And finally, considering the laid-back nature of the device, we’ll simplify the interactions.

But the 10-foot experience is only one part of the equation. There wouldn’t be a “10-foot experience” in the first place if there were no mediator between the user and the device, and if we didn’t have something to interact through from a distance.

There would be no 10-foot experience if there were no remote controllers.

The Mediator

The remote, the second half of the equation, is what allows us to interact with the TV from the comfort of the couch. Slower and more deliberate, this conglomerate of buttons lacks the fluid motion of a mouse, or the dexterity of fingers against a touchscreen — yet the capabilities of the remote should not be underestimated.

Rudimentary as it is and with a limited set of functions, the remote allows for some interesting design approaches and can carry the weight of the modern TV along with its ever-growing requirements for interactivity. It underwent a handful of overhauls during the seventy years since its inception and was refined and made more ergonomic; however, there is a 40-year-old pattern so deeply ingrained in its foundation that nothing can change it.

What if I told you that you could navigate TV interfaces and apps with a basic controller from the 1980s just as well as with the latest remote from Apple? Not only that, but any experience built around the six core buttons of a remote will be system-agnostic and will easily translate across platforms.

This is the main point I will focus on for the rest of this article.

Birth Of A Pattern

As television sets were taking over people’s living rooms in the 1950s, manufacturers sought to upgrade and improve the user experience. The effort of walking up to the device to manually adjust some settings was eventually identified as an area for improvement, and as a result, the first television remote controllers were introduced to the market.

Early Developments

Preliminary iterations of the remotes were rather unique, and it took some divergence before we finally settled on a rectangular shape and sprinkled buttons on top.

Take a look at the Zenith Flash-Matic, for example. Designed in the mid-1950s, this standout device featured a single button that triggered a directional lamp; by pointing it at specific corners of the TV set, viewers could control various functions, such as changing channels or adjusting the volume.

While they were a far cry compared to their modern counterparts, devices like the Flash-Matic set the scene for further developments, and we were off to the races!

As the designs evolved, the core functionality of the remote solidified. Gradually, remote controls became more than just simple channel changers, evolving into command centers for the expanding territory of home entertainment.

Note: I will not go too much into history here — aside from some specific points that are of importance to the matter at hand — but if you have some time to spare, do look into the developmental history of television sets and remotes, it’s quite a fascinating topic.

However, practical as they may have been, they were still considered a luxury, significantly increasing the prices of TV sets. As the 1970s were coming to a close, only around 17% of United States households had a remote controller for their TVs. Yet, things would change as the new decade rolled in.

Button Mania Of The 1980s

The eighties brought with them the Apple Macintosh, MTV, and Star Wars. It was a time of cultural shifts and technological innovation. Videocassette recorders (VCRs) and a multitude of other consumer electronics found their place in the living rooms of the world, along with TVs.

These new devices, while enriching our media experiences, also introduced a few new design problems. Where there was once a single remote, now there were multiple remotes, and things were getting slowly out of hand.

This marked the advent of universal remotes.

Trying to hit many targets with one stone, the unwieldy universal remotes were humanity’s best solution for controlling a wider array of devices. And they did solve some of these problems, albeit in an awkward way. The complexity of universal remotes was a trade-off for versatility, allowing them to be programmed and used as a command center for controlling multiple devices. This meant transforming the relatively simple design of their predecessors into a beehive of buttons, prioritizing broader compatibility over elegance.

On the other hand, almost as a response to the inconvenience of the universal remote, a different type of controller was conceived in the 1980s — one with a very basic layout and set of buttons, and which would leave its mark in both how we interact with the TV, and how our remotes are laid out. A device that would, knowingly or not, give birth to a navigational pattern that is yet to be broken — the NES controller.

D-pad Dominance

Released in 1985, the Nintendo Entertainment System (NES) was an instant hit. Having sold sixty million units around the world, it left an undeniable mark on the gaming console industry.

The NES controller (which was not truly remote, as it ran a cable to the central unit) introduced the world to a deceptively simple control scheme. Consisting of six primary actions, it gave us the directional pad (the D-pad), along with two action buttons (A and B). Made in response to the bulky joystick, the cross-shaped cluster allowed for easy movement along two axes (up, down, left, and right).

Charmingly intuitive, this navigational pattern would produce countless hours of gaming fun, but more importantly, its elementary design would “seep over” into the wider industry — the D-pad, along with the two action buttons, would become the very basis on which future remotes would be constructed.

The world continued spinning madly on, and what was once a luxury became commonplace. By the end of the decade, TV remotes were more integral to the standard television experience, and more than two-thirds of American TV owners had some sort of a remote.

The nineties rolled in with further technological advancements. TV sets became more robust, allowing for finer tuning of their settings. This meant creating interfaces through which such tasks could be accomplished, and along with their master sets, remotes got updated as well.

Gone were the bulky rectangular behemoths of the eighties. As ergonomics took precedence, they got replaced by comfortably contoured devices that better fit their users’ hands. Once conglomerations of dozens of uniform buttons, these contemporary remotes introduced different shapes and sizes, allowing for recognition simply through touch. Commands were being clustered into sensible groups along the body of the remote, and within those button groups, a familiar shape started to emerge.

Gradually, the D-pad found its spot on our TV remotes. As the evolution of these devices progressed, it became even more deeply embedded at the core of their interactivity.

Set-top boxes and smart features emerged in the 2000s and 2010s, and TV technology continued to advance. Along the way, many bells and whistles were introduced. TVs got bigger, brighter, thinner, yet their essence remained unchanged.

In the years since their inception, remotes were innovated upon, but all the undertakings circle back to the core principles of the NES controller. Future endeavours never managed to replace, but only to augment and reinforce the pattern.

The Evergreen Pattern

In 2013, LG introduced their Magic remote (“So magically simple, the kids will be showing you how to use it!”). This uniquely shaped device enabled motion controls on LG TV sets, allowing users to point and click similar to a computer mouse. Having a pointer on the screen allowed for much more flexibility and speed within the system, and the remote was well-received and praised as one of the best smart TV remotes.

Innovating on tradition, this device introduced new features and fresh perspectives to the world of TV. But if we look at the device itself, we’ll see that, despite its differences, it still retains the D-pad as a means of interaction. It may be argued that LG never set out to replace the directional pad, and as it stands, regardless of their intent, they only managed to augment it.

For an even better example, let’s examine Apple TV’s second-generation remotes (the first-generation Siri remote). Being the industry disruptors, Apple introduced a touchpad to the top half of the remote. The glass surface provided briskness and precision to the experience, enabling multi-touch gestures, swipe navigation, and quick scrolling. This quality of life upgrade was most noticeable when typing with the horizontal on-screen keyboards, as it allowed for smoother and quicker scrolling from A to Z, making for a more refined experience.

While at first glance it may seem Apple removed the directional buttons, the fact is that the touchpad is simply a modernised take on the pattern, still abiding by the same four directions a classic D-pad does. You could say it’s a D-pad with an extra layer of gimmick.

Furthermore, the touchpad didn’t really sit well with the user base, along with the fact that the remote’s ergonomics were a bit iffy. So instead of pushing the boundaries even further with their third generation of remotes, Apple did a complete 180, re-introducing the classic D-pad cluster while keeping the touch capabilities from the previous generation (the touch-enabled clickpad lets you select titles, swipe through playlists, and use a circular gesture on the outer ring to find just the scene you’re looking for).

Now, why can’t we figure out a better way to navigate TVs? Does that mean we shouldn’t try to innovate?

We can argue that using motion controls and gestures is an obvious upgrade to interacting with a TV. And we’d be right… in principle. These added features are more complex and costly to produce, but more importantly, while it has been upgraded with bits and bobs, the TV is essentially a legacy system. And it’s not only that.

While touch controls are a staple of interaction these days, adding them without thorough consideration can reduce the usability of a remote.

“

Pitfalls Of Touch Controls

Modern car dashboards are increasingly being dominated by touchscreens. While they may impress at auto shows, their real-world usability is often compromised.

Driving demands constant focus and the ability to adapt and respond to ever-changing conditions. Any interface that requires taking your eyes off the road for more than a moment increases the risk of accidents. That’s exactly where touch controls fall short. While they may be more practical (and likely cheaper) for manufacturers to implement, they’re often the opposite for the end user.

Unlike physical buttons, knobs, and levers, which offer tactile landmarks and feedback, touch interfaces lack the ability to be used by feeling alone. Even simple tasks like adjusting the volume of the radio or the climate controls often involve gestures and nested menus, all performed on a smooth glass surface that demands visual attention, especially when fine-tuning.

Fortunately, the upcoming 2026 Euro NCAP regulations will encourage car manufacturers to reintroduce physical controls for core functions, reducing driver distraction and promoting safer interaction.

Similarly (though far less critically), sleek, buttonless TV remote controls may feel modern, but they introduce unnecessary abstraction to a familiar set of controls.

Physical buttons with distinct shapes and positioning allow users to navigate by memory and touch, even in the dark. That’s not outdated — it’s a deeper layer of usability that modern design should respect, not discard.

“

And this is precisely why Apple reworked the Apple TV third-generation remote the way it is now, where the touch area at the top disappeared. Instead, the D-pad again had clearly defined buttons, and at the same time, the D-pad could also be extended (not replaced) to accept some touch gestures.

The Legacy Of TV

Let’s take a look at an old on-screen keyboard.

The Legend of Zelda, released in 1986, allowed players to register their names in-game. There are even older games with the same feature, but that’s beside the point. Using the NES controller, the players would move around the keyboard, entering their moniker character by character. Now let’s take a look at a modern iteration of the on-screen keyboard.

Notice the difference? Or, to phrase it better: do you notice the similarities? Throughout the years, we’ve introduced quality of life improvements, but the core is exactly the same as it was forty years ago. And it is not the lack of innovation or bad remotes that keep TV deeply ingrained in its beginnings. It’s simply that it’s the most optimal way to interact given the circumstances.

Laying It All Out

Just like phones and computers, TV layouts are based on a grid system. However, this system is a lot more apparent and rudimentary on TV. Taking a look at a standard TV interface, we’ll see that it consists mainly of horizontal and vertical lists, also known as shelves.

These grids may be populated with cards, characters of the alphabet, or anything else, essentially, and upon closer examination, we’ll notice that our movement is restricted by a few factors:

1. There is no pointer for our eyes to follow, like there would be on a computer.
2. There is no way to interact directly with the display like we would with a touchscreen.

For the purposes of navigating with a remote, a focus state is introduced. This means that an element will always be highlighted for our eyes to anchor, and it will be the starting point for any subsequent movement within the interface.

Moreover, starting from the focused element, we can notice that the movement is restricted to one item at a time, almost like skipping stones. Navigating linearly in such a manner, if we wanted to move within a list of elements from element #1 to element #5, we’d have to press a directional button four times.

To successfully navigate such an interface, we need the ability to move left, right, up, and down — we need a D-pad. And once we’ve landed on our desired item, there needs to be a way to select it or make a confirmation, and in the case of a mistake, we need to be able to go back. For the purposes of those two additional interactions, we’d need two more buttons, OK and back, or to make it more abstract, we’d need buttons A and B.

So, to successfully navigate a TV interface, we need only a NES controller.

Yes, we can enhance it with touchpads and motion gestures, augment it with voice controls, but this unshakeable foundation of interaction will remain as the very basic level of inherent complexity in a TV interface. Reducing it any further would significantly impair the experience, so all we’ve managed to do throughout the years is to only build upon it.

The D-pad and buttons A and B survived decades of innovation and technological shifts, and chances are they’ll survive many more. By understanding and respecting this principle, you can design intuitive, system-agnostic experiences and easily translate them across platforms. Knowing you can’t go simpler than these six buttons, you’ll easily build from the ground up and attach any additional framework-bound functionality to the time-tested core.

And once you get the grip of these paradigms, you’ll get into mapping and re-mapping buttons depending on context, and understand just how far you can go when designing for TV. You’ll be able to invent new experiences, conduct experiments, and challenge the patterns. But that is a topic for a different article.

Closing Thoughts

While designing for TV almost exclusively during the past few years, I was also often educating the stakeholders on the very principles outlined in this article. Trying to address their concerns about different remotes working slightly differently, I found respite in the simplicity of the NES controller and how it got the point across in an understandable way. Eventually, I expanded my knowledge by looking into the developmental history of the remote and was surprised that my analogy had backing in history. This is a fascinating niche, and there’s a lot more to share on the topic. I’m glad we started!

It’s vital to understand the fundamental “ins” and “outs” of any venture before getting practical, and TV is no different. Now that you understand the basics, go, dig in, and break some ground.

Having covered the underlying interaction patterns of TV experiences in detail, it’s time to get practical.

In Part 2, we’ll explore the building blocks of the 10-foot experience and how to best utilize them in your designs. We’ll review the TV design fundamentals (the screen, layout, typography, color, and focus/focus styles), and the common TV UI components (menus, “shelves,” spotlights, search, and more). I will also show you how to start thinking beyond the basics and to work with — and around — the constraints which we abide by when designing for TV. Stay tuned!

Further Reading

• “The 10 Foot Experience,” by Robert Stulle (Edenspiekermann)
  Every user interface should offer effortless navigation and control. For the 10-foot experience, this is twice as important; with only up, down, left, right, OK and back as your input vocabulary, things had better be crystal clear. You want to sit back and enjoy without having to look at your remote — your thumb should fly over the buttons to navigate, select, and activate.
• “Introduction to the 10-Foot Experience for Windows Game Developers” (Microsoft Learn)
  A growing number of people are using their personal computers in a completely new way. When you think of typical interaction with a Windows-based computer, you probably envision sitting at a desk with a monitor, and using a mouse and keyboard (or perhaps a joystick device); this is referred to as the 2-foot experience. But there’s another trend which you’ll probably start hearing more about: the 10-foot experience, which describes using your computer as an entertainment device with output to a TV. This article introduces the 10-foot experience and explores the list of things that you should consider first about this new interaction pattern, even if you aren’t expecting your game to be played this way.
• “10-foot user interface” (Wikipedia)
  In computing, a 10-foot user interface, or 3-meter UI, is a graphical user interface designed for televisions (TV). Compared to desktop computer and smartphone user interfaces, it uses text and other interface elements that are much larger in order to accommodate a typical television viewing distance of 10 feet (3.0 meters); in reality, this distance varies greatly between households, and additionally, the limitations of a television’s remote control necessitate extra user experience considerations to minimize user effort.
• “The Television Remote Control: A Brief History,” by Mary Bellis (ThoughtCo)
  The first TV remote, the Lazy Bone, was made in 1950 and used a cable. In 1955, the Flash-matic was the first wireless remote, but it had issues with sunlight. Zenith’s Space Command in 1956 used ultrasound and became the popular choice for over 25 years.
• “The History of The TV Remote,” by Remy Millisky (Grunge)
  The first person to create and patent the remote control was none other than Nikola Tesla, inventor of the Tesla coil and numerous electronic systems. He patented the idea in 1893 to drive boats remotely, far before televisions were invented. Since then, remotes have come a long way, especially for the television, changing from small boxes with long wires to the wireless universal remotes that many people have today. How has the remote evolved over time?
• “Nintendo Entertainment System controller” (Nintendo Wiki)
  The Nintendo Entertainment System controller is the main controller for the NES. While previous systems had used joysticks, the NES controller provided a directional pad (the D-pad was introduced in the Game & Watch version of Donkey Kong).
• “Why Touchscreens In Cars Don’t Work,” by Jacky Li (published in June 2018)
  Observing the behaviour of 21 drivers has made me realize what’s wrong with automotive UX. […] While I was excited to learn more about the Tesla Model X, it slowly became apparent to me that the driver’s eyes were more glued to the screen than the road. Something about interacting with a touchscreen when driving made me curious to know: just how distracting are they?
• “Europe Is Requiring Physical Buttons For Cars To Get Top Safety Marks,” by Jason Torchinsky (published in March 2024)
  The overuse of touchscreens is an industry-wide problem, with almost every vehicle-maker moving key controls onto central touchscreens, obliging drivers to take their eyes off the road and raising the risk of distraction crashes. New Euro NCAP tests due in 2026 will encourage manufacturers to use separate, physical controls for basic functions in an intuitive manner, limiting eyes-off-road time and therefore promoting safer driving.

(mb, yk)

These days, it’s easy to find curated lists of AI tools for designers, galleries of generated illustrations, and countless prompt libraries. What’s much harder to find is a clear view of how AI is actually integrated into the everyday workflow of a product designer — not for experimentation, but for real, meaningful outcomes.

I’ve gone through that journey myself: testing AI across every major stage of the design process, from ideation and prototyping to visual design and user research. Along the way, I’ve built a simple, repeatable workflow that significantly boosts my productivity.

In this article, I’ll share what’s already working and break down some of the most common objections I’ve encountered — many of which I’ve faced personally.

Stage 1: Idea Generation Without The Clichés

Pushback: “Whenever I ask AI to suggest ideas, I just get a list of clichés. It can’t produce the kind of creative thinking expected from a product designer.”

That’s a fair point. AI doesn’t know the specifics of your product, the full context of your task, or many other critical nuances. The most obvious fix is to “feed it” all the documentation you have. But that’s a common mistake as it often leads to even worse results: the context gets flooded with irrelevant information, and the AI’s answers become vague and unfocused.

Current-gen models can technically process thousands of words, but the longer the input, the higher the risk of missing something important, especially content buried in the middle. This is known as the “lost in the middle” problem.

To get meaningful results, AI doesn’t just need more information — it needs the right information, delivered in the right way. That’s where the RAG approach comes in.

How RAG Works

Think of RAG as a smart assistant working with your personal library of documents. You upload your files, and the assistant reads each one, creating a short summary — a set of bookmarks (semantic tags) that capture the key topics, terms, scenarios, and concepts. These summaries are stored in a kind of “card catalog,” called a vector database.

When you ask a question, the assistant doesn’t reread every document from cover to cover. Instead, it compares your query to the bookmarks, retrieves only the most relevant excerpts (chunks), and sends those to the language model to generate a final answer.

How Is This Different from Just Dumping a Doc into the Chat?

Let’s break it down:

Typical chat interaction

It’s like asking your assistant to read a 100-page book from start to finish every time you have a question. Technically, all the information is “in front of them,” but it’s easy to miss something, especially if it’s in the middle. This is exactly what the “lost in the middle” issue refers to.

RAG approach

You ask your smart assistant a question, and it retrieves only the relevant pages (chunks) from different documents. It’s faster and more accurate, but it introduces a few new risks:

• Ambiguous question
  You ask, “How can we make the project safer?” and the assistant brings you documents about cybersecurity, not finance.
• Mixed chunks
  A single chunk might contain a mix of marketing, design, and engineering notes. That blurs the meaning so the assistant can’t tell what the core topic is.
• Semantic gap
  You ask, “How can we speed up the app?” but the document says, “Optimize API response time.” For a human, that’s obviously related. For a machine, not always.

These aren’t reasons to avoid RAG or AI altogether. Most of them can be avoided with better preparation of your knowledge base and more precise prompts. So, where do you start?

Start With Three Short, Focused Documents

These three short documents will give your AI assistant just enough context to be genuinely helpful:

• Product Overview & Scenarios
  A brief summary of what your product does and the core user scenarios.
• Target Audience
  Your main user segments and their key needs or goals.
• Research & Experiments
  Key insights from interviews, surveys, user testing, or product analytics.

Each document should focus on a single topic and ideally stay within 300–500 words. This makes it easier to search and helps ensure that each retrieved chunk is semantically clean and highly relevant.

Language Matters

In practice, RAG works best when both the query and the knowledge base are in English. I ran a small experiment to test this assumption, trying a few different combinations:

• English prompt + English documents: Consistently accurate and relevant results.
• Non-English prompt + English documents: Quality dropped sharply. The AI struggled to match the query with the right content.
• Non-English prompt + non-English documents: The weakest performance. Even though large language models technically support multiple languages, their internal semantic maps are mostly trained in English. Vector search in other languages tends to be far less reliable.

Takeaway: If you want your AI assistant to deliver precise, meaningful responses, do your RAG work entirely in English, both the data and the queries. This advice applies specifically to RAG setups. For regular chat interactions, you’re free to use other languages. A challenge also highlighted in this 2024 study on multilingual retrieval.

From Outsider to Teammate: Giving AI the Context It Needs

Once your AI assistant has proper context, it stops acting like an outsider and starts behaving more like someone who truly understands your product. With well-structured input, it can help you spot blind spots in your thinking, challenge assumptions, and strengthen your ideas — the way a mid-level or senior designer would.

Here’s an example of a prompt that works well for me:

Your task is to perform a comparative analysis of two features: "Group gift contributions" (described in group_goals.txt) and "Personal savings goals" (described in personal_goals.txt).

The goal is to identify potential conflicts in logic, architecture, and user scenarios and suggest visual and conceptual ways to clearly separate these two features in the UI so users can easily understand the difference during actual use.

Please include:

• Possible overlaps in user goals, actions, or scenarios;
• Potential confusion if both features are launched at the same time;
• Any architectural or business-level conflicts (e.g. roles, notifications, access rights, financial logic);
• Suggestions for visual and conceptual separation: naming, color coding, separate sections, or other UI/UX techniques;
• Onboarding screens or explanatory elements that might help users understand both features.

If helpful, include a comparison table with key parameters like purpose, initiator, audience, contribution method, timing, access rights, and so on.

AI Needs Context, Not Just Prompts

If you want AI to go beyond surface-level suggestions and become a real design partner, it needs the right context. Not just more information, but better, more structured information.

Building a usable knowledge base isn’t difficult. And you don’t need a full-blown RAG system to get started. Many of these principles work even in a regular chat: well-organized content and a clear question can dramatically improve how helpful and relevant the AI’s responses are. That’s your first step in turning AI from a novelty into a practical tool in your product design workflow.

Stage 2: Prototyping and Visual Experiments

Pushback: “AI only generates obvious solutions and can’t even build a proper user flow. It’s faster to do it manually.”

That’s a fair concern. AI still performs poorly when it comes to building complete, usable screen flows. But for individual elements, especially when exploring new interaction patterns or visual ideas, it can be surprisingly effective.

For example, I needed to prototype a gamified element for a limited-time promotion. The idea is to give users a lottery ticket they can “flip” to reveal a prize. I couldn’t recreate the 3D animation I had in mind in Figma, either manually or using any available plugins. So I described the idea to Claude 4 in Figma Make and within a few minutes, without writing a single line of code, I had exactly what I needed.

At the prototyping stage, AI can be a strong creative partner in two areas:

• UI element ideation
  It can generate dozens of interactive patterns, including ones you might not think of yourself.
• Micro-animation generation
  It can quickly produce polished animations that make a concept feel real, which is great for stakeholder presentations or as a handoff reference for engineers.

AI can also be applied to multi-screen prototypes, but it’s not as simple as dropping in a set of mockups and getting a fully usable flow. The bigger and more complex the project, the more fine-tuning and manual fixes are required. Where AI already works brilliantly is in focused tasks — individual screens, elements, or animations — where it can kick off the thinking process and save hours of trial and error.

A quick UI prototype of a gamified promo banner created with Claude 4 in Figma Make. No code or plugins needed.

Here’s another valuable way to use AI in design — as a stress-testing tool. Back in 2023, Google Research introduced PromptInfuser, an internal Figma plugin that allowed designers to attach prompts directly to UI elements and simulate semi-functional interactions within real mockups. Their goal wasn’t to generate new UI, but to check how well AI could operate inside existing layouts — placing content into specific containers, handling edge-case inputs, and exposing logic gaps early.

The results were striking: designers using PromptInfuser were up to 40% more effective at catching UI issues and aligning the interface with real-world input — a clear gain in design accuracy, not just speed.

That closely reflects my experience with Claude 4 and Figma Make: when AI operates within a real interface structure, rather than starting from a blank canvas, it becomes a much more reliable partner. It helps test your ideas, not just generate them.

Stage 3: Finalizing The Interface And Visual Style

Pushback: “AI can’t match our visual style. It’s easier to just do it by hand.”

This is one of the most common frustrations when using AI in design. Even if you upload your color palette, fonts, and components, the results often don’t feel like they belong in your product. They tend to be either overly decorative or overly simplified.

And this is a real limitation. In my experience, today’s models still struggle to reliably apply a design system, even if you provide a component structure or JSON files with your styles. I tried several approaches:

• Direct integration with a component library.
  I used Figma Make (powered by Claude) and connected our library. This was the least effective method: although the AI attempted to use components, the layouts were often broken, and the visuals were overly conservative. Other designers have run into similar issues, noting that library support in Figma Make is still limited and often unstable.
• Uploading styles as JSON.
  Instead of a full component library, I tried uploading only the exported styles — colors, fonts — in a JSON format. The results improved: layouts looked more modern, but the AI still made mistakes in how styles were applied.
• Two-step approach: structure first, style second.
  What worked best was separating the process. First, I asked the AI to generate a layout and composition without any styling. Once I had a solid structure, I followed up with a request to apply the correct styles from the same JSON file. This produced the most usable result — though still far from pixel-perfect.

So yes, AI still can’t help you finalize your UI. It doesn’t replace hand-crafted design work. But it’s very useful in other ways:

• Quickly creating a visual concept for discussion.
• Generating “what if” alternatives to existing mockups.
• Exploring how your interface might look in a different style or direction.
• Acting as a second pair of eyes by giving feedback, pointing out inconsistencies or overlooked issues you might miss when tired or too deep in the work.

AI won’t save you five hours of high-fidelity design time, since you’ll probably spend that long fixing its output. But as a visual sparring partner, it’s already strong. If you treat it like a source of alternatives and fresh perspectives, it becomes a valuable creative collaborator.

“

Stage 4: Product Feedback And Analytics: AI As A Thinking Exosuit

Product designers have come a long way. We used to create interfaces in Photoshop based on predefined specs. Then we delved deeper into UX with mapping user flows, conducting interviews, and understanding user behavior. Now, with AI, we gain access to yet another level: data analysis, which used to be the exclusive domain of product managers and analysts.

As Vitaly Friedman rightly pointed out in one of his columns, trying to replace real UX interviews with AI can lead to false conclusions as models tend to generate an average experience, not a real one. The strength of AI isn’t in inventing data but in processing it at scale.

Let me give a real example. We launched an exit survey for users who were leaving our service. Within a week, we collected over 30,000 responses across seven languages.

Simply counting the percentages for each of the five predefined reasons wasn’t enough. I wanted to know:

• Are there specific times of day when users churn more?
• Do the reasons differ by region?
• Is there a correlation between user exits and system load?

The real challenge was… figuring out what cuts and angles were even worth exploring. The entire technical process, from analysis to visualizations, was done “for me” by Gemini, working inside Google Sheets. This task took me about two hours in total. Without AI, not only would it have taken much longer, but I probably wouldn’t have been able to reach that level of insight on my own at all.

AI enables near real-time work with large data sets. But most importantly, it frees up your time and energy for what’s truly valuable: asking the right questions.

“

A few practical notes: Working with large data sets is still challenging for models without strong reasoning capabilities. In my experiments, I used Gemini embedded in Google Sheets and cross-checked the results using ChatGPT o3. Other models, including the standalone Gemini 2.5 Pro, often produced incorrect outputs or simply refused to complete the task.

AI Is Not An Autopilot But A Co-Pilot

AI in design is only as good as the questions you ask it. It doesn’t do the work for you. It doesn’t replace your thinking. But it helps you move faster, explore more options, validate ideas, and focus on the hard parts instead of burning time on repetitive ones. Sometimes it’s still faster to design things by hand. Sometimes it makes more sense to delegate to a junior designer.

But increasingly, AI is becoming the one who suggests, sharpens, and accelerates. Don’t wait to build the perfect AI workflow. Start small. And that might be the first real step in turning AI from a curiosity into a trusted tool in your product design process.

Let’s Summarize

• If you just paste a full doc into chat, the model often misses important points, especially things buried in the middle. That’s the “lost in the middle” problem.
• The RAG approach helps by pulling only the most relevant pieces from your documents. So responses are faster, more accurate, and grounded in real context.
• Clear, focused prompts work better. Narrow the scope, define the output, and use familiar terms to help the model stay on track.
• A well-structured knowledge bas makes a big difference. Organizing your content into short, topic-specific docs helps reduce noise and keep answers sharp.
• Use English for both your prompts and your documents. Even multilingual models are most reliable when working in English, especially for retrieval.
• Most importantly: treat AI as a creative partner. It won’t replace your skills, but it can spark ideas, catch issues, and speed up the tedious parts.

Further Reading

• “AI-assisted Design Workflows: How UX Teams Move Faster Without Sacrificing Quality”, Cindy Brummer
  This piece is a perfect prequel to my article. It explains how to start integrating AI into your design process, how to structure your workflow, and which tasks AI can reasonably take on — before you dive into RAG or idea generation.
• “8 essential tips for using Figma Make”, Alexia Danton
  While this article focuses on Figma Make, the recommendations are broadly applicable. It offers practical advice that will make your work with AI smoother, especially if you’re experimenting with visual tools and structured prompting.
• “What Is Retrieval-Augmented Generation aka RAG”, Rick Merritt
  If you want to go deeper into how RAG actually works, this is a great starting point. It breaks down key concepts like vector search and retrieval in plain terms and explains why these methods often outperform long prompts alone.

(yk)

Color plays a pivotal role in crafting compelling user experiences and successful digital products. It’s far more than just aesthetics; color strategically guides users, establishes brand identity, and evokes specific emotions.

Beyond functionality, color is also a powerful tool for brand recognition and emotional connection. Consistent use of brand colors across a digital product reinforces identity and builds trust. Different hues carry cultural and psychological associations, allowing designers to subtly influence user perception and create the desired mood. A thoughtful and deliberate approach to color in UX design elevates the user experience, strengthens brand presence, and contributes significantly to the overall success and impact of digital products. In this article, we will talk about the importance of color and why they are important for creating emotional connection and delivering consistent and accessible digital products.

Well-chosen color palettes enhance usability by creating visual hierarchies, highlighting interactive elements, and providing crucial feedback on screens. For instance, a bright color might draw attention to a call-to-action button, while consistent color coding can help users navigate complex interfaces intuitively. Color also contributes significantly to accessibility, ensuring that users with visual impairments can still effectively interact with digital products. By carefully considering contrast ratios and providing alternative visual cues, designers can create inclusive experiences that cater to a wider audience.

The colors we choose are the silent language of our digital products, and speaking it fluently is essential for success.

“

Communicating Brand Identity Through Color In The Digital Space

A thoughtfully curated and vibrant color palette becomes a critical differentiator, allowing a brand to stand out amidst the digital noise and cultivate stronger connections with the audience.

Far beyond mere decoration, color acts as a visual shorthand, instantly conveying a brand’s personality, its underlying values, and its unique essence. According to the American Marketing Association, vibrant colors, in particular, possess an inherent magnetism, drawing the eye and etching themselves into memory within the online environment. They infuse the brand with energy and dynamism, projecting approachability and memorability in a way that more muted tones often cannot.

Consistency: The Core Of Great Design

Consistency is important because it fosters trust and familiarity, allowing users to quickly identify and connect with the brand in the online landscape. The strategic deployment of vibrant colors is especially crucial for brands seeking to establish themselves and flourish within the digital ecosystem. In the absence of physical storefronts or tangible in-person interactions, visual cues become paramount in shaping user perception and building brand recognition. A carefully selected primary color, supported by a complementary and equally energetic secondary palette, can become synonymous with a brand’s digital presence. A consistent application of the right colors across different digital touchpoints — from the logo and website design to the user interface of an app and engaging social media campaigns — creates a cohesive and instantly recognizable visual language.

Several sources and professionals agree that the psychology behind the colors plays a significant role in shaping brand perception. The publication Insights Psychology, for instance, explains how colors can create emotional and behavioural responses. Vibrant colors often evoke strong emotions and associations. A bold, energetic red, for example, might communicate passion and excitement, while a bright, optimistic yellow could convey innovation and cheerfulness. By consciously aligning their color choices with their brand values and target audience preferences, digitally-native brands can create a powerful emotional resonance.

Beyond Aesthetics: How Color Psychologically Impacts User Behavior In Digital

As designers working with digital products, we’ve learned that color is far more than a superficial layer of visual appeal. It’s a potent, often subconscious, force that shapes how users interact with and feel about the digital products we build.

We’re not just painting pixels, we’re conducting a psychological symphony, carefully selecting each hue to evoke specific emotions, guide behavior, and ultimately forge a deeper connection with the user.

The initial allure of a color palette might be purely aesthetic, but its true power lies in its ability to bypass conscious thought and tap directly into our emotional core. Think about the subtle unease that might creep in when encountering a predominantly desaturated interface for a platform promising dynamic content, or the sense of calm that washes over you when a learning application utilizes soft, analogous colors. These are not arbitrary responses; they’re deeply rooted in our evolutionary history and cultural conditioning.

To understand how colors psychologically impact user behavior in digital, we first need to understand how colors are defined. In digital design, colors are precisely defined using the HSB model, which stands for Hue, Saturation, and Brightness. This model provides a more intuitive way for designers to think about and manipulate color compared to other systems like RGB (Red, Green, Blue). Here is a quick breakdown of each component:

Hue

This is the pure color itself, the essence that we typically name, such as red, blue, green, or yellow. On a color wheel, hue is represented as an angle ranging from 0 to 360 degrees. For example, 0 is red, 120 is green, and 240 is blue. Think of it as the specific wavelength of light that our eyes perceive as a particular color. In UX, selecting the base hues is often tied to brand identity and the overall feeling you want to convey.

Saturation

Saturation refers to the intensity or purity of the hue. It describes how vivid or dull the color appears. A fully saturated color is rich and vibrant, while a color with low saturation appears muted, grayish, or desaturated. Saturation is typically expressed as a percentage, from 0% (completely desaturated, appearing as a shade of gray) to 100% (fully saturated, the purest form of the hue).

In UX, saturation levels are crucial for creating visual hierarchy and drawing attention to key elements. Highly saturated colors often indicate interactive elements or important information, while lower saturation can be used for backgrounds or less critical content.

Brightness

Brightness, sometimes also referred to as a value or lightness, indicates how light or dark a color appears. It’s the amount of white or black mixed into the hue. Brightness is also usually represented as a percentage, ranging from 0% (completely black, regardless of the hue or saturation) to 100% (fully bright). At 100% brightness and 0% saturation, you get white. In UX, adjusting brightness is essential for creating contrast and ensuring readability. Sufficient brightness contrast between text and background is a fundamental accessibility requirement. Furthermore, variations in brightness within a color palette can create visual depth and subtle distinctions between UI elements.

By understanding and manipulating these 3 color dimensions, digital designers have precise control over their color choices. This allows for the creation of harmonious and effective color palettes that not only align with brand guidelines but also strategically influence user behavior.

Just as in the physical world, colors in digital also carry symbolic meanings and trigger subconscious associations. Understanding these color associations is essential for UX designers aiming to craft experiences that not only look appealing but also resonate emotionally and guide user behavior effectively.

As the EMB Global states, the way we perceive and interpret color is not universal, yet broad patterns of association exist. For instance, the color blue often evokes feelings of trust, stability, and calmness. This association stems from the natural world — the vastness of the sky and the tranquility of deep waters. In the digital space, this makes blue a popular choice for financial institutions, corporate platforms, and interfaces aiming to project reliability and security. However, the specific shade and context matter immensely. A bright, electric blue can feel energetic and modern, while a muted and darker blue might convey a more serious and authoritative tone.

Kendra Cherry, a psychosocial and rehabilitation specialist and author of the book Everything Psychology, explains very well how colors evoke certain responses in us. For example, the color green is intrinsically linked to nature, often bringing about feelings of growth, health, freshness, and tranquility. It can also symbolize prosperity in some cultures. In digital design, green is frequently used for health and wellness applications, environmental initiatives, and platforms emphasizing sustainability. A vibrant lime green can feel energetic and youthful, while a deep forest green can evoke a sense of groundedness and organic quality.

Yellow, the color of sunshine, is generally associated with optimism, happiness, energy, and warmth. It’s attention-grabbing and can create a sense of playfulness. In digital interfaces, yellow is often used for highlighting important information, calls to action (though sparingly, as too much can be overwhelming), or for brands wanting to project a cheerful and approachable image.

Red, a color with strong physiological effects, typically evokes excitement, passion, urgency, and sometimes anger or danger. It commands attention and can stimulate action. Digitally, red is often used for alerts, error messages, sales promotions, or for brands wanting to project a bold and energetic identity. Its intensity requires careful consideration, as overuse can lead to user fatigue or anxiety.

Orange blends the energy of red with the optimism of yellow, often conveying enthusiasm, creativity, and friendliness. It can feel less aggressive than red but still commands attention. In digital design, orange is frequently used for calls to action, highlighting sales or special offers, and for brands aiming to appear approachable and innovative.

Purple has historically been associated with royalty and luxury. It can evoke feelings of creativity, wisdom, and mystery. In digital contexts, purple is often used for brands aiming for a sophisticated or unique feel, particularly in areas like luxury goods, beauty, or spiritual and creative platforms.

Black often signifies sophistication, power, elegance, and sometimes mystery. In digital design, black is frequently used for minimalist interfaces, luxury brands, and for creating strong contrast with lighter elements. The feeling it evokes heavily depends on the surrounding colors and overall design aesthetic.

White is generally associated with purity, cleanliness, simplicity, and neutrality. It provides a sense of spaciousness and allows other colors to stand out. In digital design, white space is a crucial element, and white is often used as a primary background color to create a clean and uncluttered feel.

Gray is often seen as neutral, practical, and sometimes somber or conservative. In digital interfaces, various shades of gray are essential for typography, borders, dividers, and creating visual hierarchy without being overly distracting.

Evoking Emotions In Digital Interfaces

Imagine an elegant furniture application. The designers might choose a primary palette of soft, desaturated blues and greens, accented with gentle earth tones. The muted blues could subtly induce a feeling of calmness and tranquility, aligning with the app’s core purpose of relaxation. The soft greens might evoke a sense of nature and well-being, further reinforcing the theme of peace and mental clarity. The earthy browns could ground the visual experience, creating a feeling of stability and connection to the natural world.

Now, consider a platform for extreme investment enthusiasts. The color palette might be dominated by high-energy oranges and reds, contrasted with stark blacks and sharp whites. The vibrant oranges could evoke feelings of excitement and adventure, while the bold red might amplify the sense of adrenaline and intensity. The black and white could provide a sense of dynamism and modernity, reflecting the fast-paced nature of the activities.

By consciously understanding and applying these color associations, digital designers can move beyond purely aesthetic choices and craft experiences that resonate deeply with users on an emotional level, leading to more engaging, intuitive, and successful digital products.

“

Color As A Usability Tool

Choosing the right colors isn’t about adhering to fleeting trends; it’s about ensuring that our mobile applications and websites are usable by the widest possible audience, including individuals with visual impairments. Improper color choices can create significant barriers, rendering content illegible, interactive elements indistinguishable, and ultimately excluding a substantial portion of potential users.

Prioritizing color with accessibility in mind is not just a matter of ethical design; it’s a fundamental aspect of creating inclusive and user-friendly digital experiences that benefit everyone.

For individuals with low vision, sufficient color contrast between text and background is paramount for readability. Imagine trying to decipher light gray text on a white background — a common design trend that severely hinders those with even mild visual impairments. Adhering to Web Content Accessibility Guidelines (WCAG) contrast ratios ensures that text remains legible and understandable.

Furthermore, color blindness, affecting a significant percentage of the population, necessitates the use of redundant visual cues. Relying solely on color to convey information, such as indicating errors in red without an accompanying text label, excludes colorblind users. By pairing color with text, icons, or patterns, we ensure that critical information is conveyed through multiple sensory channels, making it accessible to all. Thoughtful color selection, therefore, is not an optional add-on but an integral component of designing digital products that are truly usable and equitable.

Choosing Your Palette

As designers, we need a strategic approach to choosing color palettes, considering various factors to build a scalable and impactful color system. Here’s a breakdown of the steps and considerations involved:

1. Deep Dive Into Brand Identity And Main Goals

The journey begins with a thorough understanding of the brand itself. What are its core values? What personality does it project? Is it playful, sophisticated, innovative? Analyze existing brand guidelines (if any), target audience demographics and psychographics, and the overall goals of the digital product. The color palette should be a visual extension of this identity, reinforcing brand recognition and resonating with the intended users. For instance, a financial app aiming for trustworthiness might lean towards blues and greens, while a creative platform could explore more vibrant and unconventional hues.

2. Understand Color Psychology And Cultural Associations

As discussed previously, colors carry inherent psychological and cultural baggage. While these associations are not absolute, they provide a valuable framework for initial exploration. Consider the emotions you want to evoke and research how your target audience might perceive different colors, keeping in mind cultural nuances that can significantly alter interpretations. This step is important to help in making informed decisions that align with the desired user experience and brand perception.

3. Defining The Core Colors

Start by identifying the primary color — the dominant hue that represents your brand’s essence. This will likely be derived from the brand logo or existing visual identity. Next, establish a secondary color or two that complement the primary color and provide visual interest and hierarchy. These secondary colors should work harmoniously with the primary, offering flexibility for different UI elements and interactions.

4. Build A Functional Color System

A consistent and scalable color palette goes beyond just a few base colors. It involves creating a system of variations for practical application within the digital interface. This typically includes tints and shades, accent colors, and neutral colors.

5. Do Not Forget About Usability And Accessibility

Ensure sufficient color contrast between text and background, as well as between interactive elements and their surroundings, to meet WCAG guidelines. Tools are readily available to check color contrast ratios.

Test your palette using color blindness simulators to see how it will be perceived by individuals with different types of color vision deficiencies. This helps identify potential issues where information might be lost due to color alone.

Visual hierarchy is also important to guide the user’s eye and establish a clear visual story. Important elements should be visually distinct.

6. Testing And Iteration

Once you have a preliminary color palette, it’s crucial to test it within the context of your digital product. Create mockups and prototypes to see how the colors work together in the actual interface. Gather feedback from stakeholders and, ideally, conduct user testing to identify any usability or aesthetic issues. Be prepared to iterate and refine your palette based on these insights.

A well-defined color palette for the digital medium should be:

• Consistent,
• Scalable,
• Accessible,
• Brand-aligned,
• Emotionally resonant, and
• Functionally effective.

By following these steps and keeping these considerations in mind, designers can craft color palettes that are not just visually appealing but also strategically powerful tools for creating effective and accessible digital experiences.

Color Consistency: Building Trust And Recognition Through A Harmonized Digital Presence

Consistency plays an important role in the whole color ecosystem. By maintaining a unified color scheme for interactive elements, navigation cues, and informational displays, designers create a seamless and predictable user journey, building trust through visual stability.

Color consistency directly contributes to brand recognition in the increasingly crowded digital landscape. Just as a logo or typeface becomes instantly identifiable, a consistent color palette acts as a powerful visual signature. When users repeatedly encounter the same set of colors associated with a particular brand, it strengthens their recall and fosters a stronger brand association. This visual consistency extends beyond the core interface to marketing materials, social media presence, and all digital touchpoints, creating a cohesive and memorable brand experience. By strategically and consistently applying a solid and consistent color palette, digital products can cultivate stronger brand recognition, build user trust, and enhance user loyalty.

(yk)

Design career origin stories often sound clean and linear: a degree in Fine Arts, a lucky internship, or a first job that launches a linear, upward path. But what about those whose paths were not so straight? The ones who came from service, retail, construction, or even firefighting — the messy, winding paths that didn’t begin right out of design school — who learned service instincts long before learning design tools?

I earned my Associate in Science way later than planned, after 15 years in fine dining, which I once dismissed as a detour delaying my “real” career. But in hindsight, it was anything but. Those years built skills and instincts I still rely on daily — in meetings, design reviews, and messy mid-project pivots.

Your Past Is Your Advantage

I still have the restaurant dream.

Whenever I’m overwhelmed or deep in a deadline, it comes back: I’m the only one running the restaurant floor. The grill is on fire. There’s no clean glassware. Everyone needs their check, their drink, and their table turned. I wake up sweating, and I ask myself, “Why am I still having restaurant nightmares 15 years into a design career?”

Because those jobs wired themselves into how I think and work.

Those years weren’t just a job but high-stakes training in adaptability, anticipation, and grace under pressure. They built muscle memory: ways of thinking, reacting, and solving problems that still appear daily in my design work. They taught me to adapt, connect with people, and move with urgency and grace.

But those same instincts rooted in nightmares can trip you up if you’re unaware. Speed can override thoughtfulness. Constant anticipation can lead to over-complication. The pressure to polish can push you to over-deliver too soon. Embracing your past also means examining it — recognizing when old habits serve you and when they don’t.

With reflection, those experiences can become your greatest advantage.

Lessons From The Line

These aren’t abstract comparisons. They’re instincts built through repetition and real-world pressure, and they show up daily in my design process.

Here are five moments from restaurant life that shaped how I think, design, and collaborate today.

1. Reading The Room

Reading a customer’s mood begins as soon as they sit down. Through years of trial and error, I refined my understanding of subtle cues, like seating delays indicating frustration or menus set aside, suggesting they want to enjoy cocktails. Adapting my approach based on these signals became instinctual, emerging from countless moments of observation.

What I Learned

The subtleties of reading a client aren’t so different in product design. Contexts differ, but the cues remain similar: project specifics, facial expressions, tone of voice, lack of engagement, or even the “word salad” of client feedback. With time, these signals become easier to spot, and you learn to ask better questions, challenge assumptions, or offer alternate approaches before misalignment grows. Whether a client is energized and all-in or hesitant and constrained, reading those cues early can make all the difference.

Those instincts — like constant anticipation and early intervention — served me well in fine dining, but can hinder the design process if I’m not in tune with how I’m reacting. Jumping in too early can lead to over-complicating the design process, solving problems that haven’t been voiced (yet), or stepping on others’ roles. I’ve had to learn to pause, check in with the team, and trust the process to unfold more collaboratively.

How I Apply This Today

• Guide direction with focused options.
  Early on, share 2–3 meaningful variations, like style tiles or small component explorations, to shape the conversation and avoid overwhelm.
• Flag misalignment fast.
  If something feels off, raise it early and loop in the right people.
• Be intentional about workshop and deliverable formats.
  Structure or space? Depends on what helps the client open up and share.
• Pause before jumping in.
  A sticky note on my screen (“Pause”) helps me slow down and check assumptions.

2. Speed Vs. Intentionality

In fine dining, multitasking wasn’t just helpful, it was survival. Every night demanded precision timing, orchestrating every meal step, from the first drink poured to the final dessert plated. The soufflé, for example, was a constant test. It takes precisely 45 minutes — no more, no less. If the guests lingered over appetizers or finished their entrées too early, that soufflé risked collapse.

But fine dining taught me how to handle that volatility. I learned to manage timing proactively, mastering small strategies: an amuse-bouche to buy the kitchen precious minutes, a complimentary glass of champagne to slow a too-quickly paced meal. Multitasking meant constantly adjusting in real-time, keeping a thousand tiny details aligned even when, behind the scenes, chaos loomed.

What I Learned

Multitasking is a given in product design, just in a different form. While the pressure is less immediate, it is more layered as designers often juggle multiple projects, overlapping timelines, differing stakeholder expectations, and evolving product needs simultaneously. That restaurant instinct to keep numerous plates spinning at the same time? It’s how I handle shifting priorities, constant Slack pings, regular Figma updates, and unexpected client feedback — without losing sight of the big picture.

The hustle and pace of fine dining hardwired me to associate speed with success. But in design, speed can sometimes undermine depth. Jumping too quickly into a solution might mean missing the real problem or polishing the wrong idea. I’ve learned that staying in motion isn’t always the goal. Unlike a fast-paced service window, product design invites experimentation and course correction. I’ve had to quiet the internal timer and lean into design with a slower, more intentional nature.

How I Apply This Today

• Make space for inspiration.
  Set aside time for untasked exploration outside the norm — magazines, bookstores, architecture, or gallery visits — before jumping into design.
• Build in pause points.
  Plan breaks between design rounds and schedule reviews after a weekend gap to return with fresh eyes.
• Stay open to starting over.
  Let go of work that isn’t working, even full comps. Starting fresh often leads to better ideas.

3. Presentation Matters

Presentation isn’t just a finishing touch in fine dining — it’s everything. It’s the mint leaf delicately placed atop a dessert, the raspberry glace cascading across the perfectly off-centered espresso cake.

The presentation engages every sense: the smell of rare imported truffles on your truffle fries, or the meticulous choreography of four servers placing entrées in front of diners simultaneously, creating a collective “wow” moment. An excellent presentation shapes diners’ emotional connection with their meal — that experience directly impacts how generously they spend, and ultimately, your success.

What I Learned

A product design presentation, from the initial concept to the handoff, carries that same power. Introducing a new homepage design can feel mechanical or magical, depending entirely on how you frame and deliver it. Just like careful plating shapes a diner’s experience, clear framing and confident storytelling shape how design is received.

Beyond the initial introduction, explain the why behind your choices. Connect patterns to the organic elements of the brand’s identity and highlight how users will intuitively engage with each section. Presentation isn’t just about aesthetics; it helps clients connect with the work, understand its value, and get excited to share it.

The pressure to get everything right the first time, to present a pixel-perfect comp that “wows” immediately, is intense.

Sometimes, an excellent presentation isn’t about perfection — it’s about pacing, storytelling, and allowing the audience to see themselves in the work.

“

I’ve had to let go of the idea that polish is everything and instead focus on the why, describing it with clarity, confidence, and connection.

How I Apply This Today

• Frame the story first.
  Lead with the “why” behind the work before showing the “what”. It sets the tone and invites clients into the design.
• Keep presentations polished.
  Share fewer, more intentional concepts to reduce distractions and keep focus.
• Skip the jargon.
  Clients aren’t designers. Use clear, relatable terms. Say “section” instead of “component,” or “repeatable element” instead of “pattern.”
• Bring designs to life.
  Use motion, prototypes, and real content to add clarity, energy, and brand relevance.

4. Collaboration Is The Backbone

In fine dining, teamwork isn’t just helpful — it’s essential. Every night, success depends entirely on collaboration. The hostess seats guests, the bartender crafts drinks, the chefs prepare dishes, bussers swiftly clear tables, dishwashers provide spotless glasses — each role is critical, and without one, everything falls apart. You quickly learn there’s no ego or question about whether you could do it better alone. You know that teamwork is the only way, which may mean temporarily stepping outside your role to buss your table or jump behind the dishwasher to get clean glasses. Fine dining is truly a well-oiled machine — everyone must trust and rely on one another entirely.

What I Learned

In product design, it’s easier to slip into a silo inadvertently. Unlike restaurants, it can feel natural to work independently, maintaining biases and assumptions, or pushing work forward without additional feedback. But great design thrives on intentional collaboration and shared accountability, especially within an agency setting. Collaborate early, not alone. Actively embracing your support system — joining a UX call even when you’re not officially invited — can give critical insights far before wireframes or comps are developed, helping you ask better questions and make smarter assumptions.

In restaurant service, stepping in unannounced to address an issue was seen as helpful, even necessary. But in design, jumping in without alignment can confuse roles or interrupt someone else’s process. I’ve learned that collaboration isn’t about taking over but staying connected. I’ve had to get better at asking before helping, syncing instead of assuming, and treating the handoff not as an ending but as an open communication thread.

How I apply This Today

• Stay involved after handoff.
  Check in during engineering and QA (quality assurance) to support implementation.
• Keep workshops flexible.
  Adjust structure based on the client’s energy and decision-making style.
• Invite a fresh perspective.
  Bring in another designer near the end for polish or feedback.
• Capture intent visually.
  Document decisions clearly so downstream teams understand the nuances and not just the layout.

5. Composure Under Pressure

In fine dining, pressure isn’t an occasional event — it’s the default setting. Every night is high stakes. Timing is tight, expectations are sky-high, and mistakes are rarely forgiven. Composure becomes your edge. You don’t show panic when the kitchen is backed up or when a guest sends a dish back mid-rush. You pivot. You delegate. You anticipate. Some nights, the only thing that kept things on track was staying calm and thinking clearly.

“This notion of problem solving and decision making is key to being a great designer. I think that we need to get really strong at problem identification and then prioritization. All designers are good problem solvers, but the really great designers are strong problem finders.”

— Jason Cyr, “How being a firefighter made me a better designer thinker”

What I Learned

The same principle applies to product design. When pressure mounts — tight timelines, conflicting feedback, or unclear priorities — your ability to stay composed can shift the energy of the entire project.

Composure isn’t just about being calm; it’s about being adaptable and responsive without reacting impulsively. It helps you hold space for feedback, ask better questions, and move forward with clarity instead of chaos.

There have also been plenty of times when a client doesn’t resonate with a design, which can feel crushing. You can easily take it personally and internalize the rejection, or you can pause, listen, and course-correct. I’ve learned to focus on understanding the root of the feedback. Often, what seems like a rejection is just discomfort with a small detail, which in most cases can be easily corrected.

Perfection was the baseline in restaurants, and pressure drove polish. In design, that mindset can lead to overinvesting in perfection too soon or “freezing” under critique. I’ve had to unlearn that success means getting everything right the first time. Now I see messy collaboration and gradual refinement as a mark of success, not failure.

How I Apply This Today

• Use live design to unblock.
  When timelines are tight and feedback goes in circles, co-designing in real time helps break through stuck points and move forward quickly.
• Turn critique into clarity.
  Listen for what’s underneath the feedback, then ask clarifying questions, or repeat back what you’re hearing to align before acting.
• Pause when stress builds.
  If you feel reactive, take a moment to regroup before responding.
• Frame changes as progress.
  Normalize iteration as part of the process, and not a design failure.

Would I Go Back?

I still dream about the restaurant floor. But now, I see it as a reminder — not of where I was stuck, but of where I perfected the instincts I use today. If you’re someone who came to design from another path, try asking yourself:

• When do I feel strangely at ease while others panic?
• What used to feel like “just part of the job,” but now feels like a superpower?
• Where do I get frustrated because my instincts are different — and maybe sharper?
• What kinds of group dynamics feel easy to me that others struggle with?
• What strengths would not exist in me today if I hadn’t lived that past life?

Once you see the patterns, start using them.

Name your edge. Talk about your background as an asset: in intros, portfolios, interviews, or team retrospectives. When projects get messy, lean into what you already know how to do. Trust your instincts. They’re real, and they’re earned. But balance them, too. Stay aware of when your strengths could become blind spots, like speed overriding thoughtfulness. That kind of awareness turns experience into a tool, not a trigger.

Your past doesn’t need to look like anyone else’s. It just needs to teach you something.

“

Further Reading

• “If I Was Starting My Career Today: Thoughts After 15 Years Spent In UX Design” (Part One, Part Two), by Andrii Zhdan (Smashing Magazine)
  In this two-part series, Andrii Zhdan outlines common challenges faced at the start of a design career and offers advice to smooth your journey based on insights from his experience hiring designers.
• “Overcoming Imposter Syndrome By Developing Your Own Guiding Principles,” by Luis Ouriach (Smashing Magazine)
  Unfortunately, not everyone has access to a mentor or a guide at the start of the design career, which is why we often have to rely on “working it out” by ourselves. In this article, Luis Ouriach tries to help you in this task so that you can walk into the design critique meetings with more confidence and really deliver the best representation of your ideas.
• “Why Designers Get Stuck In The Details And How To Stop,” by Nikita Samutin (Smashing Magazine)
  Designers love to craft, but polishing pixels before the problem is solved is a time sink. This article pinpoints the five traps that lure us into premature detail and then hands you a rescue plan to refocus on goals, ship faster, and keep your craft where it counts.
• “Rediscovering The Joy Of Design,” by Pratik Joglekar (Smashing Magazine)
  Pratik Joglekar takes a philosophical approach to remind designers about the lost joy within themselves by effectively placing massive importance on mindfulness, introspection, and forward-looking.
• “Lessons Learned As A Designer-Founder,” by Dave Feldman (Smashing Magazine)
  In this article, Dave Feldman shares his lessons learned and the experiments he has done as a multidisciplinary designer-founder-CEO at an early-stage startup.
• “How Designers Should Ask For (And Receive) High-Quality Feedback,” by Andy Budd (Smashing Magazine)
  Designers often complain about the quality of feedback they get from senior stakeholders without realizing it’s usually because of the way they initially have framed the request. In this article, Andy Budd shares a better way of requesting feedback: rather than sharing a linear case study that explains every design revision, the first thing to do would be to better frame the problem.
• “How being a Firefighter made me a better Designer Thinker“ by Jason Cyr (Medium)
  The ability to come upon a situation and very quickly start evaluating information, asking questions, making decisions, and formulating a plan is a skill that every firefighter learns to develop, especially as you rise through the ranks and start leading others.
• “Advice for making the most of an indirect career path to design,” by Heidi Meredith (Adobe Express Growth)
  I didn’t know anything about design until after I graduated from the University of California, Santa Cruz, with a degree in English Literature/Creative Writing. A mere three months into it, though, I realized I didn’t want to write books — I wanted to design them.

I want to express my deep gratitude to Sara Wachter-Boettcher, whose coaching helped me find the clarity and confidence to write this piece — and, more importantly, to move forward with purpose in both life and work. And to Lea Alcantara, my design director at Fueled, for being a steady creative force and an inspiring example of thoughtful leadership.

(mb, yk)

AI is almost everywhere — it writes text, makes music, generates code, draws pictures, runs research, chats with you — and apparently even understands people better than they understand themselves?!

It’s a lot to take in. The pace is wild, and new tools pop up faster than anyone has time to try them. Amid the chaos, one thing is clear: this isn’t hype, but it’s structural change.

According to the Future of Jobs Report 2025 by the World Economic Forum, one of the fastest-growing, most in-demand skills for the next five years is the ability to work with AI and Big Data. That applies to almost every role — including product design.

What do companies want most from their teams? Right, efficiency. And AI can make people way more efficient. We’d easily spend 3x more time on tasks like replying to our managers without AI helping out. We’re learning to work with it, but many of us are still figuring out how to meet the rising bar.

That’s especially important for designers, whose work is all about empathy, creativity, critical thinking, and working across disciplines. It’s a uniquely human mix. At least, that’s what we tell ourselves.

Even as debates rage about AI’s limitations, tools today (June 2025 — timestamp matters in this fast-moving space) already assist with research, ideation, and testing, sometimes better than expected.

Of course, not everyone agrees. AI hallucinates, loses context, and makes things up. So how can both views exist at the same time? Very simple. It’s because both are true: AI is deeply flawed and surprisingly useful. The trick is knowing how to work with its strengths while managing its weaknesses. The real question isn’t whether AI is good or bad — it’s how we, as designers, stay sharp, stay valuable, and stay in the loop.

Why Prompting Matters

Prompting matters more than most people realize because even small tweaks in how you ask can lead to radically different outputs. To see how this works in practice, let’s look at a simple example.

Imagine you want to improve the onboarding experience in your product. On the left, you have the prompt you send to AI. On the right, the response you get back.

This side-by-side shows just how much even the smallest prompt details can change what AI gives you.

Talking to an AI model isn’t that different from talking to a person. If you explain your thoughts clearly, you get a better understanding and communication overall.

Advanced prompting is about moving beyond one-shot, throwaway prompts. It’s an iterative, structured process of refining your inputs using different techniques so you can guide the AI toward more useful results. It focuses on being intentional with every word you put in, giving the AI not just the task but also the path to approach it step by step, so it can actually do the job.

Where basic prompting throws your question at the model and hopes for a quick answer, advanced prompting helps you explore options, evaluate branches of reasoning, and converge on clear, actionable outputs.

But that doesn’t mean simple prompts are useless. On the contrary, short, focused prompts work well when the task is narrow, factual, or time-sensitive. They’re great for idea generation, quick clarifications, or anything where deep reasoning isn’t required. Think of prompting as a scale, not a binary. The simpler the task, the faster a lightweight prompt can get the job done. The more complex the task, the more structure it needs.

In this article, we’ll dive into how advanced prompting can empower different product & design use cases, speeding up your workflow and improving your results — whether you’re researching, brainstorming, testing, or beyond. Let’s dive in.

Practical Cases

In the next section, we’ll explore six practical prompting techniques that we’ve found most useful in real product design work. These aren’t abstract theories — each one is grounded in hands-on experience, tested across research, ideation, and evaluation tasks. Think of them as modular tools: you can mix, match, and adapt them depending on your use case. For each, we’ll explain the thinking behind it and walk through a sample prompt.

Important note: The prompts you’ll see are not copy-paste recipes. Some are structured templates you can reuse with small tweaks; others are more specific, meant to spark your thinking. Use them as scaffolds, not scripts.

1. Task Decomposition By JTBD

Technique: Role, Context, Instructions template + Checkpoints (with self-reflection)

Before solving any problem, there’s a critical step we often overlook: breaking the problem down into clear, actionable parts.

Jumping straight into execution feels fast, but it’s risky. We might end up solving the wrong thing, or solving it the wrong way. That’s where GPT can help: not just by generating ideas, but by helping us think more clearly about the structure of the problem itself.

There are many ways to break down a task. One of the most useful in product work is the Jobs To Be Done (JTBD) framework. Let’s see how we can use advanced prompting to apply JTBD decomposition to any task.

Good design starts with understanding the user, the problem, and the context. Good prompting? Pretty much the same. That’s why most solid prompts include three key parts: Role, Context, and Instructions. If needed, you can also add the expected format and any constraints.

In this example, we’re going to break down a task into smaller jobs and add self-checkpoints to the prompt, so the AI can pause, reflect, and self-verify along the way.

Role
Act as a senior product strategist and UX designer with deep expertise in Jobs To Be Done (JTBD) methodology and user-centered design. You think in terms of user goals, progress-making moments, and unmet needs — similar to approaches used at companies like Intercom, Basecamp, or IDEO.

Context
You are helping a product team break down a broad user or business problem into a structured map of Jobs To Be Done. This decomposition will guide discovery, prioritization, and solution design.

Task & Instructions
[👉 DESCRIBE THE USER TASK OR PROBLEM 👈🏼]
Use JTBD thinking to uncover:

• The main functional job the user is trying to get done;
• Related emotional or social jobs;
• Sub-jobs or tasks users must complete along the way;
• Forces of progress and barriers that influence behavior.

Checkpoints
Before finalizing, check yourself:

• Are the jobs clearly goal-oriented and not solution-oriented?
• Are sub-jobs specific steps toward the main job?
• Are emotional/social jobs captured?
• Are user struggles or unmet needs listed?

If anything’s missing or unclear, revise and explain what was added or changed.

With a simple one-sentence prompt, you’ll likely get a high-level list of user needs or feature ideas. An advanced approach can produce a structured JTBD breakdown of a specific user problem, which may include:

• Main Functional Job: A clear, goal-oriented statement describing the primary outcome the user wants to achieve.
• Emotional & Social Jobs: Supporting jobs related to how the user wants to feel or be perceived during their progress.
• Sub-Jobs: Step-by-step tasks or milestones the user must complete to fulfill the main job.
• Forces of Progress: A breakdown of motivations (push/pull) and barriers (habits/anxieties) that influence user behavior.

But these prompts are most powerful when used with real context. Try it now with your product. Even a quick test can reveal unexpected insights.

2. Competitive UX Audit

Technique: Attachments + Reasoning Before Understanding + Tree of Thought (ToT)

Sometimes, you don’t need to design something new — you need to understand what already exists.

Whether you’re doing a competitive analysis, learning from rivals, or benchmarking features, the first challenge is making sense of someone else’s design choices. What’s the feature really for? Who’s it helping? Why was it built this way?

Instead of rushing into critique, we can use GPT to reverse-engineer the thinking behind a product — before judging it. In this case, start by:

1. Grabbing the competitor’s documentation for the feature you want to analyze.
2. Save it as a PDF. Then head over to ChatGPT (or other models).
3. Before jumping into the audit, ask it to first make sense of the documentation. This technique is called Reasoning Before Understanding (RBU). That means before you ask for critique, you ask for interpretation. This helps AI build a more accurate mental model — and avoids jumping to conclusions.

Role
You are a senior UX strategist and cognitive design analyst. Your expertise lies in interpreting digital product features based on minimal initial context, inferring purpose, user intent, and mental models behind design decisions before conducting any evaluative critique.

Context
You’ve been given internal documentation and screenshots of a feature. The goal is not to evaluate it yet, but to understand what it’s doing, for whom, and why.

Task & Instructions
Review the materials and answer:

• What is this feature for?
• Who is the intended user?
• What tasks or scenarios does it support?
• What assumptions does it make about the user?
• What does its structure suggest about priorities or constraints?

Once you get the first reply, take a moment to respond: clarify, correct, or add nuance to GPT’s conclusions. This helps align the model’s mental frame with your own.

For the audit part, we’ll use something called the Tree of Thought (ToT) approach.

Tree of Thought (ToT) is a prompting strategy that asks the AI to “think in branches.” Instead of jumping to a single answer, the model explores multiple reasoning paths, compares outcomes, and revises logic before concluding — like tracing different routes through a decision tree. This makes it perfect for handling more complex UX tasks.

You are now performing a UX audit based on your understanding of the feature. You’ll identify potential problems, alternative design paths, and trade-offs using a Tree of Thought approach, i.e., thinking in branches, comparing different reasoning paths before concluding.

or

Convert your understanding of the feature into a set of Jobs-To-Be-Done statements from the user’s perspective using a Tree of Thought approach.

List implicit assumptions this feature makes about the user's behavior, workflow, or context using a Tree of Thought approach.

Propose alternative versions of this feature that solve the same job using different interaction or flow mechanics using a Tree of Thought approach.

3. Ideation With An Intellectual Opponent

Technique: Role Conditioning + Memory Update

When you’re working on creative or strategic problems, there’s a common trap: AI often just agrees with you or tries to please your way of thinking. It treats your ideas like gospel and tells you they’re great — even when they’re not.

So how do you avoid this? How do you get GPT to challenge your assumptions and act more like a critical thinking partner? Simple: tell it to and ask to remember.

Instructions
From now on, remember to follow this mode unless I explicitly say otherwise.

Do not take my conclusions at face value. Your role is not to agree or assist blindly, but to serve as a sharp, respectful intellectual opponent.

Every time I present an idea, do the following:

• Interrogate my assumptions: What am I taking for granted?
• Present counter-arguments: Where could I be wrong, misled, or overly confident?
• Test my logic: Is the reasoning sound, or are there gaps, fallacies, or biases?
• Offer alternatives: Not for the sake of disagreement, but to expand perspective.
• Prioritize truth and clarity over consensus: Even when it’s uncomfortable.

Maintain a constructive, rigorous, truth-seeking tone. Don’t argue for the sake of it. Argue to sharpen thought, expose blind spots, and help me reach clearer, stronger conclusions.

This isn’t a debate. It’s a collaboration aimed at insight.

4. Requirements For Concepting

Technique: Requirement-Oriented + Meta prompting

This one deserves a whole article on its own, but let’s lay the groundwork here.

When you’re building quick prototypes or UI screens using tools like v0, Bolt, Lovable, UX Pilot, etc., your prompt needs to be better than most PRDs you’ve worked with. Why? Because the output depends entirely on how clearly and specifically you describe the goal.

The catch? Writing that kind of prompt is hard. So instead of jumping straight to the design prompt, try writing a meta-prompt first. That is a prompt that asks GPT to help you write a better prompt. Prompting about prompting, prompt-ception, if you will.

Here’s how to make that work: Feed GPT what you already know about the app or the screen. Then ask it to treat things like information architecture, layout, and user flow as variables it can play with. That way, you don’t just get one rigid idea — you get multiple concept directions to explore.

Role
You are a product design strategist working with AI to explore early-stage design concepts.

Goal
Generate 3 distinct prompt variations for designing a Daily Wellness Summary single screen in a mobile wellness tracking app for Lovable/Bolt/v0.

Each variation should experiment with a different Information Architecture and Layout Strategy. You don’t need to fully specify the IA or layout — just take a different angle in each prompt. For example, one may prioritize user state, another may prioritize habits or recommendations, and one may use a card layout while another uses a scroll feed.

User context
The target user is a busy professional who checks this screen once or twice a day (morning/evening) to log their mood, energy, and sleep quality, and to receive small nudges or summaries from the app.

Visual style
Keep the tone calm and approachable.

Format
Each of the 3 prompt variations should be structured clearly and independently.

Remember: The key difference between the three prompts should be the underlying IA and layout logic. You don’t need to over-explain — just guide the design generator toward different interpretations of the same user need.

5. From Cognitive Walkthrough To Testing Hypothesis

Technique: Casual Tree of Though + Casual Reasoning + Multi-Roles + Self-Reflection

Cognitive walkthrough is a powerful way to break down a user action and check whether the steps are intuitive.

Example: “User wants to add a task” → Do they know where to click? What to do next? Do they know it worked?

We’ve found this technique super useful for reviewing our own designs. Sometimes there’s already a mockup; other times we’re still arguing with a PM about what should go where. Either way, GPT can help.

Here’s an advanced way to run that process:

Context
You’ve been given a screenshot of a screen where users can create new tasks in a project management app. The main action the user wants to perform is “add a task”. Simulate behavior from two user types: a beginner with no prior experience and a returning user familiar with similar tools.

Task & Instructions
Go through the UI step by step and evaluate:

1. Will the user know what to do at each step?
2. Will they understand how to perform the action?
3. Will they know they’ve succeeded?

For each step, consider alternative user paths (if multiple interpretations of the UI exist). Use a casual Tree-of-Thought method.

At each step, reflect: what assumptions is the user making here? What visual feedback would help reduce uncertainty?

Format
Use a numbered list for each step. For each, add observations, possible confusions, and UX suggestions.

Limits
Don’t assume prior knowledge unless it’s visually implied.
Do not limit analysis to a single user type.

Cognitive walkthroughs are great, but they get even more useful when they lead to testable hypotheses.

After running the walkthrough, you’ll usually uncover moments that might confuse users. Instead of leaving that as a guess, turn those into concrete UX testing hypotheses.

We ask GPT to not only flag potential friction points, but to help define how we’d validate them with real users: using a task, a question, or observable behavior.

Task & Instructions
Based on your previous cognitive walkthrough:

1. Extract all potential usability hypotheses from the walkthrough.
2. For each hypothesis:
   • Assess whether it can be tested through moderated or unmoderated usability testing.
   • Explain what specific UX decision or design element may cause this issue. Use causal reasoning.
   • For testable hypotheses:
     • Propose a specific usability task or question.
     • Define a clear validation criterion (how you’ll know if the hypothesis is confirmed or disproved).
     • Evaluate feasibility and signal strength of the test (e.g., how easy it is to test, and how confidently it can validate the hypothesis).
     • Assign a priority score based on Impact, Confidence, and Ease (ICE).

Limits
Don’t invent hypotheses not rooted in your walkthrough output. Only propose tests where user behavior or responses can provide meaningful validation. Skip purely technical or backend concerns.

6. Cross-Functional Feedback

Technique: Multi-Roles

Good design is co-created. And good designers are used to working with cross-functional teams: PMs, engineers, analysts, QAs, you name it. Part of the job is turning scattered feedback into clear action items.

Earlier, we talked about how giving AI a “role” helps sharpen its responses. Now let’s level that up: what if we give it multiple roles at once? This is called multi-role prompting. It’s a great way to simulate a design review with input from different perspectives. You get quick insights and a more well-rounded critique of your design.

Role
You are a cross-functional team of experts evaluating a new dashboard design:

• PM (focus: user value & prioritization)
• Engineer (focus: feasibility & edge cases)
• QA tester (focus: clarity & testability)
• Data analyst (focus: metrics & clarity of reporting)
• Designer (focus: consistency & usability)

Context
The team is reviewing a mockup for a new analytics dashboard for internal use.

Task & Instructions
For each role:

1. What stands out immediately?
2. What concerns might this role have?
3. What feedback or suggestions would they give?

Designing With AI Is A Skill, Not A Shortcut

By now, you’ve seen that prompting isn’t just about typing better instructions. It’s about designing better thinking.

We’ve explored several techniques, and each is useful in different contexts:

But even the best techniques won’t matter if you use them blindly, so ask yourself:

• Do I need precision or perspective right now?
  • Precision? Try Role + Checkpoints for clarity and control.
  • Perspective? Use Multi-Role or Tree of Thought to explore alternatives.
• Should the model reflect my framing, or break it?
  • Reflect it? Use Role + Context + Instructions.
  • Break it? Try Opponent prompting to challenge assumptions.
• Am I trying to reduce ambiguity, or surface complexity?
  • Reduce ambiguity? Use Meta-prompting to clarify your ask.
  • Surface complexity? Go with ToT or RBU to expose hidden layers.
• Is this task about alignment, or exploration?
  • Alignment? Use Multi-Roles prompting to simulate consensus.
  • Exploration? Use Cognitive Walkthrough to push deeper.

Remember, you don’t need a long prompt every time. Use detail when the task demands it, not out of habit. AI can do a lot, but it reflects the shape of your thinking. And prompting is how you shape it. So don’t just prompt better. Think better. And design with AI — not around it.

(yk)