DEV Community: Yurick Hoang

Using AI without losing people's trust: a designer's view

Yurick Hoang — Sun, 08 Nov 2026 05:46:20 +0000

A few days ago I read "Don't let AI cost you your credibility at work" by Hoang Nguyen in the MindYourMind community. He tells the story of a Product Owner candidate who submitted a test almost entirely written by AI, then kept using AI to answer questions during the presentation. The test ended after two questions.

It made me realize this is not just a PO problem. As a designer, I have seen it too, and I have received documents from other stakeholders with the same issue. My previous post asked whether AI is making designers lazy thinkers, which is about what happens inside each of us. This one is about what happens outside: other people look at our work and decide whether to trust us.

A polished test, but two questions were enough

I once looked over a test from a designer candidate. The brief was to improve the checkout screen of a shopping app. The submission looked great: a problem statement, user insights and five proposed improvements. Proposal number one was "optimize the checkout journey to reduce friction for users".

During the presentation, I asked a simple question: "Which step has the friction? Where do users get stuck?". The candidate read the slide back in different words, but could not point to a step. I asked again: "If you could only do one thing, what would you pick and what would you drop?". No answer either, because those five proposals had been listed by AI, and none had been weighed by the candidate.

A more convincing answer can be very simple: "At the address step, the form has 9 fields. I asked 3 friends to fill it in and all 3 stopped at the postal code field. I would remove that field first." No fancy wording, it just shows you looked at the problem yourself.

I don't think the candidate was weak. A test simply isn't there to see how polished your document is, but how you think when you face a problem.

Three places designers lose points

In my view, these are the three places where AI most easily costs a designer credibility, because they are where others judge how we think.

Explaining design decisions

A design decision holds up when it answers three questions: what is the problem, what are we trading off, and how will we measure it. AI is quick to write lines like "optimize the user journey" or "elevate the visual experience". They are not wrong, they just say nothing specific, so one "why" is enough to expose them.

The same proposal, presented two ways. The mockup, figures and content have been changed to protect the project's confidentiality.

Presentation B is not longer than A. It simply contains things the author had to find out: 5 of 8 testers had to scroll to see the battery level, the weather card has to give up its spot, and after launch we will measure time to find the battery level. AI can help phrase those points more tightly, but it cannot come up with them for you.

Writing UX copy

This is where the "AI voice" shows most, because end users read it every day: long sentences with many clauses, words like "journey", "seamless", "optimal", and structures that read like a literal translation. In Vietnamese this is especially visible, and Hoang Nguyen notes he almost never saw such phrasing at work before AI became common.

An AI insight card before and after editing. The mockup, product name, figures and content have been changed to protect the project's confidentiality.

Nielsen Norman Group also points out that AI drafts tend toward generic phrasing, drift from brand voice, and know nothing about your users or context. Their advice is to treat AI as a first-draft collaborator and always have a person review the copy before it ships. The edited card above does not need beautiful writing. It only needs to answer what the user wants to know: does today affect me?

Writing case studies and portfolios

A case study is where recruiters learn how you work. One written with AI usually has every section: context, problem, process, results. But read closely and you can't find yourself in it. No moment where you were wrong, no hard decision, no detail only someone on the project would know.

People who read many case studies notice quickly. And as in the example above, they will check in the interview.

Across stakeholders: one missing edge case and the flow falls apart

For documents that pass between stakeholders, the problem is usually not the wording but what was never written down. I once received a requirements document that looked complete: goals, user stories, acceptance criteria. But edge cases were almost absent: what happens if the connection drops midway, what to show when there is no data, where users resume if they come back mid-flow.

Once design and development started, those questions came up one by one. Everyone guessed differently, the flow got messy, and we had to go back into meetings to align. The time the document saved its author was simply moved to the whole team.

In another case, the acceptance criteria (ACs) were written by AI separately for each user story, and the author never put them side by side to cross-check. Each AC made sense on its own, but together some contradicted each other: one required auto-saving a draft on exit, another required clearing data on exit. Developers built every AC correctly, and the flow was still wrong.

