I Started My UI/UX Career 1.5 Years Ago — Here’s What I Wish I Knew Before Starting

When I first started learning UI/UX design, I thought the path was pretty simple.

Learn Figma.

Watch some tutorials.

Create beautiful screens.

Build a portfolio.

Apply for jobs.

Done.

At least, that's what I thought.

After around 1.5 years of actually working and learning as a UI/UX designer, I realize how wrong that assumption was.

The biggest things I learned weren't about which button to use in Figma or how to create a beautiful gradient.

They were about why I was designing something in the first place.

I had to learn how to understand users, question my own assumptions, accept feedback, work with developers, understand design fundamentals, and most importantly, stop designing just because something "looked good."

So if you're starting your UI/UX journey in 2026, this isn't another roadmap telling you to learn ten different tools.

This is what I genuinely wish someone had told me when I was starting.

When I Started, I Thought UI/UX Was Mostly About Making Things Look Good

I'll be honest.

In the beginning, I was more interested in the UI part.

I enjoyed creating screens.

Choosing colors.

Trying different fonts.

Playing around with cards, buttons, shadows, spacing, and layouts.

Whenever I created something that looked visually good, I felt like I had done a good job.

But after working on real projects, I slowly realized something.

A design can look beautiful and still be a terrible experience.

That's probably one of the first important lessons I learned.

Good UI doesn't automatically mean good UX.

A user doesn't care how beautiful my button looks if they can't figure out what to do with it.

That changed the way I started looking at design.

My First Big Mistake: I Didn't Understand Design Fundamentals

One thing I wish I had learned much earlier was design fundamentals.

Initially, I knew things like colors, typography, spacing, and alignment existed.

But I didn't really understand why they mattered.

I was choosing colors because I liked them.

I was increasing font sizes because the heading "felt too small."

I was adding spacing until the design "looked balanced."

I was designing based on my eyes rather than understanding the principles behind the design.

Later, I started understanding concepts like:

• Visual hierarchy
• Typography
• Contrast
• Alignment
• Spacing
• Grids
• Proximity
• Balance
• Consistency

And suddenly, many design decisions started making more sense.

I realized that good visual design isn't about randomly making things look better.

There is a reason behind almost every good design decision.

I Also Made Another Mistake: Designing Before Understanding the Problem

This was probably one of my biggest mistakes.

I would get a requirement and immediately start thinking:

"Okay, what should the screen look like?"

I'd open Figma.

Create a frame.

Start placing components.

Try different layouts.

And slowly build the UI.

But I wasn't asking the most important question:

"What problem am I actually solving?"

That question changed my entire approach to design.

Today, before I start designing, I try to understand the problem first.

Who is using this?

What are they trying to accomplish?

Where are they getting stuck?

What information do they need?

What is frustrating them?

What does the business actually want to achieve?

These questions may sound basic now.

But when I was starting, I didn't think this way.

User Research Was Something I Didn't Really Understand

When I first heard the term user research, I honestly wasn't sure what it meant in practice.

I understood the theory.

"Talk to users."

"Understand their problems."

"Find pain points."

Sounds simple, right?

But then I had the obvious question:

What exactly do I ask them?

And even if they tell me something, how do I know whether it's actually a problem?

That was something I had to learn through experience.

I eventually understood that user research isn't about asking users:

"Do you like my design?"

That's not really the point.

The goal is to understand what users are actually trying to do, what they struggle with, and what they currently do to solve their problems.

How I Now Think About User Pain Points

One thing that helped me was changing the type of questions I ask.

Instead of asking:

"Would you use this feature?"

I'd rather understand:

"How do you currently do this?"

Instead of:

"Do you find this difficult?"

I'd ask:

"Can you walk me through the last time you had to do this?"

That difference is important.

People can tell you what they think they would do.

But their actual experiences often tell you much more.

I started paying attention to:

• What they struggle to find
• Where they hesitate
• What they repeat
• What they avoid
• What they complain about
• What takes too much time
• What they currently do manually
• Where they make mistakes
• What they expect to happen

Those observations can reveal much more useful insights than simply asking whether someone likes a particular design.

I Learned That Assumptions Can Be Dangerous

