AI can now turn a design idea into a working interface surprisingly quickly. You can describe a dashboard, ask for interactions, connect sample data, and have something functional without writing every line of code yourself.
So, should product designers still learn to code?
Yes. But not because every designer needs to become a software engineer.
Designers should understand enough code to evaluate what they build, collaborate effectively with engineers, and recognize technical limitations. They should also learn how to use AI-assisted development tools. But neither skill replaces the ability to understand a problem and make good product decisions.
I wanted to explore that distinction beyond another opinion about designers learning JavaScript.
So I used a fictional sales dashboard as a design-to-code experiment. The starting interface was a conventional CRM with metrics, filters, and a lead table. The revised concept took a different approach: instead of primarily organizing lead records, it focused on helping a sales representative identify what needed attention and what to do next.
The comparison revealed something more interesting than whether AI can generate attractive UI.
A working interface and a useful product experience are not necessarily the same thing.
AI has changed what designers can build independently
Not long ago, testing a complex interaction often required several connected design frames, a specialized prototyping tool, or support from an engineer.
AI-assisted coding has made it easier to build realistic interfaces during exploration.
A designer can now create a working dashboard, experiment with filtering behavior, test navigation patterns, or demonstrate a multi-step flow without waiting for a full development cycle.
That is valuable, especially when teams need to evaluate an idea before committing significant engineering resources.
But there's a catch.
When something becomes easier to build, it also becomes easier to build without thinking deeply enough about why it should exist.
A dashboard with cards, charts, filters, and tables can look complete. It can respond to clicks. It can contain realistic sample data.
None of that automatically tells us whether it helps someone do their job.
And that distinction matters more as the cost of generating interfaces continues to fall.
The experiment: from a lead dashboard to a priority workspace
For this experiment, I compared two versions of a fictional B2B sales workspace called Northstar.
The initial interface followed a familiar CRM pattern. It had a sidebar, pipeline metrics, a searchable list of leads, status badges, owners, deal values, and recent activity.
It wasn't an unreasonable design.
In fact, it included many elements you would expect from a lead-management dashboard.
The problem was that it primarily presented information without making the user's next decision particularly clear.
Consider the first lead in the table.
Alba Health had a proposal-stage deal worth $48,000. Its last recorded activity was six days earlier.
That information was visible. But what should the sales representative do with it?
Should they follow up immediately? Is the deal waiting on an internal review? Has the prospect requested more time? Is another lead more urgent?
The interface left those questions largely unanswered.
The revised design started from a different product question:
What does a sales representative need to know to decide where to spend their attention today?
That shift changed the structure of the experience.
Instead of treating all leads as equivalent rows, the new interface introduced a priority workspace, contextual explanations, recommended actions, and a detailed lead panel.
The goal wasn't simply to make the dashboard look more premium.
It was to make the information more actionable.
Finding 1: Showing information isn't the same as supporting decisions
The original dashboard displayed useful information: deal values, stages, ownership, and last activity.
But those details were distributed across a conventional table.
The user had to interpret the data and decide what deserved attention.
The revised dashboard introduced a dedicated Needs attention view.
Rather than showing only the lead's stage, it explains why the record may require action.
For example:
- Alba Health: proposal idle for six days.
- Vela Studio: no response for five days.
- North & Co.: decision date approaching in three days.
Each record also includes a suggested next step.
Alba Health needs a revised proposal. Vela Studio needs a follow-up call. North & Co. needs pricing options.
This is a meaningful product-design change because it connects information to a potential action.
The interface moves from answering "What leads do we have?" toward answering "Which lead should I work on, and why?"
However, prioritization introduces new responsibilities.
The system must have a defensible reason for placing one lead above another. A six-day-old proposal is not automatically more urgent than a deal approaching its deadline.
In a real product, those rules would need to account for business priorities, customer commitments, due dates, and available evidence.
The prototype demonstrates a proposed interaction model, not a validated prioritization algorithm.
That's an important distinction.
Product design doesn't end when an interface makes a recommendation. Someone still needs to determine whether that recommendation is appropriate.
Finding 2: A dashboard becomes more useful when context and action stay connected
The original interface offered a More link for each lead.
That pattern is familiar, but it doesn't communicate what the user will find or what they should do next.
The revised interface brings relevant context into a side panel.
Selecting Alba Health reveals its deal stage, value, owner, close date, activity history, and an explanation of why the lead needs attention.
It also presents a recommended next step: send a revised proposal.
The design includes a due-date field and actions to defer or mark the task complete.
This creates a clearer relationship between the lead's situation and the action being proposed.
Instead of asking the user to interpret a row, open another view, find the relevant context, and decide what to do, the interface brings those pieces closer together.
That doesn't mean every CRM should use a side panel.
A side panel can become crowded. It can also create accessibility and responsive-design challenges, especially on smaller screens.
The point is that the information architecture now reflects the task more directly.
The experience is organized around reviewing a lead and deciding what to do next, rather than simply browsing a collection of records.
Whether that improves task completion or reduces time spent navigating would require usability testing.
But the design rationale is clear and testable.
Finding 3: Better UI requires decisions about the product's behavior
The most significant difference between the two versions isn't the typography, spacing, or visual polish.
It's the number of product decisions made explicit in the revised interface.
The initial version had a conventional set of features: search, filters, selection, and export.
The revised version introduces a more opinionated workflow.
It distinguishes leads that need attention from the complete lead list. It proposes a priority order. It explains why a record is flagged. It offers a next action and a way to record progress.
Each of those choices creates questions that the product team must answer.
What qualifies as needing attention?
Should a lead disappear from the priority list when its task is completed?
What happens if the recommended action is wrong?
Can a user override the recommendation?
Does deferring a task change its priority?
How should multiple team members see updates to the same record?
These aren't visual-design questions alone.
They involve product requirements, state management, business rules, data modeling, and interaction design.
An AI coding assistant can help implement the resulting behavior. But the team still needs to define what correct behavior means.
That's where technical understanding and product judgment meet.
A designer who understands application state can ask how task completion affects the interface.
A designer who understands data dependencies can ask where the recommendation comes from.
A designer who understands accessibility can consider whether the lead panel and its controls work with keyboard navigation and assistive technology.
The more capable AI becomes at producing interfaces, the more valuable these questions become.
What the experiment does and doesn't prove
The two Northstar designs demonstrate a clear change in product direction.
The first organizes lead information. The second proposes a workflow centered on attention, context, and action.
That makes the revised design a stronger expression of a specific product hypothesis.
It does not prove that users would perform better with it.
No user study, task-completion benchmark, or production deployment has been established by these screenshots.
A proper evaluation would involve representative sales users completing the same tasks in both versions.
For example, participants could be asked to identify the most urgent lead, explain why it matters, find the relevant context, and record an appropriate next step.
We could then compare task success, time, errors, and confidence, while also observing whether the revised prioritization creates confusion or encourages overreliance on recommendations.
The purpose of the experiment is not to claim that one screenshot wins.
It's to show how a different understanding of the user's problem can change the product being designed.
Understanding code is different from becoming an engineer
When people advise designers to learn coding, they often jump straight to programming languages and frameworks.
HTML, CSS, JavaScript, React.
Those skills can be useful. But the value depends on what the designer needs to accomplish.
For most product designers, technical literacy is a sensible starting point.
Understand how interfaces are structured, how responsive layouts work, how components behave, and how application state changes after an interaction.
Learn what APIs do, why data can fail to load, and why authentication and permissions affect the experience.
Understand the basics of semantic HTML and accessibility.
These fundamentals help designers communicate with engineers and recognize when an apparently simple feature has deeper implications.
Take the revised Northstar interface.
A designer doesn't need to implement its entire backend to ask what happens when someone marks a recommended action as complete.
But understanding state and data flow helps them recognize that the answer matters.
Should the task disappear? Should the lead's activity history update? Should the next recommendation change?
Technical literacy makes those questions easier to anticipate.
It also helps designers evaluate AI-generated code instead of treating the output as a black box.
AI-assisted development is a different capability
Knowing code and building with AI overlap, but they aren't the same skill.
Working effectively with AI development tools involves defining requirements, breaking problems into manageable pieces, evaluating output, and iterating with intention.
A prompt such as "Build a modern CRM dashboard" can generate a plausible interface.
A more thoughtful specification explains who uses the product, what decisions they need to make, what information supports those decisions, and how the interface should behave under different conditions.
The difference isn't just prompt-writing technique.
It's product thinking expressed through implementation requirements.
For example, asking for a priority list is relatively straightforward.
Defining how priorities are calculated, when they change, how users override them, and how those decisions are communicated is considerably more demanding.
AI can assist with the implementation.
It can also help explore alternatives and identify potential edge cases.
But designers need enough understanding to evaluate the suggestions and recognize when the tool has made assumptions.
This is why I don't think learning AI-assisted development eliminates the value of coding fundamentals.
The two capabilities reinforce each other.
The more you understand about how software works, the more effectively you can inspect, debug, and improve what AI generates.
The skill that becomes harder to replace is product judgment
There's a risk in focusing too heavily on how quickly AI can generate an interface.
Speed is useful, but only when it helps teams make progress toward something worthwhile.
Imagine spending an afternoon generating five beautiful dashboards.
Each has different layouts, cards, charts, and interactions.
Which one should the team build?
The answer can't come from visual polish alone.
It depends on the users, their tasks, the business context, the available data, and the trade-offs the team is willing to make.
In the Northstar example, the most important design decision wasn't changing the visual style.
It was shifting the primary experience from managing a list of leads to deciding what deserves attention.
That decision changes which information is prominent, which interactions matter, and which behaviors need to be implemented.
AI can help explore that direction. It can even suggest it.
But someone still needs to evaluate whether it solves a meaningful problem.
Being able to build more possibilities doesn't remove the responsibility to choose carefully.
What should product designers actually learn?
I would approach this in three layers.
First, understand how interfaces work
Learn the fundamentals of HTML, CSS, and JavaScript.
Understand responsive layouts, interaction states, accessibility, APIs, and basic data flow.
The goal isn't to become an expert in every technology. It's to understand the medium well enough to make informed design decisions.
Second, become comfortable building with AI
Choose an AI-assisted development workflow and use it to build small, functional prototypes.
Don't stop when the interface looks convincing.
Test the interactions. Try unexpected inputs. Resize the layout. Inspect error states. Check keyboard behavior.
When something fails, investigate the reason rather than endlessly regenerating the interface.
Learn to distinguish a working demonstration from a production-ready implementation.
Third, strengthen your product judgment
Spend time understanding user needs, business constraints, prioritization, research methods, and evaluation.
Practice defining a problem before proposing an interface.
Learn to recognize when a feature request is actually a symptom of a deeper issue.
And become comfortable explaining not only what you've designed, but why you made those decisions and what evidence would change your mind.
These skills make technical capability more useful.
Should junior and senior designers learn coding differently?
The fundamentals are relevant at every experience level, but the priorities may differ.
For junior designers, coding literacy can help connect design decisions to implementation reality. Building small interfaces is a useful way to understand responsive behavior, component states, and technical constraints.
But a polished AI-generated portfolio project isn't enough on its own.
A strong case study should explain the problem, assumptions, decisions, and evaluation.
For senior designers and design leads, AI-assisted development can make exploration and communication more independent.
It can help demonstrate complicated interactions, investigate feasibility, and give stakeholders something concrete to discuss.
The value is not simply producing more prototypes.
It's using those prototypes to make better decisions and reduce uncertainty.
For designers interested in design engineering or building their own software products, deeper programming knowledge may be essential.
Frameworks, application architecture, testing, version control, and backend fundamentals become more important when you're responsible for maintaining the product, not just exploring an idea.
There isn't one technical learning path that suits every designer.
The right depth depends on the work you want to do.
So, should product designers learn to code?
Yes.
But I wouldn't make coding the new definition of a good product designer.
Learn enough to understand the systems you're designing. Use AI-assisted development to explore ideas, communicate behavior, and test assumptions more independently.
Go deeper into engineering when your responsibilities or ambitions require it.
And don't confuse the ability to generate a convincing interface with the ability to design a useful product.
The Northstar experiment began with a dashboard that organized information. The revised concept focused on helping someone decide what needed attention and what to do next.
That shift required more than better code or visual polish.
It required a clearer understanding of the user's job, the decisions the product should support, and the behavior needed to make those decisions actionable.
AI can help build the interface.
Knowing what the interface should help someone accomplish is still the harder question.
About the experiment
Northstar is a fictional B2B sales workspace created for this article. The comparison examines two interface designs and the product decisions visible in them. It is an illustrative design-to-code experiment, not a controlled benchmark or a usability study.