There are also times when a team uses AI to build the interface directly to move fast, and that version goes live. Each screen looks fine on its own. But when the team's design system is not tight enough, every AI-generated screen picks its own colors, spacing and components. Put together as a whole platform, the screens no longer speak the same language. In the end, designers have to take that live version as the starting point, bring it back into Figma, and review and fix it until it is consistent. The time saved by building fast gets paid back later in rework. My takeaway: AI builds fast and right only when the design system is clear enough for it to follow. If the foundation isn't solid, AI just makes the inconsistencies show up sooner.

Researchers at BetterUp Labs and the Stanford Social Media Lab call this kind of output "workslop": AI-generated content that looks like good work but lacks the substance to move a task forward. In their survey, about 40% of workers said they had received workslop in the past month, spending nearly two hours on average dealing with each instance. More striking, about half of recipients saw the sender as less creative, less capable and less trustworthy.

Nobody says anything, but people remember

The part of Hoang Nguyen's post I agree with most is that trust is not lost in one go. People still say thanks, still use the document, sometimes don't even ask for changes. But next time there is a hard problem, they think of someone else first.

(Every document gets a thank-you, but the trust level never shows up anywhere. See the animation in the original post.)

For a designer, that might mean not being invited to a product direction meeting, or having your proposals go through an extra round of checks. Nothing tells you it has started.

Using AI in a way people can still trust

To be honest, the website you are reading was also built with AI, vibe coding style. I use it as a place to show my projects and notes, not to sell web development or to suggest I am a developer. What I take responsibility for is what sits on it: the design decisions, the project stories and every post. I think being clear about which part AI helped with and which part is mine is also a way to keep people's trust.

I still use AI every day: summarizing documents, suggesting phrasing, listing edge cases for me to review, sketching a few options to compare. But before sending anything important, I ask myself four questions.

Four questions before hitting send, and a spec excerpt before and after rewriting. The mockup and content have been changed to protect the project's confidentiality.

Can I say the key message again in my own words? If I need to look at the slide, I may not really understand it yet.
Can I answer "why not the other option"? A decision with no rejected alternative is often not a decision yet.
Have I opened the source of every number myself? AI is very good at producing numbers that sound plausible.
Is there any sentence I would never say out loud? If so, I rewrite it the way I would say it in a meeting.

The fourth one sounds simple, but it works best for me. Sometimes I have to drop a line that sounds great and replace it with a plainer one that says what I actually mean.

Wrapping up

I don't think there is one right way to use AI. Every person and every team is finding their own rhythm with a tool that changes almost every month. Some of the stories in this post are moments I stumbled on myself. I wrote them down to remember, not to say who is right or wrong.

For me, working in a world with AI feels like having a very fast collaborator. I hand it the repetitive work and save my time for the parts that need me most: understanding users, weighing trade-offs and being able to explain my decisions. When someone asks "why", the answer comes from what I actually understand, and that is the part AI cannot hold for me.

Hoang Nguyen has a comparison I really like: when your AI tokens run out you can buy more, but trust takes time to build. So I choose to keep using AI and keep learning with it, while holding on to the habit of understanding what I send out. If you are also figuring out how to work with AI and want to talk, feel free to reach out on yurickart.com!

Sources

The survey data below was collected from US workers, has limited scope, and does not replace my own point of view.

