Hey and welcome back to a new week!

I’m just back from Hatch Conference, where I hosted and moderated a roundtable called Training the Next Generation of Designers.

We had a very honest conversation about what still matters for juniors now that AI can produce so much, so quickly. That conversation became the starting point for this week’s article.

In this issue:

🛳 LEARN FROM ME HOW TO SHIP WITH AI

Copy edits, spacing fixes, small UX improvements — these shouldn't have to wait weeks in an engineering queue. Designers and PMs often have the clearest eye for what needs to change, but not the path to ship it themselves. That gap is closing fast.

​You won’t just watch AI write code. You’ll use it to navigate a real product, make a focused improvement, test it locally, and push your work to GitHub. You’ll work inside an existing product rather than starting from a blank page — learning how to understand the codebase, find where your change belongs, build it with AI, test the result, and share it through GitHub.

AI has made it possible to produce an impressive amount of design work very quickly.

You can turn a rough idea into screens, flows, copy, prototypes, components, code, and polished presentation assets in a fraction of the time it used to take. If you use the best tools well, the first result can look surprisingly complete.

That creates an uncomfortable question for junior designers:

What should I still spend my time learning?

If the tools can generate the screens, help with the research plan, suggest the UX copy, build the prototype, and even critique the result, where does that leave someone who is still trying to enter the industry?

I think the answer is much clearer than it sometimes feels.

There are two things I would invest in heavily if I were starting now:

Neither of these has become less important because AI can execute faster.

They have become more important because execution is getting cheaper.

You can ask an AI tool almost any design question now.

It can explain typography. It can critique a layout. It can give you a learning plan, suggest portfolio improvements, role-play an interview, or point out inconsistencies in a flow. Used well, that is incredibly valuable.

But it is not the same as having someone experienced understand you over time.

A good mentor can notice that you keep avoiding visual craft because you feel more comfortable talking about process. They can see that the roles you apply for do not match the work in your portfolio. They can tell when you are solving the wrong problem, hiding behind another course, or polishing a project that has already taught you everything it can.

They can also give advice with a real career in mind.

If you want to become a design engineer, you need guidance from somebody who understands how design and engineering come together in actual teams. If you want to work on complex B2B products, a mentor whose experience is mainly brand and marketing design may still be helpful—but they may not be the right person to steer your whole portfolio.

The fit matters.

This does not mean you need one perfect mentor who guides every part of your career. Most people learn from a mix of managers, more experienced designers, peers, teachers, colleagues, communities, and occasional conversations with people whose work they respect.

What matters is that your development is not happening inside a closed loop between you and a machine that is always ready to produce another answer and is biased towards validating you.

You need feedback with stakes. You need somebody to disagree with you. You need somebody whose judgment you trust to say, “This is not ready yet,” or, “You are better at this than you think—push it further.”

And you need external validation.

That phrase can sound unhealthy because nobody should build their entire self-worth around other people’s approval. That is not what I mean.

Design is a collaborative profession. The work needs to make sense to users, teams, clients, and hiring managers—not only to the person who made it. At some point, your internal feeling about the work has to meet somebody else’s experience of it.

External validation tells you whether your judgment travels.

If several experienced designers struggle to understand the hierarchy of your case study, that is useful information. If engineers repeatedly find your flows difficult to implement, that is useful information. If a mentor says your project has become much stronger but your homepage still undersells it, that is useful information.

AI can help you interpret feedback. It cannot replace the fact that feedback came from another person with a real perspective.

This is where the conversation often becomes more controversial.

One side says juniors should learn the fundamentals first: typography, hierarchy, composition, spacing, colour, interaction principles, information architecture, usability, accessibility, and the patterns people already understand.

The other side says that tools are changing too quickly for a traditional learning path. Juniors should build, experiment, ship, and learn through making instead of spending months studying rules.

I do not think those positions are as far apart as they sound.

You should build. You should use the new tools. You should make real things and learn through the messiness of trying.

But building faster is only useful if you can tell whether what you built is any good.

That is what fundamentals give you.