This was another lesson that took me some time to understand.

As a designer, it's very easy to think:

"If I were the user, I'd do it this way."

But I'm not the user.

My experience, expectations, technical knowledge, and habits can be completely different from someone else's.

That's why I slowly started becoming more careful about making assumptions.

If I think users are struggling with something, I want some evidence.

If I think a particular feature is necessary, I want to understand why.

If I think a particular flow is better, I want to know what makes it better.

That mindset has helped me become much more objective about my designs.

I Started Looking at Designs Differently

Something interesting happened after I started understanding UX better.

I stopped looking at websites and apps only from a visual perspective.

Earlier, I'd see a website and think:

"Nice colors."

Now I find myself thinking:

"Why is this CTA here?"

"Why did they put this information above the fold?"

"Why does this flow have four steps?"

"What happens if the user makes a mistake here?"

"What happens if the user doesn't have this information?"

"Why is this option more prominent than the others?"

I started seeing interfaces as systems of decisions, not just collections of screens.

That was a big shift for me.

Feedback Was Another Thing I Had to Learn

One of the hardest things when you're starting out is receiving feedback on something you've spent hours designing.

You look at your design and think:

"This is good."

Then someone points out three things that don't work.

And initially, it can feel frustrating.

I definitely had to learn not to take design feedback personally.

A design is not an extension of my ego.

If something isn't working, changing it doesn't mean my previous work was worthless.

It means the design can become better.

I started treating feedback as part of the design process rather than as criticism.

That made collaboration much easier.

Working With Developers Changed My Design Thinking

Another major learning came from working with developers.

When I was just practicing UI/UX, I could design almost anything I wanted.

There were no technical constraints.

No API limitations.

No weird edge cases.

No questions about how something would actually behave.

Real projects are different.

A developer might ask:

"What happens when this text becomes longer?"

Or:

"What happens on smaller screens?"

Or:

"What happens if the API doesn't return any data?"

Or:

"What happens when the user submits this form incorrectly?"

These questions made me realize that designing the perfect happy path isn't enough.

A real product needs to account for real situations.

Empty States, Errors and Edge Cases Matter More Than I Thought

When you're a beginner, you naturally design the ideal scenario.

The user has all the information.

The internet works.

The API returns data.

The form is filled correctly.

Nothing goes wrong.

Real life doesn't work that way.

Users forget passwords.

They enter incorrect information.

Data doesn't load.

Pages don't have content.

Networks fail.

Names become longer than expected.

Images don't load.

And users don't always behave the way we expect.

Learning to design these situations was one of the things that made my work feel more mature.

I Stopped Trying to Make Every Screen "Fancy"

Another thing I changed over time was my relationship with visual trends.

When I was starting, I was attracted to fancy interfaces.

Gradients.

Glassmorphism.

Huge typography.

Animations.

Interesting cards.

Creative layouts.

And there is nothing wrong with those things.

But they shouldn't be the starting point.

Now I ask:

Does this visual decision help the user?

If yes, great.

If it only exists because it looks cool, maybe it isn't necessary.

I've learned that sometimes the best design decision is the simplest one.

I Started Understanding That Consistency Is a Superpower

As I worked on more interfaces, I started appreciating consistency much more.

The same button shouldn't behave differently across different parts of a product.

Spacing shouldn't randomly change.

Typography shouldn't feel different from page to page.

Components shouldn't constantly be reinvented.

This is where I started becoming more interested in design systems.

Reusable components, typography scales, spacing systems, colors, states, and interaction patterns don't just make a design look consistent.

They make the product easier to scale.

And they make collaboration with developers much easier.

My Relationship With Figma Changed Too

I still use Figma a lot.

But my relationship with it is different now.

Earlier:

Figma → Design

Now:

Problem → Research → Structure → Flow → Wireframe → Design → Prototype → Feedback → Iteration

Figma is still an important tool.

But it's no longer the first step.

That's probably one of the biggest differences between how I used to approach design and how I approach it now.

I Also Realized That a Portfolio Isn't Just a Gallery

This is something I wish I knew earlier.

When you're starting, it's tempting to make your portfolio look like a collection of beautiful screenshots.