Hoang Nguyen (2026). Đừng để AI làm mất sự tín nhiệm của bạn trong công việc (Don't let AI cost you your credibility at work). MindYourMind (members-only post, in Vietnamese).
Niederhoffer, K., Rosen Kellerman, G., Lee, A., Liebscher, A., Rapuano, K., Hancock, J. T. (2025). AI-Generated "Workslop" Is Destroying Productivity. Harvard Business Review.
Kaley, A. (2026). UX Writing: FAQs from Practitioners. Nielsen Norman Group.

Originally published at yurickart.com.

Managing variables in a design system: a three-layer structure for products with dark mode

Yurick Hoang — Sun, 25 Oct 2026 07:48:36 +0000

I once opened a design system file and found the same gray typed in by hand in more than a dozen places, each a few hex codes off. Rebranding meant fixing every layer one by one. Figma variables exist to end that, but only if you organize them on purpose. This post is how I build and manage variables for a mobile product design system with dark mode, along with the conventions I think are worth keeping.

Three layers, one direction of reference.

Start with the file structure, not the colors

Before creating any variable, I organize the file. The foundation pages come first: Color, Typography, Spacing, Corner Radius, Shadows, Backdrop Blur, plus Anatomy and Design annotations. Core Components follow, grouped with divider pages so the Pages panel is easy to scan.

This order is not just for looks. Components depend on foundations, so putting foundations first reminds the whole team that when a component needs changing, you look up first to see whether the tokens are enough.

Foundations first, components after.

Layer 1: Primitives, raw colors with no meaning

The first collection holds raw values only. Each hue has a scale from 100 to 900, with 500 as the base color. Grey alone adds 0, 850 and 950 because dark mode needs more dark steps. This collection has a single mode and one rule: designers never bind primitives directly to components.

A name like color/Primary/500 tells you what the color is, but not where to use it. The question of "where to use it" belongs to the next layer.

Primitives: 93 color variables, one mode.

Layer 2: Semantic tokens, named by role

This is the most important layer. Each token describes a role: bg-surface, text-secondary, icon-disabled, stroke-brand-primary. This collection has two modes, Light and Dark, and each mode points to a different primitive.

A few things I found useful when building dark mode:

The more a stacked background rises, the lighter it gets. Canvas uses Grey/950, container uses Grey/900, surface uses Grey/850 and secondary surface uses Grey/800.
Light subtle backgrounds do not need a new color. In dark mode I reuse the base color at roughly 15 to 20 percent opacity.
Status colors go one step darker: for example, Error uses Red/500 in Light and Red/600 in Dark so it does not glare on a dark background.

That way a button only needs to bind to Colors/Main/Primary/solid. Switch the layer from Light to Dark and everything changes automatically.

One token, two modes. The table below shows how tokens point back to primitives.

One job per collection

I split variables into several collections instead of putting everything into one. Each collection holds exactly one type of value: raw colors, theme colors, typography, spacing, stroke, radius, icon size, date and time formats, data formats and title styles. This has three benefits: it is easy to find things, easy to control who can edit, and easy to publish in parts.

Three small conventions keep the Variables panel tidy:

Prefix names with 01 to 10 so Figma sorts them in the right order.
A collection that starts with an underscore is an internal set, not meant for library users to pick.
Name by role (text-secondary), not by color (grey-600). When the color changes, the name stays correct.

11 collections, one job each.

Number scales are variables too

Not just colors. Spacing, corner radius, stroke weight and icon size are all Number variables. Spacing has 18 steps from 0 to 256, radius has 8 steps up to 999 for circles, stroke has 3 steps, and icon size has 13 steps from 10 to 128.

The biggest benefit is discipline: designers pick from an existing scale instead of typing odd numbers like 13 or 22. To change the feel of the whole product, for example softer corners, you change a few radius variables instead of editing every layer.

Spacing, radius, stroke, icon size.

Typography: size and line-height as pairs

The typography collection has 36 variables: two font family variables (heading and body), four font weight variables, and a font size and line-height pair for each text role. Figma text styles simply bind to these variables. When you need to adjust the type scale, you edit in one place and every text style updates.

Type scale: one size and line-height pair per role.

Use modes to switch a whole type set

My favorite is the "Title Type" collection. It has four modes (32, 24, 20, 16), each pointing to a matching title size, line-height, letter-spacing and subtext size. One title component, and switching mode switches the whole set. No need for four variants, and no need to remember to adjust letter-spacing by hand.

One component, four modes.

String variables for display data

Variables come in four types: Color, Number, String and Boolean. I use String too. One collection stores sample strings for data formats such as phone numbers or emails, with three modes: fully shown and two masking styles. Another collection stores date and time formats in two locales. Every mock-up pulls its sample data from here, so the design and the real product follow the same convention and you never see a different date format on every screen.

Values shown are illustrative.

Use styles for shadows and blur

Variables cannot store effects yet, so shadows and blur stay in Effect styles. I name them on the same xs, sm, md, lg, xl scale so they are as easy to remember as the other scales. Shadows in this system are very light, with opacity only from 3 to 9 percent.

Effect styles: shadows and backdrop blur.

A checklist for managing variables

Once it is built, the hard part is keeping it from breaking over time. I use this list:

Never bind primitives to components. Always go through a semantic token.
Set a scope for every variable. Background variables should only appear when picking a fill, spacing variables only for gap and padding. The picker list gets noticeably shorter.
Rename instead of deleting. Figma binds variables by ID, so renaming does not break links, while deleting a variable in use does.
Check both modes whenever you add a token. A new token missing its Dark value is the easiest bug to miss.
Scan for hand-applied colors. Select a whole frame, open Selection colors, and replace any color not bound to a variable with a token.
Document changes. Each time you publish the library, write a few lines of notes so the team knows what just changed.
Keep the reference chain short. Primitive, semantic, then stop. The more intermediate layers, the harder it is to trace back.

Conclusion

Variables do not make a design system good on their own. What makes the difference is convention: what each layer holds, how things are named and who can edit them. If you are just starting, do three things first: separate primitives from semantic tokens, name by role, and build Light and Dark from day one. The rest can be added gradually.

If you are building a design system and want to chat, you can reach me at yurickart.com.

Originally published at yurickart.com.

Is AI making designers lazy thinkers?

Yurick Hoang — Sun, 25 Oct 2026 07:12:51 +0000

I think AI is doing something good for design: it makes the field more accessible than ever. Someone who has never opened Figma can still build an interface. A PM with no design background can make a prototype to get an idea across. A developer can get fairly polished screens from a few lines of prompt.

I don’t see anything wrong with that. Technology is helping more people turn ideas into something they can see, click and test. But it also left me with a question: when making an interface becomes this easy, are we starting to take the thinking behind it too lightly? This post is what I think about that question, with two studies for extra perspective.

When the answer arrives before the question

Before AI, getting a design request meant understanding the problem, looking at similar products, analyzing information and trying several options. Some tasks that looked simple took a long time. Should people log in with email or phone first? Should we ask them to create a password right after the OTP step? If we add one more step to the sign-up flow, is it still a reasonable length? One icon family for everything, or split by role?

Sometimes I tried one direction, dropped it and started over. That process wasn’t always fun, but looking back, I learned a lot from the times I had to find the answer myself.

Now AI can propose a solution almost instantly. Describe a sign-up screen and it returns a full layout with a form, buttons and the familiar error states. It can look good, make visual sense, and sometimes beat the first option I would have come up with. What bothers me isn’t the visual quality. It’s that when an answer arrives this fast, it is very easy to skip asking my own questions.

Instead of asking what users need, I start asking AI how to design it. Instead of thinking about how to solve the problem, I tweak a solution that already exists.

A design that looks reasonable doesn’t mean I understood the problem.

The worry is not being able to explain my own decisions

I have received very short requests from PMs, sometimes just a reference image and one line: “See which one is usable.” That is a perfectly normal situation in product design. The PM may already picture what they want to see, but not necessarily how to organize the information or the interaction. A designer’s job is not to recreate the reference, but to understand which parts of it actually fit the product.

Another example is choosing icons for the first version of an app. The team had several icon families: 3D Clay, 3D Glossy, 2D and line. AI can build all four on the same screen in minutes, and all four look fine. For the first version, the team temporarily picked two: 3D Glossy for things you can tap, minimal line icons for information.

The icon families and the rule for the first version of the app. The mockup, colors and content have been changed to protect the project’s confidentiality.

The rule sounds simple, but behind it are questions I have to be able to answer: why split by role instead of by screen, do people looking at a 3D icon understand it is something to tap, what happens when an info item later becomes tappable, and why this is only a temporary choice for the first version.

AI can make a better icon set than I can. But if I can’t explain those things, I am only picking an option that looks fine, not making a design decision. I think the ability to produce an interface will make less and less difference. The ability to explain and defend a design decision is what is worth investing in.

Everyone can make UI. Is that a good thing?

I think yes, but not entirely. AI is removing part of the technical barrier in the field, and I support that. Not everyone with a good idea needs to master Figma. Not every PM needs to become a designer to present an idea. If AI helps someone visualize their thinking quickly, collaboration across teams can get more effective. The more accessible the tools, the wider the room for creativity.

The problem starts when we confuse knowing how to make an interface with knowing how to design a product. Anyone can make a very professional-looking login screen without ever thinking about validation, error states, accessibility, or how to organize information across a whole app. On simple screens that is not a visible problem. As the product gets more complex, the gaps in knowledge show up:

If users drop off midway and come back, where do they continue from?
If a phone number is already linked to another account, what do they see and what do they do next?
Do a new device and a familiar device follow the same flow?
If the product has many states, how does the interface respond?

Take the sign-up flow of a super app I am working on: the main steps are just phone number, OTP, password, basic info, face and PIN. The hard part is the remaining branches: what a user sees when blocked because the phone number is already linked to another account, which step a user returns to after dropping off, and why a device only becomes trusted after the whole registration is complete. Those screens rarely appear in a nice screenshot, but without them the product can’t be used.

A registration flow with blocked, leave-midway and resume branches. Illustrative mockup, content changed to protect the project’s confidentiality.

I don’t think only designers are allowed to answer those questions, but anyone making design decisions should care about them. Two products looking alike doesn’t mean the two people who made them understand the same things. I think this will be a big challenge when evaluating designers in the future.

Beginners improve faster, but may miss important lessons

If I were starting to learn design today, I would probably use AI a lot: asking about layout, hierarchy and typography, generating many options to compare. That is an advantage earlier generations didn’t have. But beginners can fall into a trap: getting a good result before understanding how it was made.

Before AI, getting a layout wrong forced me to find out why. I read, looked for examples, tried and adjusted. Those slow tasks built my design intuition. With AI, some of those hard stages can be skipped. That is not necessarily bad, because nobody needs to do everything the hard way just to prove they have skills. But if we keep skipping the parts that need thinking, I wonder where our knowledge will grow from.

Lee et al. (2025) surveyed 319 knowledge workers who use generative AI at least weekly. People who trusted AI more reported using less critical thinking, while people more confident in their own ability reported more critical thinking [1]. This is self-reported data and does not show that AI reduces intelligence, but it is worth reflecting on how we spend our thinking effort.

New designers need AI just as much as experienced ones. But more than a correct answer, they need the ability to recognize why the answer is correct.

The first option is hard to let go of

Working with AI, I noticed that the first option tends to have a lot of influence. When AI gives a fairly complete layout, the easiest thing is to keep editing it: change a color, swap a component, adjust spacing, add or remove a few elements. In the end there is a new interface, but the structure of thinking is almost the same as the first option. From the outside the designer is still working, but inside, the range of exploration may have narrowed very early.

Wadinambiarachchi et al. (2024) ran an experiment with 60 people: the group using an AI image generator for ideation fixated more on the initial example, known as design fixation [2]. The result doesn’t represent every UI design situation, but it points to a real risk: tools that suggest ideas can also limit the directions we think of next.

How I want to use AI

That is why I am changing how I use AI. Instead of always asking AI to propose a design, I ask more about my own assumptions: what is the weakness of this option, is there a completely different approach, if I removed its main element would the goal still be met, in which case would the current solution fail? I want AI to play the critic, not only the one who hands out answers.

I also don’t think the future of UI/UX is a race to see who makes the most screens in the shortest time, because if speed is the standard, AI will keep gaining the advantage. I hope technology helps designers cut repetitive work so they can spend time on things worth thinking about: understanding users, talking with PMs, understanding the business context, weighing trade-offs, checking usability, working with developers to get the solution into the real world. These things rarely show up in a pretty screenshot, but they directly affect product quality.

When PMs or developers can build prototypes themselves, designers get more material to discuss. Instead of saying “that’s not your job”, I would rather ask: how do we turn that first prototype into a solution with real value? But AI helping more people take part in making products doesn’t mean every option created should become a product. That makes evaluating design even more important.

Conclusion

Any technology that makes work easier can make us dependent on it, and AI is no exception. I don’t see that as a reason to limit AI, but as a reminder about how I work. If AI saves me two hours of building an interface, do I spend those two hours understanding the problem better? If AI gives me five options, do I really evaluate them or just pick the prettiest? If a screen is generated almost complete, do I still have the patience to ask whether it needs to exist at all?

When making an interface is no longer rare, designers need to find their value in deeper skills. Not to prove we are better than AI, but because a good product always needs more than a good-looking interface.

If you are thinking about this too and want to talk, message me through the contact section!

References

Both studies below have limited scope and do not replace my own point of view.

Lee, H.-P., Sarkar, A., Tankelevitch, L., Drosos, I., Rintel, S., Banks, R., Wilson, N. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI 2025.
Wadinambiarachchi, S., Kelly, R. M., Pareek, S., Zhou, Q., Velloso, E. (2024). The Effects of Generative AI on Design Fixation and Divergent Thinking. CHI 2024.

Originally published at yurickart.com.