They do not only make your execution stronger. They make your judgment stronger.

Typography teaches you why a page feels difficult to scan. Hierarchy teaches you why everything is competing for attention. Layout and spacing teach you why a screen feels tense, empty, unbalanced, or strangely amateur. Interaction principles help you notice when the product behaves in a way users will not expect. Familiar software patterns help you understand when originality is useful and when it is simply creating friction.

The same applies beyond visual design.

How information is grouped, labelled, ordered, and revealed is fundamental. So are feedback, error prevention, system status, consistency, accessibility, and understanding what a user expects to happen next.

These things show up in a settings page, a complex enterprise table, an onboarding flow, a portfolio case study, and the way you present an argument to a stakeholder.

Fundamentals are not a layer of polish you apply at the end.

They shape whether the work makes sense.

Experienced designers often look at a screen and know immediately that something is off.

The type feels wrong. The spacing has no rhythm. The hierarchy collapses. The information is technically present but impossible to parse. The interaction uses a pattern in a way that creates doubt. Nothing is dramatically broken, yet the whole thing feels one level below professional.

This kind of judgment can look like instinct or gut feeling.

That can make it sound like something you are either born with or not.

I do not believe that.

What looks like instinct is usually compressed experience. You have seen the principle in theory. You have noticed it in strong work. You have tried to apply it. You have received feedback when you got it wrong. You have repeated that process enough times that the gap becomes visible before you can fully explain it.

The gut feeling comes from learning and looking.

Theory alone is not enough. You can memorise every typography term and still make weak layouts. Inspiration alone is not enough either. You can save 10,000 beautiful screens without understanding why any of them work.

You need both.

Learn the principle, then find it in applied design. Take the design apart. Rebuild it. Change one variable and notice what breaks. Explain why the designer may have made that decision. Then use the same principle in work of your own and ask somebody to critique it.

That is how a rule slowly becomes judgment.

I keep hearing a similar description of current AI output: with strong models and tools, you can get roughly 80% of the way there very quickly.

Do not get too attached to the number. Some outputs are nowhere near 80%. Others may be almost usable immediately. It is a metaphor for something real: the first large chunk of execution is becoming dramatically faster, while the remaining part still needs careful human attention.

That last 20% is rarely just moving a button two pixels.

It is noticing that the hierarchy is wrong even though the UI looks polished. It is recognising that the generated flow uses a familiar pattern in an unfamiliar way. It is deciding that the copy is technically clear but does not fit the moment. It is catching an accessibility issue, an impossible edge case, an inconsistency with the wider product, or a solution that answers the prompt but not the actual problem.

AI can also help with those things. You can ask it to audit, compare, test, and refine.

But somebody still has to judge its suggestions.

If you do not know what good typography looks like, you cannot reliably choose between four generated directions. If you do not understand platform conventions, you may accept an interaction that looks modern but behaves strangely. If you do not understand the user or business context, you may optimise the wrong part of the experience with impressive efficiency.

The value is moving away from producing the first plausible answer.

It is moving toward knowing which answer deserves to survive.

This matters directly in your portfolio.

Hiring managers often cannot tell exactly which parts of a project were generated, heavily assisted, based on a template, or made manually. And increasingly, that is not the most useful question anyway.

They can still tell when the work is off.

The case study has no hierarchy. The mockups look polished, but the actual product flow is thin. The visual system changes from screen to screen. The dashboard ignores how people scan dense information. The mobile interactions feel like a website squeezed into a phone. The writing explains every design-process step but never makes the important decision clear.

These are not only execution problems. They are judgment problems.

A hiring manager with years of experience may register them in seconds. They may not sit down and write a detailed explanation of every issue. They simply feel less confident that the person behind the work can recognise and raise the quality bar.

That is one reason portfolios with “almost good” work can struggle.

The tools helped the designer get close enough to look convincing at first glance, but the underlying decisions do not hold up. The last part was never finished because the designer could not yet see what was missing.

This is not an argument against using AI in portfolio projects.