But if I were reviewing a junior designer's portfolio today, I'd want to understand:

How do they think?

Not just:

How good are their screens?

A good case study should help me understand:

• What was the problem?
• Who was the user?
• What did you discover?
• What assumptions did you have?
• What decisions did you make?
• Why did you make them?
• What changed after feedback?
• What did you learn?

The final UI is important.

But the thinking behind the UI is what makes a case study interesting.

The Biggest Change Was in How I Define "Good Design"

Earlier, I thought:

Good design = Looks good.

Then I thought:

Good design = Looks good + Easy to use.

Now I'd describe it more like this:

Good design = Solves the right problem for the right user in a clear, usable, and practical way.

The visual layer still matters.

A lot.

But it is only one part of the experience.

If I Had to Start My UI/UX Journey Again in 2026

If I could go back to the beginning and start again, I wouldn't spend my first few months only watching Figma tutorials.

I'd do things differently.

I'd spend more time learning:

Design fundamentals

before trying to create impressive screens.

I'd learn:

UX thinking

before obsessing over visual polish.

I'd practice:

User research

before deciding what users need.

I'd build:

small real-world problems

instead of endlessly recreating designs from Pinterest or Dribbble.

I'd get:

feedback much earlier.

And I'd start documenting my thinking from the beginning.

Most importantly, I'd remind myself:

I don't need to know everything before I start designing.

I just need to keep learning from every project.

What 1.5 Years Has Taught Me

After 1.5 years, I still don't consider myself someone who has "figured out" UI/UX.

And honestly, I don't think a good designer ever stops learning.

There are always new products, new patterns, new technologies, new research methods, and new ways of solving problems.

But I do feel that I understand the job very differently now.

I'm less focused on:

"How do I make this look good?"

And more focused on:

"What is the user trying to accomplish, and how can I make that easier?"

That shift might sound small.

For me, it wasn't.

It changed how I approach design.

One Thing I'd Tell Anyone Starting Today

If you're just starting your UI/UX journey, don't compare your first month of learning with someone's fifth year of experience.

You will probably create bad designs.

You will make assumptions.

You will choose the wrong typography.

Your spacing will be inconsistent.

Your first case study might not be very good.

You'll probably redesign the same screen ten times.

That's okay.

I did too.

The important thing is to understand why something isn't working and improve it.

Don't chase perfection.

Chase understanding.

What I'd Focus on in 2026

If I were starting today, I'd keep my learning focused on a few core areas:

• Design fundamentals
• UX thinking
• User research
• Information architecture
• Wireframing
• UI design
• Responsive design
• Prototyping
• Design systems
• Accessibility
• Basic HTML & CSS
• AI-assisted design workflows
• Communication and presentation

I wouldn't try to master all of them at once.

I'd learn one.

Practice it.

Build something.

Get feedback.

Improve it.

Then move to the next one.

A Note on User Research

User research was one of the areas where I personally had the biggest learning curve.

I knew that research was important, but I didn't initially know how to actually conduct it, what questions to ask, how to identify genuine pain points, or how to turn conversations into actionable design insights.

That's a topic that deserves its own detailed breakdown.

I've written a separate guide explaining how to conduct user research, what questions to ask, how to identify real user pain points, and how to turn those findings into UX decisions.

→ Read: How to Conduct User Research and Find Real User Pain Points

Final Thoughts

Looking back at my first few months in UI/UX, I can see how much my understanding has changed.

I started with the idea that UI/UX was mainly about creating beautiful interfaces.

Then I learned that it was about usability.

Then I learned that it was about understanding users.

And eventually, I started understanding that it's really about solving problems.

The tools will change.

The trends will change.

AI will change how we work.

But the fundamental question will remain:

"Are we solving the right problem for the people who actually use this product?"

If you're starting your UI/UX career in 2026, don't worry about knowing everything on day one.

Learn the fundamentals.

Stay curious.

Talk to users.

Build things.

Ask for feedback.

Make mistakes.

And most importantly, learn from those mistakes.

Because sometimes the biggest step in becoming a better designer isn't learning another tool.

It's learning to think differently about the problem you're designing for.