DEV Community: nireadaddy

UX UI Designer Salary in Thailand 2026: A Complete Career Guide by Experience Level

nireadaddy — Sun, 15 Mar 2026 11:00:32 +0000

The Salary Question Nobody Answers Directly

In the UX design community in Thailand, compensation remains one of the most frequently asked yet poorly answered questions. Job postings rarely list salary ranges. Peers hesitate to share numbers. HR departments deflect with "it depends on experience."

Having spent over 15 years in UX career paths -- from the era when "web designer" was the closest title we had, through to managing UX teams at the enterprise level -- I have seen compensation data across hundreds of roles. My own career, my team members, candidates I have interviewed, and professionals who have sought career advice have all contributed to a reasonably clear picture of what a UX designer or UI UX designer earns in Thailand.

This article provides concrete salary ranges, the factors that actually move the needle, and practical strategies for maximizing your earning potential.

UX UI Designer Salary Ranges by Level in Thailand

The figures below reflect market rates observed in medium to large organizations based in Bangkok, covering in-house product teams, agencies, and consultancies. Salaries outside Bangkok tend to be 15-25% lower.

Junior UX/UI Designer (0-2 years)

Salary range: 18,000 - 35,000 THB/month

At this level, the salary spread is driven almost entirely by portfolio quality and the ability to articulate design decisions. A candidate with a strong portfolio and bootcamp training can start at 25,000-30,000 THB, while those with weaker portfolios may begin at 18,000-22,000 THB. Academic credentials have minimal impact compared to demonstrated capability.

Mid-level UX/UI Designer (2-5 years)

Salary range: 35,000 - 60,000 THB/month

This is the stage where many designers feel stuck. Annual raises of 5-8% at the same company yield slow growth. Those who break past the 50,000 THB threshold typically possess strong research skills or work within product teams where they own specific metrics. Execution-only designers -- those who work strictly from briefs without contributing to product strategy -- tend to plateau here.

Senior UX/UI Designer (5-8 years)

Salary range: 60,000 - 100,000 THB/month

The Senior level reveals a clear divergence between "senior by tenure" and "senior by capability." Designers earning 80,000 THB and above at this level can typically lead projects end-to-end, manage stakeholder relationships, and translate business requirements into design strategy. Technical craft alone is insufficient; strategic thinking becomes the differentiator.

Lead / Principal Designer (8-12 years)

Salary range: 90,000 - 150,000 THB/month

The Lead or Principal title is not yet widespread in Thailand. Many organizations jump directly from Senior to Manager. However, companies with higher design maturity maintain this track for exceptional individual contributors who prefer depth of craft over people management. At this level, the expectation is that you set design direction for the entire team or product area.

UX Manager / Head of Design (10+ years)

Salary range: 100,000 - 200,000+ THB/month

Manager-level compensation varies significantly based on team size, company scale, and industry. A UX Manager at a mid-size Thai company may earn 100,000-130,000 THB, while a Head of Design at a multinational can exceed 200,000 THB. The determining factor is scope of impact -- the breadth of products, users, and business outcomes under your responsibility.

Key Factors That Determine Compensation

Company Size and Type

This is the single largest variable in UX designer compensation, yet it is frequently overlooked. Two designers with identical skills and experience can see a 30-50% salary difference based solely on employer type.

Thai startups: Typically pay 10-20% below market, sometimes offset by equity or stock options
Large Thai corporates: Pay according to structured salary bands with predictable 5-8% annual increases
Multinational corporations (MNCs): Generally pay 20-40% above local market rates, with stronger benefits packages
Agencies and consultancies: Mid-range salaries, but rapid exposure to diverse projects and industries
Fintech and tech companies: Often the highest-paying segment due to intense competition for talent

Highest-Paying Industries for UX in Thailand

Based on observed compensation data across the market, the industries that pay the most for UX talent in Thailand, ranked from highest to lowest:

Banking and Financial Services -- Major banks undergoing digital transformation invest heavily in UX talent who can handle complex product ecosystems
E-commerce and Marketplace Platforms -- Where conversion rate improvements translate directly to revenue, making the ROI of UX quantifiably clear
Fintech and Digital Payments -- A fast-growing sector with aggressive talent acquisition, driving salaries upward
Insurance and Insurtech -- Increasingly prioritizing digital customer experience, particularly companies pursuing direct-to-consumer models
Technology Companies and SaaS -- Often international companies with Thailand offices that benchmark against global compensation standards

Skills That Command the Highest Salary Premium

Not all skills contribute equally to compensation. The following capabilities consistently correlate with above-market pay:

UX Research: Designers who conduct genuine research -- beyond basic usability testing -- are scarce in the Thai market, creating high demand
Data-informed design: The ability to interpret analytics and use data to inform design decisions significantly strengthens negotiating leverage
Design systems: Building and maintaining scalable design systems is highly valued in enterprise organizations
Advanced prototyping: Beyond static Figma mockups -- creating interactive, testable prototypes that reduce development risk
Business acumen: Speaking the language of business stakeholders is the skill that most clearly separates Senior from Mid-level compensation
English communication: In multinational contexts, strong English proficiency can add 20-30% to compensation compared to equivalent Thai-only roles

For resources on developing these high-value skills, see the Knowledge section.

Career Path: Individual Contributor vs. Manager

A common assumption is that management is the only path to higher compensation. The 2026 reality in Thailand challenges this. Companies with mature design organizations now offer IC (Individual Contributor) tracks that can match management compensation.

IC Track (Individual Contributor)

Progression: Junior, Mid, Senior, Staff/Principal
Strengths: Deep craft focus, no people management overhead, emphasis on quality and innovation
Consideration: Requires continuous skill investment; falling behind on industry evolution leads to rapid obsolescence
Salary ceiling: 100,000 - 150,000 THB (at companies with established IC tracks)

Management Track

Progression: Senior, Lead, Manager, Head of Design, VP/Director
Strengths: Broader organizational influence, ability to shape design culture at scale
Consideration: Progressively less hands-on design work; organizational politics become a significant part of the role
Salary ceiling: 150,000 - 200,000+ THB

The critical point: choosing the management track solely for higher pay is a recipe for dissatisfaction. If you do not genuinely enjoy mentoring, navigating organizational dynamics, and spending most of your time in meetings rather than in design tools, the trade-off will not be worth it. Read more on career reflections and insights on the blog before making this decision.

How to Negotiate UX Designer Salary Effectively

Salary negotiation is an area where many designers in Thailand leave significant money on the table. Cultural norms around modesty and conflict avoidance often work against candidates. Here is a structured approach.

Before the Interview

Research market rates thoroughly: Use resources like this article, community discussions, JobsDB, LinkedIn Salary Insights, and Glassdoor to establish a baseline
Quantify your value: Prepare specific examples of business impact -- metrics you improved, problems you solved, revenue you influenced
Define a range, not a single number: Set your floor at a number you would genuinely be satisfied with, and your ceiling at the top of the realistic market range for your level

During the Interview

Avoid disclosing current salary if possible: When asked, redirect with "I would prefer to focus on what is appropriate for the scope and responsibilities of this role"
Ask about the budget: "What is the compensation range budgeted for this position?" is a reasonable question that shifts the anchor point
Discuss total compensation: Base salary is one component. Inquire about bonuses, benefits, remote work policies, professional development budgets, and review cycles

After Receiving an Offer

Do not respond immediately: Requesting 2-3 days to consider is standard and expected
Counter with reasoning: If the offer falls below your range, provide evidence-based justification, not simply "I want more"
Negotiate beyond base salary: If the salary number cannot move, explore signing bonuses, accelerated review timelines, additional PTO, or training budgets

Realities That Are Rarely Discussed

Salary growth is not automatic

In the Thai work environment, many professionals wait passively for annual raises, which typically amount to 5-8%. However, the fastest salary growth comes from strategic job changes every 2-3 years, where each move can yield a 20-40% increase. This is not an endorsement of frequent job-hopping, but if you have remained at the same company for five years with minimal salary movement, the external market may value you significantly more than your current employer does.

Title does not guarantee compensation

I have observed "Senior UX Designers" earning 45,000 THB and untitled "UX Designers" earning 75,000 THB. The difference is company and scope, not title. Do not conflate title prestige with financial value.

Freelancing is not automatically more lucrative

Many designers assume that freelancing yields higher income. While hourly rates may be higher, factoring in client acquisition time, gaps between projects, self-funded benefits, and tax obligations, the net difference is often smaller than expected. Successful freelancing requires a strong professional network and adequate financial reserves.

Final Advice: Invest in Skills, Not Titles

After 15 years in this field, the clearest pattern I have observed is this: professionals who earn well over the long term are not those who chased the biggest titles. They are the ones who invested consistently in building real, demonstrable skills.

Titles are assigned by companies and can be taken away just as easily. A restructuring can change your "Senior" to "Designer" overnight. But the skills you have built -- the ability to conduct rigorous research, to translate data into design insight, to align stakeholders around a shared vision, to build systems that scale -- those remain with you regardless of title or employer.

The designers who never worry about salary are those whose skills make them indispensable. The market will always find them.

If you are at a point in your UX career where you need clarity on which skills to develop next, or you want perspective from someone who has seen the full arc of this profession, consider booking a career consultation. I am happy to help you see the bigger picture.

Do not chase titles. Chase skills. The salary will follow.

Originally published at nuttadech.com. Follow me for more UX design insights.

10 UX Design Principles Every Designer Must Know — With Real Examples and Practical Tips

nireadaddy — Sun, 15 Mar 2026 10:57:31 +0000

Why UX Design Principles Matter

If you have spent any meaningful time working in UX design, you have likely noticed that great products share something in common. It is not that their designers copied each other. It is that they all follow the same foundational design principles for user experience.

Over my 15+ years working in UX -- from small agency projects to large-scale enterprise platforms -- I have learned that trends come and go, but these core UX principles remain constant. They are the difference between a product that merely looks good and one that actually works for real people.

This article covers 10 essential UX design principles that every designer should internalize. Each one includes a clear explanation, a real-world example, and a practical tip you can apply immediately.

1. User-Centered Design

User-Centered Design means that every decision in the design process starts with the user, not with the designer's preferences or a stakeholder's opinion. It requires understanding user behavior, needs, and pain points through research, then using those insights to drive design decisions. When you design for the user rather than for yourself, the product becomes genuinely useful.

Real-world example: Spotify uses behavioral data from how users actually listen to music to generate Discover Weekly playlists personalized for each individual. Instead of having editors curate recommendations, the product lets user behavior drive the experience. The result is dramatically higher engagement and retention.