Use it. Build more. Prototype things you could not have built before. Explore directions faster. Turn static ideas into working products. That is an advantage.

Just do not confuse faster execution with stronger judgment.

If you want a practical plan, I would keep it simple.

Look for someone a few steps ahead of you whose work and career are relevant to where you are trying to go.

You do not need to ask a stranger to “be your mentor” forever. Start smaller. Ask for a portfolio review, book a mentoring session, join a community, speak to a senior designer at work, or build a relationship through thoughtful, occasional questions.

Bring something concrete. Show the work. Explain the decision you are struggling with. Ask what they would focus on next.

The goal is not unlimited access to somebody successful. It is regular calibration from a person who understands the standard you are aiming for.

Books, courses, videos, workshops, articles, exercises, formal education—it does not matter nearly as much as people make it seem.

Pick a route you can stick with. Learn typography, layout, hierarchy, colour, interaction, information architecture, usability, accessibility, and the conventions of the products you want to design.

Then repeat.

You will not “complete” the fundamentals once. You will revisit the same principles with better eyes every time.

Use Mobbin, Page Flows, real products, design systems, apps you respect, and the strongest relevant portfolios you can find.

Do not only collect screenshots. Take them apart.

Why is the primary action placed there? How is the page divided? What creates the hierarchy? Which spacing repeats? How does the design handle a long label, an error, an empty state, a loading state, or a user without permission? Which parts are standard because they should be standard?

And do not study only flashy landing pages.

If you want to design enterprise software, study tables, filters, permissions, settings, bulk actions, and dense workflows. If you want to become a design engineer, study interaction details, responsive behaviour, component logic, and what happens between states. If you want to work on consumer mobile products, study onboarding, navigation, platform conventions, retention loops, and the boring account-management screens too.

Your references should match the designer you want to become.

Take one piece of work that already feels “mostly done” and stay with it.

Ask a mentor or peer to critique it. Compare it against strong references. Check the type, hierarchy, spacing, states, accessibility, behaviour, copy, and consistency. Use AI to help audit it, but do not accept every recommendation automatically.

Make yourself explain what changed and why.

That is where the learning is.

Starting another generated concept may feel more exciting. Finishing the almost-good thing will train your judgment much faster.

Juniors are being told to learn an exhausting number of things right now.

Design. Research. Product thinking. Code. AI. Prototyping. Business. Communication. Personal branding. Content. Whatever new tool launched this week.

You cannot master all of it at once.

So start with the things that make everything else easier to judge.

Find experienced humans who can help you see your blind spots and steer toward the work you actually want to do. Learn the fundamentals until you can recognise them in strong products and feel when they are missing from your own. Use AI to move faster, explore further, and build more ambitious things—but keep responsibility for the final judgment.

Execution will continue to change.

Knowing what good looks like, and having people who help you reach it, will remain useful for a very long time.

📰 ADVERTISEMENT

Your inbox isn't the problem. Neither are your meetings. It's the hours you spend on work AI could do in minutes.

285 copy-paste prompts: built for email, meetings, admin, and delegation. Each one has a clear role, a specific task, and a defined output.

No setup. No prompt engineering. Just copy, paste, and get your time back. Free when you subscribe to Mindstream.

Get 285 free prompts

Itzie Pulido is a Dallas-based product designer who studied at UT Austin.

Her portfolio is full of personality. Illustrations, animations, pink accents, and a small cat give the site a playful surface. Spend a little more time with it, though, and a much sharper picture begins to emerge.

Itzie has worked on serious product problems, helped shape ideas from the ground up, collaborated with stakeholders and engineers, and built foundations intended to scale.

Balancing that work with such a distinctive personality is difficult. Itzie makes the combination feel natural.

Let’s take a closer look at what works and where the portfolio could become even stronger.

That’s it for this week—thanks so much for the support! ♥️

Do you want your own portfolio reviewed in-depth with a 30-minute advice-packed video portfolio review? Look no more. I do offer these as an async service you can book directly with me here.

Keep kicking doors open and see you next week!
- Florian