Practical tip: Before starting any design work, ask yourself: "What do we actually know about our users?" If the answer is "not much" or "we assumed," that is your signal to conduct research first. Even a handful of user interviews can fundamentally change your design direction. If you need a structured framework for getting started, check out our UX consulting services for process guidance.

2. Consistency

Consistency in UX design means ensuring that every part of a product looks and behaves in a predictable way. Visual styles, interaction patterns, terminology, and layout structures should all follow the same conventions throughout the product. When a user learns how one part of the interface works, every other part should work the same way.

Real-world example: Google Workspace maintains the same design patterns across Gmail, Drive, Docs, and Calendar. The compose button placement, navigation structure, and icon style are all familiar across apps. This allows users to switch between tools without relearning the interface each time.

Practical tip: Build a design system that serves as the single source of truth for your team. Define components, colors, typography, and spacing rules clearly and make them easily accessible. If you do not have a design system yet, our Design System Generator can help you create a solid foundation quickly.

3. Accessibility

Accessibility means designing products that everyone can use, regardless of physical ability. This includes people with visual impairments, hearing difficulties, motor limitations, and cognitive disabilities. Accessibility is not an optional enhancement or a nice-to-have. It is a fundamental responsibility of every designer and a principle that benefits all users, not just those with disabilities.

Real-world example: Apple has set the standard for accessibility in product design. Features like VoiceOver, Dynamic Type, and Switch Control are built into iOS from the ground up rather than added as afterthoughts. This makes the iPhone a device that people with visual impairments can use productively in their daily lives.

Practical tip: Start with the basics. Ensure your color contrast ratios meet WCAG AA standards (4.5:1 for normal text). Add meaningful alt text to every image. Make all interactive elements keyboard-accessible. These three steps alone will significantly improve the accessibility of any product.

4. Feedback

Feedback in UX design is how a system communicates back to the user after they perform an action. Every interaction must produce a clear response, whether visual, auditory, or haptic. When a user does something and nothing visibly happens, confusion and frustration follow. Good feedback keeps users informed and confident about what the system is doing.

Real-world example: When you pull-to-refresh in Instagram, a loading spinner appears immediately, and content updates as soon as it finishes loading. On slow connections, skeleton loading states indicate that the system is working. At no point does the user have to wonder whether their action registered.

Practical tip: Create a feedback state checklist for every interaction you design. Each user action should account for four states: loading, success, error, and empty. If any of these four states is missing from your design, your user will eventually encounter a moment where they do not know what is happening.

5. Simplicity

Simplicity means removing everything that does not serve the user's goal. It does not mean having fewer features. It means presenting features in the most straightforward way possible. The best design is one where the user does not even notice they are interacting with a designed interface. Every unnecessary element competes for attention and increases cognitive load.

Real-world example: Google Search is the classic example of simplicity in UX design. The homepage contains just a logo, a search bar, and two buttons. Behind that minimal interface lies an enormously complex algorithm, but the user never needs to know about that complexity. The interface respects the user's time and attention.

Practical tip: Try this exercise with your current project. Open your design and ask: "If I remove this element, can the user still complete their task?" If the answer is yes, remove it. Repeat this process until only the essential elements remain. You will be surprised how much you can strip away without losing functionality.

6. Visual Hierarchy

Visual Hierarchy is the arrangement of content elements by importance using visual properties such as size, color, weight, spacing, and position. It guides the user's eye to the most important information first. A well-constructed hierarchy allows users to understand the structure of a page within seconds, without needing to read every word.

Real-world example: Airbnb uses visual hierarchy masterfully on listing pages. The large photo captures attention first, followed by the property title, price, and rating. Secondary information like amenities and house rules is placed further down the page. Users can scan the critical information instantly without reading everything.

Practical tip: Use the squint test. Squint your eyes while looking at your design. If you can still see a clear hierarchy -- what stands out most, what is secondary, what is tertiary -- your visual hierarchy is working. If everything looks equally prominent, you need to adjust size, contrast, or spacing to create differentiation.

7. Affordance

Affordance is the property of an object that signals how it can be used, without requiring written instructions. A button that looks pressable, a link that looks clickable, a slider that looks draggable -- these are all examples of good affordance. When a user has to guess which elements are interactive, the affordance has failed and the design needs revision.

Real-world example: Consider the floating action button (FAB) in Google Maps. The "+" symbol on a brightly colored circular background immediately signals "tap me" without needing any label. Conversely, overly flat design trends can strip away affordance cues, leaving users unsure about what they can interact with.

Practical tip: Test affordance by asking someone who has never seen your design to point out which elements they think are interactive. If they miss clickable elements or try to click non-interactive ones, you need to strengthen your visual cues through shadows, color contrast, hover states, or cursor changes.

8. Error Prevention

Error Prevention means designing systems that stop users from making mistakes in the first place, rather than waiting for errors to occur and then displaying error messages. This principle, formalized by Jakob Nielsen, operates on two levels: preventing slips (unintentional mistakes caused by inattention) and preventing mistakes (wrong decisions caused by misunderstanding).

Real-world example: Gmail offers an "Undo Send" feature that gives users up to 30 seconds to recall a sent email. It also displays a warning when you mention "attachment" in your email body but forget to attach a file. These are error prevention mechanisms that save users from real, everyday mistakes.

Practical tip: Review the critical flows in your product -- checkout, form submissions, data deletion -- and ask: "Where could a user go wrong?" Add confirmation dialogs for irreversible actions, implement inline validation on forms, and disable submit buttons until required inputs are complete. Prevention is always cheaper than recovery.

9. Flexibility

Flexibility means designing a product that accommodates users across different skill levels, from beginners to power users. A well-designed system provides easy paths for newcomers while offering shortcuts and advanced features for experienced users. Forcing everyone through the same rigid workflow limits the efficiency of skilled users without necessarily helping beginners.

Real-world example: Figma demonstrates flexibility exceptionally well. You can select tools from the menu bar, or you can use keyboard shortcuts. New users start with the menu, then gradually learn shortcuts as they become more proficient. Both methods accomplish the same tasks, but the efficiency difference is significant for frequent users.

Practical tip: For every core feature in your product, consider whether there are at least two ways to accomplish the same task. This could be mouse versus keyboard shortcuts, a guided wizard versus an advanced mode, or search versus browse navigation. You do not need this for every feature, but the ones users interact with most frequently should offer flexibility.

10. Learnability

Learnability is how easily a user can learn to use a product when encountering it for the first time. A product with high learnability allows users to start using it and complete basic tasks quickly without reading documentation or watching lengthy tutorials. The first impression a user has often determines whether they continue using the product or abandon it.

Real-world example: Notion uses the "/" command to let users discover new features at any time. By typing "/", users see a menu of all available block types. They do not need to memorize where features are located. They just need to remember one interaction pattern to access everything. This is learnability done right.

Practical tip: Test learnability with a 5-second test. Show a new user your screen for 5 seconds, then ask them what the product does and how they would start using it. If they cannot answer, your onboarding experience needs improvement. The goal is for the interface itself to teach the user, not an external tutorial.

Summary: UX Design Principles Are Tools, Not Theory

These 10 UX design principles are not academic concepts to memorize for an exam. They are practical tools you can use to make better design decisions every day.

Whether you are designing a mobile app, a web platform, or a design system, use these principles as a checklist before shipping any piece of work:

User-Centered Design: Do we truly understand our users?
Consistency: Is the design coherent across the entire product?
Accessibility: Can everyone use this?
Feedback: Does the user always know what is happening?
Simplicity: Is there anything we can remove?
Visual Hierarchy: Does the most important content stand out?
Affordance: Can users tell what is interactive?
Error Prevention: Have we guarded against common mistakes?
Flexibility: Can users at all skill levels work efficiently?
Learnability: Can a new user get started quickly?

If you want to go deeper into applying these design principles in your daily work, including a free UX component guide to help you design faster and more consistently, visit our Knowledge Hub.

Originally published at nuttadech.com. Follow me for more UX design insights.

Stop Designing by Gut Feeling: Why UX Must Be Measured with Data, Not Intuition

nireadaddy — Sun, 15 Mar 2026 10:54:28 +0000

"I think this button should be bigger"

That sentence sounds harmless enough. But if you're a UX Designer, you know it's the beginning of a problem.

Over my 15 years in UIUX — from agencies to large-scale e-commerce platforms to leading insurance companies — I've encountered the same pattern over and over again:

Executives use gut feeling to judge UX work.

It's not because they're not smart. Quite the opposite — most executives are very smart. But business acumen and understanding user experience are two entirely different things.

The Problem: When UX Designers Become "Graphic Order-Takers"

Picture this:

A product team spends 3 weeks doing research — interviewing users, analyzing data, running usability tests. They build wireframes from real insights. They design flows that address the pain points they've uncovered.

Then one day, an executive walks over, glances at the screen, and says:

"I don't like this color. Change it to blue."
"Why isn't there a banner here? Our competitors have one."
"I don't like this layout. Make it look like website X."

Three weeks of research, overridden by three minutes of personal opinion.

When this happens repeatedly, UX Designers start to:

Stop doing research — because it gets overridden anyway
Stop sharing insights — because no one listens
Become order-takers — "Just tell me what you want, and I'll make it"

The UX Designer becomes a graphic production worker following orders, not someone solving user problems.

Why Gut Feeling Is Dangerous

Gut feeling isn't always wrong. But it has structural problems:

1. You Are Not the User

An executive using an iPhone 16 Pro Max with 1 Gbps fiber internet who understands every corner of the business model — is not representative of the user.

Real users might be on a budget Android phone, struggling with spotty 4G, and have never read an FAQ in their life.

2. The HiPPO Effect

HiPPO = Highest Paid Person's Opinion

In a meeting room, the highest-paid person's opinion usually wins. Not because it's right, but because no one dares to push back.

3. Survivorship Bias

"The current site works just fine" — in reality, you have no idea how many people visited and quietly left without ever complaining.

Unhappy users don't leave feedback — they just leave.

4. Confirmation Bias

Once an executive believes "the red button is better than blue," even if an A/B test proves otherwise, they'll find reasons to explain why the data is wrong.

What Executives Should Do Instead

I'm not saying executives shouldn't be involved in design. On the contrary — executives are crucial. But their role should shift:

From "Dictating what to do" → "Framing the problem to solve"

Instead of saying "Change the button to red"

Try saying "The conversion rate on this page is lower than expected. Can the team investigate why and run some experiments to fix it?"

Build a Framework That Lets the Team Experiment

Great executives don't design the UI — they create an environment where the team can experiment safely:

Allocate time for research — not everything has to ship today
Budget for usability testing — even testing with just 5 users can produce massive insights
Make room for A/B testing — let data decide, not job titles
Be willing to say "I don't know" — and let the process find the answer

Measure with Metrics, Not Feelings

Gut Feeling	Data-Driven
"This page looks cluttered"	Heatmap shows where users actually click
"Customers will probably like this"	A/B test shows which variant converts better
"Make it like the competitor"	User interview reveals what users actually need
"This button is too small"	Analytics shows the click-through rate

Case Study: What Happened When We Used Data Instead of Gut Feeling

Product Comparison Platform

An executive once suggested adding more information to a comparison page — the more the better. The logic sounded reasonable.

But when we ran usability tests, we found:

Users were overwhelmed by too much information
Users only used 3 out of 15 criteria to make decisions
Bounce rate increased when displaying more than 5 columns

We reduced the information and showed only the criteria users actually relied on → bounce rate dropped by 23%.

Online Form System

In another project, an executive wanted the signup form to include every single field on the first page — "so users don't have to come back and fill in more later."

But the data told a different story:

Users dropped off at 67% on the first page of the form
The main reason: seeing too many fields made them feel like it was too hard

We switched to progressive disclosure — ask 3 questions first, then expand → completion rate increased by 40%.

In both cases, the executives' logic wasn't wrong. But users don't think like executives.

How to Get Started: For Organizations Still Running on Gut Feeling

If your organization still makes UX decisions based on feelings, you don't have to change overnight. Start small:

Month 1: Start Measuring

Set up analytics that track real user behavior (not just pageviews)
Establish baseline metrics — where are we right now?

Month 2: Start Listening to Users

Run usability tests with 5 real users
Record video sessions for executives to watch — nothing is more powerful than seeing a real user struggle with a design you thought was "good enough"

Month 3: Start Experimenting

Run your first A/B test — pick something small with clearly measurable results
Present the findings to executives so they can see what the data says

Month 4+: Build the Culture

Make "let's test it first" the default mindset
Shift from "executives decide" to "data decides, executives set direction"

Conclusion

Gut feeling isn't the enemy — it can be a great starting point for a hypothesis.

But gut feeling should never be the final answer.

The best executives I've ever worked with aren't the ones with the strongest opinions. They're the ones who say:

"I have an opinion, but let the team test it first. If the data says I'm wrong, I'm happy to change my mind."

That's the kind of leadership that builds truly great products.

Stop designing by feeling. Start designing by understanding.

Originally published at nuttadech.com. Follow me for more UX design insights.

The Gap Nobody Talks About: The Space Between Junior and Senior in a UX Team

nireadaddy — Sun, 15 Mar 2026 10:51:27 +0000

The Gap Nobody Teaches You About

Every career path has a gap in the middle. But in a UX team, it hurts more than anywhere else.

Junior UX has a clear path — follow the brief, deliver wireframes, wait for feedback, revise based on comments. Everything has a scope that someone else defines for you. You know exactly what you need to do today.

Senior UX also has a clear path — set direction, make decisions, mentor the team, talk to stakeholders. Everything has ownership that you're responsible for.

But the middle? The middle is no man's land.

You're no longer a Junior, but you haven't earned Senior-level trust yet. You start seeing problems bigger than wireframes, but you don't have the authority to fix them. You know what's wrong, but nobody asks for your opinion.

This is the gap that makes so many people leave UX altogether.

The Workload That Grows Disproportionately

As you move up, what happens isn't just "doing the same design work but harder" — it's taking on entirely new roles while none of the old ones go away.

What Juniors Do

Create wireframes / prototypes based on requirements
Build user flows based on specs they receive
Submit work for Senior review
Revise work based on feedback

What Seniors Must Do (On Top of Everything Above)

Consolidate User Experience — maintain consistency across features, across products
Hands-on delivery — still do design work yourself because the team is small
Mentor and review Junior work
Talk to PM, Dev, Business to negotiate scope
Present and defend design decisions to senior stakeholders
Measure and prove how UX impacts the business

It's like being asked to be both the player and the coach at the same time — but only getting paid as a player.

Pressure From Every Direction

Pressure from above: "How do we measure UX?"

This is the question every Senior UX dreads.

In organizations where Engineering is measured by velocity, QA by bug count, and PM by feature delivery — UX becomes the intangible thing.

"The design looks nice, but how does it affect revenue?"

"We invested 2 months in research. What did we get out of it?"

"Why do we need a design system? Dev can build UI on their own."

Every one of these questions demands numbers — but the value of UX often lives in things that are hard to measure: reduced confusion, increased confidence, tasks completed faster than before.

Pressure from below: "Can you teach me too?"

Juniors on the team expect you to be their mentor. But the time you have for mentoring gets eaten up by meetings, stakeholder management, and delivery work you have to do yourself.

You want to teach. You want to give them time. But the reality is deadlines never move for you.

Pressure from the sides: "Why isn't the design done yet?"

PM asks. Dev asks. QA asks. Everyone is waiting on design like it's the bottleneck of the entire pipeline.

And many times it is — because a single Senior UX has to review the whole team's work, consolidate the experience across features, and still do hands-on design themselves.

The Fork in the Road: 3 Paths for Senior UX

At some point, Senior UX has to choose — not "what to do" but "what to become."

Path 1: IC Track (Individual Contributor)

Go deep into the craft. Become the specialist everyone comes to for advice.

Pros: You get to do the craft you love, impact through quality of work
Cons: In many organizations, the IC track doesn't have a clear career path, and salary hits a ceiling fast
Best for: People who still love hands-on design and don't want to manage people

Path 2: Management Track

Stop doing design yourself. Shift to managing the team, setting direction, talking to C-level.

Pros: You have authority to make decisions, clearer career path
Cons: You drift from the craft, may feel like "I'm not really doing UX anymore"
Best for: People interested in strategy, organization, and people management

Path 3: Hybrid (The Reality of Small UX Teams)

Do both IC and management — which is the reality for most UX teams.

Pros: You understand both craft and business, high flexibility
Cons: Extremely high burnout risk, you do everything but don't excel at any one thing
Best for: People in organizations where the UX team is still small (1-3 people)

Survival Strategies: Making UX Tangible

If the organization can't measure UX, don't wait for them to figure it out — measure it yourself and bring them the results.

1. Tie UX Metrics to Business Metrics

Don't say "we improved the UI" → Say "we reduced drop-off at step 3 by 23%, which increased conversion by X dollars."

Task completion rate increased → More customers complete purchases = more revenue
Time on task decreased → Fewer support calls = lower operational costs
Error rate decreased → Less rework cost = dev doesn't have to fix the same bugs
NPS/CSAT increased → Better retention = higher lifetime value

2. Document Everything You Do

The problem with UX is when it's done well, nobody notices — users will never say "wow, this form is so easy to use," but they'll complain the moment it isn't.

Build a design log:

Before/After screenshots of every improvement
Metrics before and after redesign
User feedback quotes
Dev time saved from having a design system

3. Build Alliances with PM and Dev Lead

UX can't survive alone. You need:

A PM who understands that research isn't a waste of time
A Dev Lead who agrees that a design system helps reduce tech debt
A Data Analyst who can help pull impact numbers for design changes

4. Stop Proving Yourself Through Deliverables

Juniors prove themselves by the number of wireframes they ship. Seniors must prove themselves through decisions that are right.

"We chose not to build this feature because research showed users don't need it" — that's the value a Senior UX provides, even when there's no tangible deliverable to show for it.

If You're Stuck in the Middle Right Now

For those standing at this gap right now — I get it. I've been there.

It feels like you're being stretched in every direction. You have to do design. You have to manage the team. You have to prove value. But nobody tells you how.

Here's what I want to tell you:

1. Don't carry everything alone. If you're the only Senior UX on the team, it's not your fault that you can't handle it all. That's a structural problem with the organization.

2. Pick your battles. You can't fix every UX problem at once. Choose 1-2 things with the highest impact, deliver visible results, then expand from there.

3. Build a track record. Every time a design change produces positive results, write it down. Keep accumulating. When it's time to negotiate salary or headcount, you'll have the evidence.

4. Accept that some organizations aren't for you. If an organization truly doesn't value UX, no matter how hard you try to prove it, sometimes the answer isn't "how do I make them understand" — it's "go somewhere they already do."

5. Invest in your network. The UX community may be small but it's tight-knit. There are plenty of people who've been through the same struggles. Don't fight alone.

Final Thoughts

The gap between Junior and Senior isn't about skill or seniority — it's about a complete shift in how you think. From someone who waits for answers to someone who creates them.

And the hardest part isn't making good design — it's making people who don't understand design see its value.

If you can do that, you won't just be a Senior UX.

You'll be the person who permanently changes how your organization sees User Experience.

Originally published at nuttadech.com. Follow me for more UX design insights.

Managing Stress When UX Work Doesn't Go as Planned

nireadaddy — Sun, 15 Mar 2026 10:48:26 +0000

The Night I Almost Gave Up

It was a Thursday night, around 10 PM.

I was staring at a Figma file covered in red comment bubbles. Every comment was feedback from that afternoon's review — a design I'd spent 2 weeks on, torn to shreds in 45 minutes.

"Doesn't match the brand." "This flow is too complex." "Why don't we just copy the competitor?" "I don't know what to click next." "Maybe start over from scratch."

My 4th coffee of the day had gone cold. I sat staring at the screen and asked myself, "Why am I still doing this?"

If you've ever felt this way — this article is for you.

Why UX Work Is Stressful in Ways Outsiders Don't Understand

1. Our Work Is More "Personal" Than We Realize

A developer writes code — the code isn't their identity. If there's a bug, you fix the bug.

But designers pour themselves into their work. Every color, every layout, every flow is a decision born from our experience, beliefs, and perspective.

When feedback comes, it doesn't just feel like "the work is being criticized" — it feels like we're being criticized.

2. Feedback Is Usually Subjective, Not Objective

Code is right or wrong — it compiles or it doesn't. Tests pass or they don't.

But design? "I don't like it" is considered valid feedback in a meeting room, even when there's zero logic behind it.

The subjectivity of feedback is the primary source of stress in UX — because you can't prove you're right the way a developer can point to test results.

3. UX Is Still Seen as "Making Things Pretty"

This is the wound that cuts deepest.

You spend 3 weeks doing research, interviewing users, analyzing data, building journey maps, designing flows that address real pain points.

Then a VP walks over, glances at the screen, and says, "Looks nice, but I think this button should be red."

Three weeks of research, reduced to "pretty or not pretty" in the eyes of someone who doesn't understand.

When this happens over and over, you start questioning: "Does any of what I do actually matter?"

The Feedback Storm: When Everyone Has Conflicting Opinions

Feedback from 1 person is manageable. But in reality, design reviews typically involve 5–10 people — and everyone disagrees:

PM: "Simplify it. Cut features."
VP Marketing: "Add more information. The more the better."
Dev Lead: "This can't be implemented."
CEO: "I saw App X do it like this. Make it look like that."
Sales: "Clients say they want this feature."

Everyone speaks with confidence. Everyone believes they represent the user. But nobody brings data to support their opinion.

And you — the lone designer in the room — have to:

Listen to everyone
Separate noise from signal
Find a compromise that doesn't destroy the UX
Not make anyone feel ignored
Go back and revise the design to address all conflicting feedback

Within the original deadline.

If you don't feel stressed yet — congratulations, you might be a robot.

What Happens When Stress Goes Unmanaged

When stress accumulates without being addressed, it doesn't just make you "tired" — it changes how you work:

Stage 1: Playing It Safe

You stop proposing bold ideas because you fear rejection. Everything becomes the "safe choice" that nobody will complain about — but isn't good enough to impress either.

Stage 2: Taking Feedback Personally

Every piece of feedback feels like an attack. "I don't think this layout works" gets interpreted as "you're a bad designer."

Stage 3: Shutting Down

You stop voicing opinions in meetings. Stop proposing alternatives. Become an order taker who only asks, "What do you want? Just tell me."

Stage 4: Burnout

Complete exhaustion. Working on autopilot. Quality drops. You feel nothing about the work anymore — no joy when shipping, no pain when rejected.

I've been at Stage 3. And I know that if you don't catch yourself, Stage 4 comes fast.

How to Manage the Stress: From Someone Who's Been There

1. Separate "You" from "the Work"

This is the most important skill and the hardest to learn.

The design you made isn't you. It's one proposal on a spectrum of possible solutions. If it gets rejected, it doesn't mean you're not good — it just means this particular solution doesn't fit this particular context at this particular time.

Try reframing:

"My design got rejected" → "Solution A didn't pass. Time to try Solution B."
"They don't like my work" → "The stakeholder has concerns that need addressing."
"I'm not good enough" → "I don't have enough data yet to make a convincing case."

2. Build a Feedback Filter

Not every piece of feedback needs to be acted on. Sort them into 3 buckets:

Bucket 1: Actionable + data-backed
"Conversion dropped 20% since the flow change" → Act immediately.

Bucket 2: Reasonable but needs validation
"I think users might be confused here" → Interesting. Needs testing first.

Bucket 3: Pure subjective opinion
"I don't like this color" → Note it. Don't change anything yet.

When feedback comes in like a storm, pause — don't react immediately. Take it back, categorize it, then decide what to act on.

3. Build an Evidence Bank

When UX is dismissed as just "aesthetics," the best defense is evidence.

Screenshot every usability test where users struggle → save as proof
Record before/after metrics for every design change → build a track record
Collect user quotes that support your design decisions
Write brief case studies for every project where design changes made a positive impact

With evidence, you don't argue with opinions — you argue with facts.

4. Find a Safe Space to Vent

Everyone needs a place to decompress — but don't vent at work.

UX communities — Facebook groups, Discord servers, local meetups with people facing the same struggles
A mentor — someone who's been through it before
Trusted peers — other designers in your industry
A personal journal — write it out, nobody needs to read it

Bottling it up isn't strength — knowing how to release it appropriately is.

5. Transform Feedback Sessions into Design Critiques

The core problem with feedback in many organizations is it has no structure.

Try proposing a new format:

Before review: Send context to everyone in advance — what problem are we solving? What did research find? What's the design rationale?
During review: Ask specific questions — "Does this flow address the user goal?" instead of letting everyone freestyle
After review: Summarize feedback as actionable items — make it clear what will be addressed and why

When feedback has structure, it reduces noise and reduces pain.

6. Accept That "Not Perfect" Is OK

Perfectionism is the arch-enemy of UX designers.

A design that's 80% good and ships is better than a design that's 100% perfect but never ships.

Every design is an iteration — v1 doesn't need to be flawless. It just needs to be good enough to learn from users.

Moving Forward

Stress in UX work doesn't go away — it's part of the job. Just like doctors deal with life and death, and teachers deal with distracted students.

But stress that's managed versus stress that's left to accumulate — the outcomes are worlds apart.

What I learned after nearly giving up:

Your value isn't measured by a single feedback session — it's measured by the sum of everything you've built across your entire journey.

People who give harsh feedback usually don't realize it's harsh — they're just sharing opinions in a meeting. But you take it home and think about it until 3 AM.

Good organizations build cultures where feedback is fuel, not a weapon — if your organization weaponizes feedback, that's a culture problem, not a you problem.

Rest isn't weakness — the best designers I know all know how to pause, disconnect, and say "that's enough for today."

If You're in That Place Right Now

If you're sitting in front of a screen late at night, wondering why you chose this career, feeling like the work you poured yourself into has no value in anyone else's eyes.

I want you to know:

It will pass. Not because it gets easier — but because you get stronger.

You're not alone. Every UX designer I know has been at this point — the ones who look confident and relaxed on the outside have sat crying in front of their screens too.

UX work matters. Even on days when nobody sees it. Even on days when it gets dismissed. Every time a user uses a product and thinks "that was easy" — that's your handiwork. Even if they never know.

Take care of yourself.

Because users need someone who understands them — and that someone needs to understand themselves first.

Originally published at nuttadech.com. Follow me for more UX design insights.

How to Start Learning UX UI Design: A Complete Roadmap from a 15-Year Veteran

nireadaddy — Sun, 15 Mar 2026 10:45:25 +0000

Before you begin: what this guide is and who it is for

This is a practical roadmap for anyone who wants to learn UX UI design, whether you are a complete beginner, a developer looking to upskill UX capabilities, a graphic designer transitioning into product design, or someone considering a mid-career switch.

I have been working in user experience UX design for over 15 years, currently as a senior UX manager. This guide is based on what I have seen actually work in the industry, not theoretical advice from someone who has never shipped a product.

You do not need a computer science degree. You do not need to know how to code. You do need curiosity about how people interact with products, and the discipline to learn systematically.

Step 1: Understand what UX/UI actually is

Most beginners make the same mistake: they think UX design is about making things look pretty. It is not.

UX (User Experience) Design is the process of designing the entire experience a person has with a product. It involves understanding user problems, conducting research, designing flows, testing solutions, and iterating based on evidence. It is problem-solving with humans at the center.

UI (User Interface) Design is about designing the visual layer and interactions of an interface. It is a subset of UX that focuses on how things look, how components behave, and how information is visually communicated.

Both disciplines overlap significantly, but they are not the same thing. If you only care about aesthetics, graphic design might be a better fit. If you find yourself asking "why can't people find this button?" or "where does this flow break down?" then UX is where you belong.

Where to start:

Read "The Design of Everyday Things" by Don Norman. It will fundamentally change how you see the world.
Take the Google UX Design Certificate on Coursera (free trial available). It provides solid foundational coverage.
Start observing the apps you use daily. Ask yourself why each design decision was made. This habit alone will accelerate your learning.

Step 2: Learn UX design principles before touching any tool

Before you open Figma, build a foundation in UX design principles. Without this, you will become someone who can operate a tool but cannot design.

Core principles to study:

Design Thinking — The Empathize, Define, Ideate, Prototype, Test framework. Understand the process, not just the diagram.
Information Architecture — How to structure and organize content so people can find what they need.
Interaction Design — How interfaces respond to user actions. Includes flow design, state management, and feedback patterns.
Usability Heuristics — Jakob Nielsen's 10 heuristics for evaluating interface quality. Memorize these. Use them daily.
Accessibility — Designing for all users, including those with disabilities. This is not optional; it is a professional requirement.

Do not try to learn everything simultaneously. Start with Design Thinking and Usability Heuristics. Expand from there.

Free resources:

Nielsen Norman Group articles at nngroup.com. This is the most authoritative source of UX knowledge available.
Interaction Design Foundation (some courses are free).
Laws of UX at lawsofux.com. A concise reference for psychology principles applied to design.

Paid resources:

Google UX Design Professional Certificate on Coursera.
Nielsen Norman Group UX Certification.
For structured, hands-on learning with real industry case studies, see workshops I run.

Step 3: Master the tools, starting with Figma

In 2026, Figma is the industry standard for UX/UI design. Nearly every product team uses it. Start here.

What you need to learn in Figma:

Frames and Layout Grids for responsive design.
Auto Layout for building flexible, production-ready components.
Components and Variants for reusable design elements.
Design Tokens (color, typography, spacing) for systematic design.
Prototyping with interactions, transitions, and conditional logic.
Collaboration features including comments, branching, and dev mode.

A practical warning: do not spend hundreds of dollars on Figma courses. The tool changes frequently, and paid courses become outdated within months. Learn from Figma's official documentation and tutorials, then practice by building real things.

Free resources:

Figma's official tutorials at figma.com/resources.
Figma's YouTube channel.
Try building your own design system using the Design System Generator. It is a free tool I built specifically for practice and learning.

Step 4: Study UI components and learn when to use each one

This is where most self-taught designers fall short, and it is immediately obvious in their work.

Knowing what a component looks like is easy. Knowing when to use it, and more importantly when not to use it, is what separates junior designers from competent ones.

Key decisions you need to understand:

Modal vs. Drawer vs. Toast — Which level of interruption is appropriate for the action?
Dropdown vs. Radio buttons vs. Toggle — Which input type suits the number and nature of options?
Table vs. Card vs. List — Which data display format matches the use case?
Tabs vs. Accordion vs. Stepper — How should content be grouped and revealed?

Every component exists for a reason. Using a modal when a toast would suffice creates unnecessary friction. Using a dropdown for two options wastes clicks. These decisions compound across an entire product.

I created a free UX Component Guide that covers exactly this: when to use each component, with examples of correct and incorrect usage. It is one of the most practical starting points for building real UI judgment.

Step 5: Learn UX research basics

Good UX design starts with evidence, not assumptions. If you want to be a designer who solves real problems, you need to know how to gather information from actual users.

Essential research skills:

User Interviews — How to ask questions that reveal genuine insights rather than confirming your assumptions.
Usability Testing — How to observe people using a prototype and identify where they struggle.
Survey Design — How to write unbiased questions that produce actionable data.
Affinity Mapping — How to organize research findings into meaningful patterns.
Personas and Journey Maps — How to synthesize research into tools that align your team.

You do not need to become a full-time researcher. But every UX designer should be able to conduct basic research independently.

Free resources:

"Just Enough Research" by Erika Hall. Short, practical, and immediately applicable.
UX research method guides on nngroup.com.
The best free practice: run a usability test with 5 people using any app. You will learn more in one afternoon than in a week of reading.

Step 6: Build your first portfolio

In UX, your portfolio matters more than your resume. But most beginners build their portfolios wrong.

What a strong UX portfolio shows:

Your thinking process, not just final screens.
The problem you were solving and why it mattered.
How you gathered evidence (research, data, testing).
Why you made specific design decisions.
The outcome and what you learned.

Common mistakes to avoid:

Showing only polished visuals with no process documentation.
Doing unsolicited redesigns of popular apps (everyone does this; it does not differentiate you).
Failing to clearly state your role and contribution.

If you have no professional experience yet:

Create case studies from real problems around you. Design an app for a local business, a tool for your community, or a solution for a process you personally find frustrating.
Choose problems where you understand the context deeply. Authenticity stands out.
Conduct actual usability tests on your prototypes, even for personal projects. This demonstrates rigor.

Step 7: Get real experience through freelance and volunteer work

A portfolio built from personal projects is a good start. Real-world experience is better. Even small-scale work counts.

How to gain experience when you have none:

Freelance — Take small web or app design projects on platforms like Upwork or Fiverr. Set modest rates initially. The goal is experience, not income.
Volunteer — Offer design help to NGOs, community organizations, or early-stage startups that cannot afford a designer.
Hackathons — Join hackathons that need designers. You will build portfolio pieces and professional connections simultaneously.
Internships — If you are a student or recent graduate, an internship on a product team is extremely valuable.

The key insight: do not wait until you feel ready. I started doing UX work when I barely knew what I was doing. Learning by building real things for real people is exponentially faster than learning in isolation.

Step 8: Stay current with AI in UX

In 2026, AI is transforming how UX work gets done. If you are starting now, you need to learn AI alongside your UX foundations.

Where AI helps UX designers today:

Synthesizing research from interview transcripts and survey data.
Generating draft UI copy, error messages, and onboarding content.
Creating initial prototypes and layout explorations.
Analyzing behavioral data and identifying patterns.

Where AI still falls short:

Deciding which problems are worth solving.
Understanding business context, organizational politics, and cultural nuances.
Building relationships with stakeholders and users.
Making judgment calls about what is "right" for a specific situation.

Designers who use AI effectively are 2-3x more productive. But designers who rely on AI without strong UX fundamentals produce work that looks polished but fails in practice. Build your foundation first. Then AI becomes an extraordinarily powerful amplifier.

Where to go from here

Learning UX UI design is not a quick process, but it is an achievable one. The path is clear: understand the fundamentals, learn the tools, study how components work, practice research, build a portfolio, and get real experience.

The resources available today for anyone looking to upskill UX capabilities are vastly better than what existed when I started. There are free courses, free tools, and active communities ready to help.

Start today. Start with one step. Build something. Test it with a real person. Learn from what breaks.

For a practical first step, explore the free UX Component Guide I created. It will give you a concrete understanding of when and why to use each UI component, which is one of the most immediately applicable skills in UX design. And check out more articles where I share lessons from 15 years of building products and leading design teams.

Originally published at nuttadech.com. Follow me for more UX design insights.

From Table Layouts to AI: My 15-Year Design Evolution

nireadaddy — Sun, 15 Mar 2026 10:42:24 +0000

It all started with tables

Not database tables. HTML tables.

If you started building websites before 2010, you know exactly what I'm talking about. <table>, <tr>, <td> — that was our layout system. We'd nest tables inside tables, slice up Photoshop designs into tiny image pieces, and reassemble them like digital jigsaw puzzles. It was messy, fragile, and kind of beautiful in its own way.

I was in my early twenties, fresh out of school, and completely hooked. Back then, "web design" meant you did everything — Photoshop mockup, HTML slicing, even writing the copy. There was no UX. There was no UI. There was just "making the website."

The tools were primitive. Dreamweaver was king. We'd preview in Internet Explorer 6 and pray nothing broke. Font choices were limited to Arial, Verdana, and Times New Roman. Custom fonts? You'd render them as images.

But here's what that era taught me: constraints breed creativity. When you only have tables and basic CSS, every pixel matters. You learn to think about hierarchy, spacing, and visual weight — not because a design system told you to, but because you had no other choice.

Web 2.0: The CSS revolution and the birth of "real" design

Then CSS2 happened. And with it, everything changed.

Suddenly, we could separate content from presentation. Float-based layouts replaced table hacks. We got rounded corners (after years of using corner images). We got transparency. We got @font-face.

But more importantly, the web stopped being a digital brochure and started becoming an application platform. Gmail launched. Google Maps launched. Facebook opened to the public. The web became interactive, dynamic, and personal.

This was when I first heard the term "User Experience." Before this, we'd talk about "usability" or "information architecture" — academic terms that felt distant. But UX? UX felt human. It was about feelings, not features. About journeys, not pages.

I remember my first usability test. I'd designed what I thought was a perfect e-commerce flow — clean, logical, efficient. Then I watched a real person try to use it. They couldn't find the checkout button. They didn't understand our category labels. They got lost on step 3.

That day changed my career. I realized: I don't design for screens. I design for people who are confused, distracted, and in a hurry.

The mobile earthquake

Then Steve Jobs walked on stage with the iPhone. And nothing was ever the same.

The first few years of mobile were chaos. We'd build two separate websites — one for desktop, one for mobile (remember m.example.com?). The mobile version was always an afterthought. Stripped down. Basic. Second-class.

Then Ethan Marcotte wrote an article called "Responsive Web Design," and it was like someone turned on the lights.

One codebase. Every screen size. Fluid grids. Flexible images. Media queries.

I spent months learning responsive design. Not just the technical part — that was relatively straightforward. The hard part was thinking responsively. How does this 5-column layout work on a phone? What happens to this mega-menu on a tablet? Which content should we prioritize on small screens?

This was also when I joined Priceza, Thailand's largest price comparison platform. Suddenly I wasn't designing for thousands of users — I was designing for 140 million annual visits across five countries. A 1% improvement in conversion could mean millions of baht.

At that scale, "I think this looks better" stops being an acceptable argument. You need data. You need A/B tests. You need to understand analytics. This was where I learned that great UX isn't about what designers like. It's about what users actually do.

We ran experiments constantly. Does a bigger "Compare" button increase clicks? (Yes.) Does showing the price difference as a percentage or absolute number drive more engagement? (Percentage.) Does adding a product image to the comparison table reduce bounce rate? (Dramatically.)

Every decision was measurable. Every assumption was testable. It was the most rigorous design education I could have asked for.

Web 3.0: Social, content, and the attention economy

By the mid-2010s, the web had transformed again. It was no longer about websites — it was about platforms and ecosystems.

Social media became the front door to the internet. People didn't type URLs anymore. They scrolled feeds. Content became currency. Every business needed a "content strategy." Every brand needed a "social presence."

For designers, this meant a fundamental shift. We weren't just designing interfaces anymore. We were designing for engagement, for sharing, for virality. The question changed from "Can users complete this task?" to "Will users come back tomorrow?"

I saw this play out at Priceza, where we had to think about how our content appeared on LINE, Facebook, and Twitter. An Open Graph image could make or break a shared link. A meta description could determine whether someone clicked or scrolled past.

Then I moved to insurance — first Southeast Insurance, then MSIG Thailand. And here's where things got really interesting.

Insurance is the opposite of social media. Nobody wants to buy insurance. Nobody shares their policy on Instagram. The product is complex, the language is jargon-heavy, and the trust barrier is enormous.

But that's exactly what made it the best design challenge of my career. How do you take something nobody wants to think about and make it feel simple, safe, and even... pleasant?

We redesigned MSIG's entire digital insurance platform. We introduced OCR technology so users didn't have to type their ID numbers manually. We built a self-service claims system so people could track their claim status at 3 AM without calling a hotline. We simplified policy comparison from a 15-field matrix to a 3-question wizard.

The lesson from this era: UX isn't about making things pretty or viral. Sometimes UX is about making something so seamless that people forget they're doing something complicated.

2025 and beyond: The AI era

And now we're here. The biggest shift since mobile. Maybe bigger.

I've been watching AI evolve from a designer's perspective, and I can tell you — this isn't like previous technological shifts. This isn't "add a new breakpoint" or "optimize for a new platform." This is a fundamental change in how we design, what we design, and who we design for.

Here's what I mean:

How we design has changed

My daily workflow looks nothing like it did two years ago. I use Claude as a thinking partner — not to generate designs, but to challenge my assumptions. "What edge cases am I missing in this flow?" "What would a first-time user struggle with here?" "How would this work for someone who's visually impaired?"

I use AI for research synthesis. At MSIG, we'd conduct customer interviews and spend days clustering insights. Now I can feed transcripts into an LLM and get structured themes in minutes. I still validate everything — AI doesn't replace judgment — but it eliminates the tedious parts.

I use Gemini for content generation and Imagen for quick concept visuals. Not as final outputs, but as conversation starters. "Here are 10 possible headlines for this landing page" is a better starting point than a blank text field.

What we design has changed

The interfaces themselves are evolving. We're no longer just designing static screens with buttons and forms. We're designing conversations, predictions, and adaptive experiences.

A traditional insurance quote form asks 20 questions in sequence. An AI-powered one might ask 3 questions, infer the rest from context, and present a personalized recommendation. The UX challenge isn't "how do we lay out these fields?" — it's "how do we make the user trust a recommendation they didn't explicitly ask for?"

This is a design problem no previous era prepared us for: designing trust in intelligent systems.

Who we design for has changed

AI doesn't just change the product. It changes the user's expectations. People who use ChatGPT daily now expect every interface to be conversational. People who use Midjourney expect visual generation to be instant. The bar has moved — not just for AI products, but for all products.

When a user can ask an AI assistant to "find me the cheapest travel insurance to Japan for next week" and get an instant answer, a traditional comparison website with filters and sorting feels... slow. Not broken. Just slow.

This is the challenge — and the opportunity — for every designer right now.

What 15 years taught me

Looking back, every era had its own version of the same panic: "This new thing will make designers obsolete."

CSS will replace designers. (It didn't.)
Templates will replace designers. (They didn't.)
No-code tools will replace designers. (They didn't.)
AI will replace designers. (It won't.)

But here's what each era did replace: designers who refused to adapt.

The table-layout designers who wouldn't learn CSS? They faded out. The desktop-only designers who dismissed responsive? They got left behind. The designers who ignored data and insisted on gut feelings? They lost influence.

The pattern is always the same: the technology changes, the tools change, but the core skill remains — understanding people and reducing the gap between what they want and what they experience.

That's what I've been doing for 15 years. The medium keeps changing. The mission never does.

What comes next

I don't know exactly what the next era looks like. Nobody does. But I know what I'll be doing in it: watching real people struggle with things that should be simple, and figuring out how to fix it.

Whether that's with table layouts, responsive grids, social platforms, or AI agents — the work is the same.

Make the complex feel simple. Make the invisible feel intentional. Make technology disappear so people can focus on what actually matters.

That's the job. It's always been the job.

And after 15 years, I'm just getting started.

Originally published at nuttadech.com. Follow me for more UX design insights.

Figma MCP: A Design-to-Code Pipeline for Scalable Products Across Multiple Projects

nireadaddy — Sun, 15 Mar 2026 10:39:22 +0000

The Problem Every Design Team Faces

If you've ever maintained a Design System used across multiple projects, you know exactly how much of a nightmare it can be.

A Button in Project A uses border-radius: 8px while Project B uses 12px. A Card component in the Dashboard app has a different shadow than the Mobile app. A color token named primary-500 in Figma gets called brand-blue in code by developers.

Every time you hand off a design to dev, it's like a game of Telephone — information drifts little by little until the final result no longer matches the design.

The more projects you have, the worse it gets. The problem doesn't scale linearly — it's exponential.

What Is Figma MCP?

MCP stands for Model Context Protocol — an open standard created by Anthropic that allows AI models to connect with external tools in a structured way.

Figma MCP Server is a bridge between Figma and AI coding tools like Claude Code, Cursor, or Windsurf. It enables AI to:

Read designs directly from Figma (components, layout, spacing, colors)
Understand design context — not just pixels, but hierarchy, component structure, and design intent
Generate code that matches your project's design system, not generic code
Map components between Figma components and codebase components via Code Connect

Think of it as a translator fluent in both the language of Design and the language of Code — one that also understands your project's context.

Why MCP Is a Game-Changer for Multi-Project Teams

Before MCP: The Copy-Paste Hell

Before MCP, the typical design-to-code workflow looked like this:

Designer creates the design in Figma
Developer opens the Figma inspect panel
Copies CSS values one by one (padding, margin, font-size...)
Builds a new component based on the styles they see
QA finds it doesn't match the design → fix → repeat

Each project goes through this process independently, with no shared understanding between projects.

After MCP: Single Source of Truth

With Figma MCP, the workflow becomes:

Designer creates the design in Figma (same as before)
AI reads design context directly from Figma
AI generates code that matches the project stack (React, Vue, Svelte, etc.)
Code Connect maps Figma components → codebase components
Every project uses the same mappings → consistency across projects

How to Set Up Figma MCP for Multiple Projects

Step 1: Enable the Figma MCP Server

In Claude Code or any AI tool that supports MCP, add the Figma MCP Server through its settings. Figma MCP is an official server provided by Figma.

Step 2: Understand the Core Tools

Figma MCP provides several key tools you should know:

get_design_context — Fetches the design along with code, screenshots, and hints (the most frequently used tool)
get_screenshot — Captures the design for visual reference
get_metadata — Retrieves file structure and page information
get_code_connect_map — Views mappings between Figma and Code components
add_code_connect_map — Adds new mappings

Step 3: Create Code Connect Mappings

This is the heart of scalability — Code Connect is a mapping that tells the system which Figma component corresponds to which code component.

Figma "Button/Primary"  →  <Button variant="primary" />
Figma "Card/Product"     →  <ProductCard />
Figma "Input/Text"       →  <TextField />

When AI sees a Button/Primary in a Figma design, it will generate code using <Button variant="primary" /> from your component library — rather than building a new button from scratch.

Step 4: Share Mappings Across Projects

Key insight: Code Connect mappings can be shared across projects if every project uses the same shared component library (e.g., an internal design system package).

Project A (Web App)      → uses @company/ui-kit
Project B (Admin Panel)  → uses @company/ui-kit
Project C (Mobile Web)   → uses @company/ui-kit
                              ↑
                    Code Connect maps to this

Every project gets consistent code that references the same components.

Real-World Workflow: From Design to Production

Let's walk through a real example of what this workflow looks like in practice.

1. Designer Sends a Figma URL

The designer sends the link to a completed design, such as figma.com/design/abc123/Dashboard?node-id=42:1337

2. AI Reads the Design Context

AI uses get_design_context to pull information from Figma:

Code: React + Tailwind code that Figma generates as a reference
Screenshot: The actual design image for visual verification
Hints: Design tokens, spacing values, component names

3. AI Adapts to the Project

This is the crucial part — AI doesn't use the code from Figma as-is. Instead, it adapts the output to fit the project stack:

Uses existing components from the codebase (via Code Connect)
Maps design tokens to the project's token system
Follows project conventions (naming, file structure, patterns)

4. Review & Iterate

Developers review the AI-generated code, make adjustments as needed, and commit. When iteration back to Figma is required, it happens quickly because the design-code connection is clear.

Scaling Strategies for Multiple Projects

Strategy 1: Centralized Design System + Distributed Code Connect

Maintain 1 Figma Design System library that every project references
Each project has its own Code Connect mapping (since stacks may differ)
Design tokens sync via Figma Variables → CSS Variables

Strategy 2: Design System Rules

Use create_design_system_rules to define your design system's rules:

Component usage guidelines
Spacing and sizing conventions
Color token naming conventions
Typography scale rules

These rules help AI generate consistent code even when working across different projects.

Strategy 3: Progressive Code Connect

Don't try to map every component upfront — take a progressive approach:

Start with core components (Button, Input, Card, Modal)
Add layout components (Grid, Stack, Container)
Gradually add domain-specific components (ProductCard, PolicySummary)

Every time AI needs to generate a new component that should be a shared component, add it to the Code Connect map immediately.

Lessons Learned from Real-World Usage

Benefits

Dramatically reduces the design-code gap — instead of inspecting properties one by one, AI reads the entire design context in a single pass
Consistency across projects — Code Connect ensures every project uses the same components
Reduces handoff time by 60-70% — Designer sends a Figma link, AI handles code generation, developer reviews
Higher Design System adoption — when AI automatically uses design system components, developers follow suit

Things to Watch Out For

Figma designs must be well-structured — if the design doesn't use Auto Layout or has poorly named layers, AI will generate poor code
Code Connect requires maintenance — when the component library updates, the mappings need to be updated too
AI isn't perfect — you still need to review code every time, especially for responsive behavior and edge cases
Security considerations — Figma MCP accesses your design files, so make sure access controls are properly configured

The Future of Design-to-Code

We're at an incredibly exciting inflection point in the design-to-code workflow.

Figma MCP is just the beginning. Here's what's on the horizon:

Bi-directional sync — not just design → code, but code → design as well
Automated design QA — AI verifying whether implementation matches the design
Cross-platform Code Connect — a single mapping that works across Web, iOS, and Android
Design System as Code — a design system defined in code that generates Figma components

For teams managing multiple projects, now is the best time to start building a design-to-code pipeline that scales.

Because the question is no longer "Should we use AI for design-to-code?" — it's "When do we start?"

Originally published at nuttadech.com. Follow me for more UX design insights.

Auto Layout + Shared Components: Building a Figma Design System That Actually Scales

nireadaddy — Sun, 15 Mar 2026 10:36:21 +0000

Why Auto Layout Matters

If you're still designing in Figma by manually dragging elements into position — you're working like it's 2020.

Auto Layout is a Figma feature that makes elements inside a frame arrange themselves automatically — like CSS Flexbox, but in Figma. No code required.

Why it matters:

Resize without breaking — change the width and everything adjusts automatically
Add or remove content freely — add another item to a list without manually nudging everything
Consistent spacing — padding and gaps are fixed values that never drift
Developers understand it instantly — because Auto Layout works just like the Flexbox they already use

Auto Layout 101: Starting from Zero

Horizontal vs Vertical Layout

There are only 2 directions:

Horizontal (→) — elements line up side by side, like flex-direction: row
Vertical (↓) — elements stack top to bottom, like flex-direction: column

Padding = "Edge Spacing"

Padding is the space between the frame's edge and its inner content.

Set equally on all sides: padding: 16
Set individually: top: 24, right: 16, bottom: 24, left: 16

Gap = "Space Between Items"

Gap is the distance between each element inside the frame.

Common values: 8, 12, 16, 24
Always use values from your design system's spacing scale

Alignment

Controls how items position themselves within the frame:

Top-left, Center, Bottom-right, etc.
Space between — distribute evenly (like justify-content: space-between)

Nested Auto Layout: Building Complex UI from Small Pieces

The real power of Auto Layout is nesting multiple layers — like LEGO blocks.

Example: Building a Product Card

Layer 1 — Text Group (Vertical)

[Title]        ← text, bold
[Description]  ← text, regular
Gap: 4px

Layer 2 — Content Row (Horizontal)

[Image] [Text Group]
Gap: 12px
Alignment: center

Layer 3 — Card Body (Vertical)

[Content Row]
[Price + CTA Button]
Gap: 16px
Padding: 16px

Layer 4 — Full Card (Vertical)

[Hero Image]    ← fill width
[Card Body]
Gap: 0
Border radius: 12px

Every layer is an Auto Layout frame that resizes independently — add 2 more lines of description and the card grows automatically. Shrink the width and everything reflows.

Key Principles

Build inside-out — create the smallest pieces first, then combine them
Every layer must be Auto Layout — any non-Auto Layout layer is where things break on resize
Name your layers clearly — Card/Body, Card/Content-Row, Card/Text-Group — not Frame 47

Shared Components: The Heart of Multi-Project Design

Auto Layout makes components flexible. But if every project creates its own components, they'll diverge over time until nothing matches.

How to Set Up a Shared Library

Step 1: Create a Separate Figma File for the Library

Don't put components inside project files — create a dedicated file that serves as your "Single Source of Truth."

📁 Design System Library (Figma file)
├── 🎨 Colors & Tokens
├── 📝 Typography
├── 🔲 Icons
├── 🧩 Components
│   ├── Button
│   ├── Input
│   ├── Card
│   ├── Modal
│   ├── Navigation
│   └── ...
└── 📐 Layout Patterns

Step 2: Publish as a Team Library

In Figma, go to the Assets panel → Publish library. Every project in your team will see this library and can drag components in.

Step 3: Enable the Same Library in Every Project

Project A (Web App)       → Enable "Design System Library"
Project B (Admin Panel)   → Enable "Design System Library"
Project C (Mobile App)    → Enable "Design System Library"

When you update a component in the Library, every project gets a notification to update — consistency on autopilot.

Component Variants: One Component to Rule Them All

A good component covers every use case — you shouldn't need to create a new component every time.

Example: Button Component

Using Figma's Component Properties:

Variant Properties:

Type: Primary / Secondary / Ghost / Danger
Size: Small (32px) / Medium (40px) / Large (48px)
State: Default / Hover / Pressed / Disabled

Boolean Properties:

Show Icon: true / false
Show Badge: true / false

Instance Swap Properties:

Icon: swap in any icon for context

Text Properties:

Label: change text directly on the instance

The Result

From 1 component, you get buttons for every scenario:

Primary Large with icon → main CTA button
Secondary Small without icon → action button in a table
Ghost Medium → cancel button in a modal
Danger Medium → delete button

No new components. No detaching instances. No style overrides.

Auto Layout + Components = Responsive Design

When components use Auto Layout correctly, they become naturally responsive.

Resizing Behavior

Controls how an element resizes when its parent changes size:

Fixed — stays the same size regardless of parent
Fill — expands to fill remaining space (like flex: 1)
Hug — shrinks to fit its content (like width: fit-content)

Example: A Responsive Card

Card (Vertical Auto Layout, Fill width)
├── Image (Fill width, Fixed height: 200px)
├── Body (Vertical Auto Layout, Hug height)
│   ├── Title (Fill width, Hug height)
│   ├── Description (Fill width, Hug height)
│   └── Actions (Horizontal Auto Layout, Fill width)
│       ├── Price (Hug width)
│       └── Button (Hug width)

Desktop (360px wide): Card displays normally, text and button sit side by side
Mobile (280px wide): Narrower, text wraps, button stays next to price
List view (600px wide): Wider, content spreads out elegantly

No need to design 3 separate breakpoints — Auto Layout handles it.

Best Practices for Multi-Project Design Systems

1. Establish Clear Naming Conventions

Use / to create hierarchy in the Assets panel:

Button/Primary/Large
Button/Primary/Medium
Button/Secondary/Large
Card/Product/Horizontal
Card/Product/Vertical
Input/Text/Default
Input/Text/Error

Every project sees components organized cleanly — no hunting through long lists.

2. Use Design Tokens

Don't hardcode color and spacing values — use Figma Variables:

Colors: primary/500, neutral/100, danger/600
Spacing: space/4, space/8, space/16, space/24
Border Radius: radius/sm, radius/md, radius/lg

When you need to rebrand or change themes, just update the token values — every component in every project updates instantly.

3. Document Components in Figma

Every component should have:

Description — when to use it
Usage guidelines — dos and don'ts
Link to code — if using Code Connect, link to the codebase component

4. Version Control

Use Branches in Figma when making major component updates
Review before merging, just like a code PR
Changelog — record what changed in each version

5. Create Template Pages

Beyond components, create page templates assembled from shared components:

📄 Templates
├── Dashboard Layout
├── Settings Page
├── Form Page
├── List/Table Page
└── Empty State

When starting a new project, just duplicate a template and customize — no starting from scratch.

Lessons from Managing a Design System Across Multiple Projects

What Works Well

40–50% less design time — no rebuilding components from scratch
Automatic consistency — every project uses the same components
Faster onboarding — Juniors start producing immediately with ready-made components
Easier handoff — developers inspect one component and use it everywhere

Watch Out For

Don't over-engineer — start with frequently-used components (Button, Input, Card), don't try to build everything upfront
Maintain regularly — a library that doesn't get updated is a library nobody uses
Listen to team feedback — if people keep detaching instances, your components aren't flexible enough
Don't force adoption — let people see the benefits themselves rather than making it feel like a burden

Wrap Up

Auto Layout + Shared Components isn't "nice to have" — it's the foundation that lets design teams actually scale.

Start simple:

Convert your most-used components to Auto Layout
Create a separate Library file
Publish it as a Team Library
Enable the same library in every project
Gradually add components by priority

It doesn't have to be perfect on day one — just start today.

Originally published at nuttadech.com. Follow me for more UX design insights.

Becoming a UX Manager: A Path Not Paved with Rose Petals

nireadaddy — Sun, 15 Mar 2026 10:33:20 +0000

The Crown Is Heavier Than You Think

The day you get promoted to UX Manager, everyone congratulates you. "Well deserved!" "Finally!" "You earned it!"

But nobody tells you that starting tomorrow:

You still need to do design work yourself because the team is small
You have to review every piece of work your team produces
You must attend stakeholder meetings with people who don't understand UX, every week
You have to protect your team from unreasonable demands
You need to prove the value of UX to people who keep asking "how do you even measure UX?"

The UX Manager title isn't a reward — it's an entirely new set of burdens stacked on top of the ones you already carry.

Reality Check #1: You're Still an IC

In most organizations, UX teams have 2–5 people. Being a UX Manager doesn't mean you sit back and manage — you still have to get your hands dirty with design work, just like before.

Here's what a typical day looks like:

Morning — Review 3 sets of wireframes from Juniors. Give feedback that's constructive but on point.

Mid-morning — Meet with PM about Q2 scope. Negotiate which features are essential and which can be cut.

Afternoon — Do your own design work for a feature that's too complex to assign to anyone else.

Late afternoon — Present UX strategy to the VP. Translate design language into business language.

Evening — Address the design questions dev sent over, review a PR where the UI doesn't match spec.

Night — Prioritize the backlog for next sprint.

This is every day. Not an unusually heavy one.

The Skills Nobody Teaches You

As a Designer, you need to be good at UX/UI — wireframes, prototypes, research, usability testing. That's the part above the waterline.

But as a Manager, the much larger part is underwater:

1. Negotiation

Every day you'll need to negotiate:

With PM: "This feature needs research first. I know the deadline is close, but shipping without data will cost us more time in the long run."
With Dev Lead: "I understand implementing this animation is complex, but let me explain why this transition matters for the user experience."
With VP: "I respectfully disagree with this feedback. Let me explain why the current design better addresses user needs."
With your Junior: "This work is good, but try to imagine how a first-time user who's never used the app would feel."

Negotiation isn't just arguing — it's the art of helping people who think differently see the same picture, without making anyone feel like they lost.

2. Business Acumen

A UX Manager who only speaks "user experience" without understanding business will be sidelined quickly.

You need to know:

How the company's revenue model works
What the OKRs are for this quarter
What competitors are doing
What the conversion, retention, and churn numbers look like

Because the only language executives listen to is the language of numbers — if you say "UX improved," nobody cares. But if you say "this redesign increased conversion by 15%," everyone listens.

3. Timeline Management

UX Designers manage their own timelines. UX Managers manage everyone's timelines.

Junior A's research must finish before Junior B can start designing
Feature X needs to be handed off to dev by Friday, but the design hasn't passed review
A stakeholder reschedules the design approval meeting, so the entire sprint needs to adjust

You need to see the full picture of dependencies and adjust plans in real-time as things change — which happens daily.

4. UI Consistency Across the Team

This is invisible but critical work — when multiple UX people design simultaneously, each brings slightly different habits:

Junior A uses 16px spacing, Junior B uses 20px
Components in Feature X and Feature Y look similar but aren't identical
Microcopy tone of voice is inconsistent
Icon styles mix outlined and filled

The UX Manager has to guard all of this consistency — reviewing every screen, every flow, every component to make the product feel like "one thing."

5. People Management

No UX skill prepares you for this:

A Junior whose work isn't good enough — how do you give feedback that's constructive without destroying confidence?
Team members who don't get along — how do you resolve conflict?
A team that's burning out — how do you protect them without making the business unhappy?
Hiring new people — how do you evaluate portfolios? What interview questions do you ask?

Pulled in Two Directions

The hardest part of being a UX Manager is existing between two worlds.

The Business World

Executives want:

Features delivered on schedule
Lower costs, higher revenue
Everything measured in numbers
Move fast, ship fast

The Craft World

The UX team wants:

Adequate time for research
Creative freedom
Quality that isn't compromised by deadlines
Recognition for invisible work

The UX Manager must translate between these two worlds constantly.

When the VP asks "why isn't the design done yet?" you explain that research takes time without making the VP think the team is slow.

When your Junior asks "why did we cut this feature?" you explain that a business decision doesn't mean UX doesn't matter.

You're a translator between business and craft — and often, neither side will be happy with you.

Lessons I Learned the Hard Way

"Being a good manager ≠ being the best designer on the team"

When I first became a manager, I tried to also be the "best designer on the team" — reviewing every piece of work and fixing it myself, giving extremely detailed feedback. The team ended up feeling zero ownership.

I learned that a manager's job isn't to produce the best design, but to enable the team to produce the best design on their own.

"You don't need to be in every meeting"

Early on I attended every meeting — every design review, every sprint planning, every stakeholder sync. I'd end up with 6–7 hours of meetings per day and 1–2 hours of actual work.

I learned that you must choose which meetings need you personally and what can be delegated — which is also a way of developing your team.

"Conflict isn't a bad thing"

I used to fear conflict — afraid that arguing with PM would ruin the relationship, afraid that giving Junior too-direct feedback would make them quit.

I learned that healthy conflict is a sign that people care — the problem isn't conflict itself, but conflict that goes unresolved.

"You don't need to prove yourself every day"

UX Managers don't have tangible deliverables every day — no wireframes shipped daily, no code committed daily.

I used to feel guilty thinking "I didn't produce anything today" when I'd actually spent the entire day unblocking the team, making 20 decisions, and protecting scope from scope creep.

I learned that a manager's value isn't in what they make with their hands, but in the outcomes the entire team delivers.

A Survival Guide

For those who are UX Managers or about to become one, here's what I wish someone had told me:

1. Build Trust Before Changing Anything

Don't rush to change processes in your first month. Take time to understand — what does the team need? What are the business pain points? Why do current processes exist?

Trust must be built before authority follows.

2. Shield Your Team from Noise

The most important job of a UX Manager is being a barrier between the team and external chaos.

Stakeholders change their mind every week? You handle it, don't pass it to the team.
Features get added mid-sprint? You push back, not let the team crunch.
Executives give subjective feedback? You translate it into actionable items before passing it on.

3. Demonstrate Business Impact

Don't wait for people to ask "what does UX actually do?" — tell them first.

Create monthly reports translating UX work into business metrics
Document before/after of every design change with numbers
Build a library of case studies as evidence

4. Don't Abandon the Craft

Even as a manager, don't stop doing design entirely.

You don't need to design every feature, but choose 1–2 of the most complex projects to do yourself, so you can:

Keep your skills sharp
Understand the pain points your team actually faces
Maintain credibility as a design leader

5. Invest in People

The most worthwhile long-term investment is making the team stronger.

Build a design system that reduces friction
Have quality 1-on-1s — actually listen, don't just check status
Let Juniors try leading projects (with appropriate guardrails)
Share context about business decisions — a team that understands "why" makes better decisions

6. Take Care of Yourself

UX Manager burnout rates are extremely high — because you absorb pressure from every direction.

Set clear boundaries — you don't need to reply to Slack after 8 PM
Find a mentor who's also a manager — someone who understands what you're going through
Accept that some days "good enough" is enough — you don't have to be perfect every day

Final Thought: Not Rose Petals, But Not a Dead End Either

Being a UX Manager is hard — harder than anyone tells you, harder than the job description says.

You'll be exhausted. You'll feel discouraged. You'll feel like you can't keep up. You'll question why you didn't just stay as an IC.

But when you see a Junior who once struggled now confidently leading a project on their own. When you see a product your team built helping users do something that used to be hard with ease. When you see that the team you built is strong enough to function even when you're not there.

You'll know it was worth it.

The path to UX Manager isn't paved with rose petals.

But the flowers you plant — they'll bloom on their own, if you tend to them well enough.

Originally published at nuttadech.com. Follow me for more UX design insights.

AI Is Not Replacing UX Designers — It's Replacing the Boring Parts

nireadaddy — Sun, 15 Mar 2026 10:19:04 +0000

The panic is real — but misplaced

Every few months, a new article declares that AI will replace designers. I've been designing for over 15 years, and I've heard this before — about templates, about no-code tools, about offshore teams. None of them killed design. AI won't either.

But AI is changing how I work. And honestly? It's the best thing that's happened to my workflow since Figma replaced Sketch.

What AI actually replaced in my day-to-day

Here's what I no longer do manually:

Research synthesis — I used to spend 2-3 days reading interview transcripts and clustering insights on sticky notes. Now I feed transcripts to an LLM and get a structured summary in minutes. I still validate everything, but the first pass is 10x faster.
Content drafting — Writing UI copy, error messages, onboarding flows. AI generates 80% of the first draft. I refine the voice and context.
Competitive analysis — Instead of manually screenshotting 20 competitor apps, I describe what I'm looking for and get a structured comparison.

What AI can't replace

The interesting stuff. The stuff that actually makes design design:

Knowing which problem to solve — AI can analyze data, but it can't sit in a room with a frustrated insurance customer and feel the weight of their confusion.
Political navigation — Half of UX is convincing stakeholders. AI can't read a room.
Taste and restraint — AI generates. Designers curate. Knowing what to remove is still a human skill.

My current AI toolkit

Claude — My thinking partner. I use it for brainstorming, writing, and rubber-ducking design decisions.
Gemini — Research synthesis and content generation.
Imagen 3 — Quick concept visuals and blog thumbnails.
Claude Code — Building prototypes and this entire website.

The real question

It's not "will AI replace designers?" — it's "will designers who use AI replace designers who don't?"

After 15 years, I'm more productive than ever. Not because AI does my job, but because it handles the parts I never liked doing anyway.

The craft remains. The empathy remains. The judgment remains.

The busywork? Good riddance.

Originally published at nuttadech.com. Follow me for more UX design insights.

How AI Coding Is Reshaping UX Design — And Whether the Future Is Still Bright

nireadaddy — Sun, 15 Mar 2026 10:19:00 +0000

If AI Can Code, Do We Still Need Designers?

This question gets louder every day.

Claude Code builds React components from Figma designs in 30 seconds. Cursor writes responsive layouts from a single prompt. v0 by Vercel generates entire pages from short descriptions.

If your primary value as a UX Designer is "make wireframes and hand them to dev" — yes, you should be worried.

But if you understand that UX Design was never just "making pictures" — your future has never looked brighter.

What AI Coding Has Already Changed

Design-to-Code Is No Longer a Bottleneck

The handoff between designer and developer used to be the biggest pain point — designer makes a mockup, developer inspects pixel by pixel, copies CSS property by property, then QA finds mismatches. An endless loop.

Now, AI tools like Figma MCP + Claude Code can:

Read design context directly from Figma
Generate code matching the project's stack
Reuse existing components from the design system
Create responsive layouts automatically

Handoff time reduced by 60–70%. That's a fact.

Prototyping Is 10x Faster

Previously, testing an idea meant building a Figma prototype — which was just click-through at best. Now I can:

Describe the concept to AI
AI creates a working, interactive prototype
Test with users immediately
Iterate from feedback in 30 minutes, not 3 days

"Making UI" Is No Longer a Competitive Advantage

When everyone can generate good-looking UI with AI, the ability to "make pretty interfaces" stops being what makes you special.

It's like how Canva let everyone do graphic design — yet truly skilled graphic designers are busier than ever. Because the real skill was never "using the tool." It was thinking.

What AI Still Can't Replace About UX Designers

This is the core of this article — I believe 80% of the UX work that actually matters is something AI still can't do.

1. Problem Framing — Knowing What Problem to Solve

AI can write code, but AI doesn't know what the real problem is.

I once worked on a project where the client said "make the dashboard prettier." But when we did research, we found the real problem was that users didn't understand what the numbers on the dashboard meant — it wasn't about aesthetics at all.

AI will happily make your dashboard prettier. But it will never tell you, "Hey, the real problem isn't visual."

2. User Empathy — Understanding People Unlike Ourselves

I once watched a 60-year-old farmer try to use an insurance app. He couldn't tap the "Next" button because it was too small for fingers that had worked hard his entire life.

No AI can feel that. No AI can see the frustration on someone's face when they struggle with technology and understand, deep down, that "we need to redesign this."

3. Stakeholder Navigation — Office Politics

Half of good UX work is convincing the people in the room.

The VP wants this feature because a competitor has it
The PM wants to cut scope because the deadline is near
Dev says "can't be done" when they mean "don't want to do it"
The CEO saw Apple's app and wants something just like that

AI can't read a room, negotiate trade-offs, or build trust with stakeholders.

4. Ethical Judgment — Knowing What Not to Do

AI can design dark patterns that manipulate users brilliantly — because it optimizes for whatever metric you tell it to.

But knowing what you shouldn't do is a human skill. "We could make unsubscribing harder, but we shouldn't" — that's judgment AI doesn't have.

5. System Thinking — Seeing the Big Picture Across All Touchpoints

AI excels at component-level design — designing a button, a form, a card.

But seeing how an entire journey from awareness to retention should feel — connecting 20 touchpoints into one coherent experience — that's still human work.

The New Role of UX Designers in the AI Coding Era

The role is changing, not disappearing.

From "Mockup Maker" → "AI Director"

Instead of pushing pixels in Figma all day, UX Designers now:

Write clear prompts to get AI to generate UI that matches intent
Review and curate AI output — keep what works, cut what doesn't
Iterate faster — try 10 variations in 1 hour instead of 2 variations in 1 day

From "Send Specs to Dev" → "Build Real Prototypes Yourself"

With AI coding tools, UX Designers can:

Create working prototypes with real interactions
Test concepts before they enter a sprint
Prove ideas with functional prototypes instead of static mockups

This is the biggest superpower — when you present an idea as a working prototype instead of a wireframe, your credibility skyrockets instantly.

From "Design Pixels" → "Design Systems + AI Rules"

Instead of designing every screen by hand, UX Designers will:

Build comprehensive Design Systems
Define rules for AI to follow when generating UI
Maintain consistency across AI-generated touchpoints

New Superpowers for UX Designers Who Use AI

I believe UX Designers who embrace AI become exponentially more powerful:

Research synthesis 10x faster — feed interview transcripts to AI and get structured themes in minutes, not days
Rapid prototyping — from idea to working prototype in 1 hour
Data analysis — ask AI "what does the user behavior data say?" instead of reading spreadsheets
Content at scale — generate UI copy, microcopy, error messages for every edge case
Accessibility audit — let AI check WCAG compliance automatically
Competitive analysis — analyze 20 competitors in 1 hour instead of 1 week

So, Is the Future Still Bright?

Short answer: Yes — for those who adapt.

Paths That Are Opening Up

UX Engineer — People who can both design and code with AI tools will be in massive demand, because they eliminate the gap between teams
AI Product Designer — People who understand how to design UX for AI products (conversation design, trust building, error handling)
Design Strategist — People who see the big picture, set direction, and decide what to design and what not to design
Design System Architect — People who build design systems that both humans and AI can use together
UX Researcher + AI — People who use AI to synthesize research but still lead with human understanding

Paths That Are Shrinking

Let's be honest — some roles will decline:

UI Designers who only do visuals — AI can do that now
Designers who only wireframe from specs — AI does it faster
Designers who skip research — no insight = no value that AI can't provide

What to Invest in Right Now

Learn AI tools — you don't need to write code, but you need to know how to use AI coding tools for prototyping
Practice problem framing — why before what. Ask "what's the real problem?" before "what should I design?"
Build research skills — the more AI can do UI, the more you need to know what the right UI is
Sharpen communication — the ability to present, negotiate, and convince matters more than ever
Understand data — read analytics, set metrics, measure design impact

Final Thought: From Tools to Thinking

Every time new technology arrives, people fear it will replace them.

Photoshop didn't replace graphic designers — it made them more capable.
Figma didn't replace UX Designers — it made collaboration easier.
AI Coding isn't replacing UX Designers — it's making designers more powerful than ever before.

But there's a condition: you have to stop defining yourself by the tools you use.

"I'm a Figma expert" ← This is dangerous.
"I'm someone who understands users and solves their problems" ← This is future-proof.

AI will change the tools we use, but it won't change why we do this work — because the purpose of a UX Designer was never about pixels.

It was always about people.

And as long as there are people, there will need to be someone who understands them.

Originally published at nuttadech.com. Follow me for more UX design insights.