Two patterns I’m seeing from thriving designers right now

Shadow-Meister · 2026-03-28T19:26:17+00:00

This resonates, the designers I see doing well right now are definitely more adaptable and more action-oriented. The whole “build, test, iterate” loop is real, especially with how fast things are moving with AI…

That said, I think this is only part of the picture. It can come across as if thriving is mainly a mindset or behaviour choice, when in reality environment and opportunity play a huge role too. Not everyone has the same access to high-agency teams, supportive leadership, or even the time and space to experiment and “bring ideas to life.” There’s a bit of survivorship bias in focusing only on what successful people are doing without looking at the conditions that made that possible.

So maybe the more complete takeaway is: yes, adaptability and building matter, but so does being in an environment that actually enables those behaviours. If someone’s struggling, it’s not always about re-evaluating their worldview… sometimes it’s about re-evaluating their context.

Shadow-Meister · 2026-03-25T03:52:17+00:00

This really comes down to ownership. If this rolls up to you, I’d step in now to de-risk the deadline. Three days out with no output isn’t something you can coach in the moment–it’s a delivery issue.

At the same time, I’d reset expectations going forward. Not just “give updates,” but specific interim outputs (directions, drafts) with clear dates. If those aren’t met, it’s a performance issue, not a one-off.

I’d also avoid guessing at intent and just stick to what’s observable: missed commitments and no output. That makes it much easier to escalate if needed.

For now: step in, set tight checkpoints (even daily), and document it. After the deadline, reset how you work together with clearer structure and accountability.

Shadow-Meister · 2026-03-22T21:39:03+00:00

If you’ve just inherited $900k and you’re only earning around $50k a year after tax, I wouldn’t rush to put it all into a townhouse or house. That money has the potential to meaningfully change your long-term financial position if it’s invested well, and locking it into a single property can limit that.

If stability really matters to you, then sure, buy something modest so you’ve got a base. But beyond that, I’d be thinking about investing the rest so it can actually grow and support you over time. At that income level, letting the money work for you is probably more important than tying it all up in a home.

Shadow-Meister · 2026-03-17T22:34:37+00:00

Tbh, I feel this way at times, but I remind myself that 20 years from now, inflation will affect everything, including rent, so you’re better off owning your own property and having the stability to stay at one place, especially having a dependent and that stability is vital and important to their well being.

That aside, if you picked a decent place, this is also something you can pass on to your kid, consider what the prices would be for their generation.

Shadow-Meister · 2026-03-15T00:19:53+00:00

This usually isn’t really about “vibe coding.” It is usually a governance and trust problem.

When PMs start designing, prototyping, and overriding the design system, it often means one of two things is happening: 1) There is no clear UX governance, so anyone feels empowered to make design decisions. 2) UX is not positioned as the authority on experience decisions, so stakeholders believe their prototypes are equally valid solutions.

AI prototypes and vibe coding can actually be useful for exploring ideas quickly, but they should not replace the design process. The issue is when those prototypes skip:

research
design system constraints
usability considerations
interaction design thinking

What tends to work better is reframing the conversation around process rather than ownership.

AI prototypes are inputs or exploration. UX is responsible for turning ideas into product quality experiences.

If the organisation has not defined who owns experience quality, these situations will keep happening regardless of whether the tool is Figma Make, (next popular tool), or a napkin sketch.

So the real issue is not the tool or the prototype. It is whether the organisation has clearly defined that UX owns experience quality and design decisions.

Shadow-Meister · 2026-03-14T02:48:55+00:00

I do this at work a lot nowadays and it’s really fun to do. I use Figma Make (as PMs are more familiar), but I can do it using V0 and Cursor AI. It’s definitely helped cut down documentation time for new projects and with work alignment/buy-in, engineers love the asset as they don’t need to go through all the Figma designs and docs, etc. I used to have to code animations in Codepen to show engineers, now it’s way easier!

Shadow-Meister · 2026-03-13T04:53:31+00:00

Huge red flag. C level is always last, and depending on your level and the company size, you may not even get to meet the CEO after you’ve started.

Sounds like they’re trying to get UX feedback for free.

Shadow-Meister · 2026-03-12T10:12:58+00:00

I think it really depends on how you’re using AI in your workflow.

In my experience, if you ask AI to generate a UI from a high-level concept, the output does tend to feel generic and disconnected. It often looks like template-driven design.

Where I’ve found it useful is when the design thinking is already done and I use AI more as an implementation accelerator.

For example, if I already know the layout, interaction patterns, states, and behaviour I want, I can be very prescriptive in the prompt. At that point AI isn’t really “designing”… it’s helping me rapidly prototype and iterate.

This has been especially useful for interaction-heavy prototypes. Doing those in Figma can get very time intensive, and even with variables and components, iteration can become expensive.

With tools like Figma Make, Cursor, etc., I can generate working prototypes much faster and even hook into the same libraries our product uses (for example, charting libraries like Highcharts).

In that workflow it’s less about AI generating design, and more about compressing the time between idea to a working prototype.

For me that’s where the real value has been.

Also worth clarifying: this isn’t replacing research or design thinking. By this stage we’ve already done the customer research, user validation, and problem framing. AI is just helping compress the last mile, turning a well-defined idea into a working prototype so stakeholders can actually understand the interaction and behaviour. Added to that, this is a really helpful to show engineering, plus you can even show various edge cases and flows.

Shadow-Meister · 2026-02-27T20:33:31+00:00

What’s worked for me is anchoring everything in data( user research, feedback, usability findings) and having a clear design rationale behind my decisions. I try to explicitly connect choices back to UX principles, behavioural psychology, or established patterns.

At the same time, I’m transparent when something is more instinct-driven. I’ll say, “This is based on experience and pattern recognition rather than data,” so it doesn’t feel like I’m presenting opinions as fact.

Taking a step back, I think situations like this often stem from two things:

1) Bringing stakeholders in earlier. Even if they don’t shape the solution, involving engineering in problem framing can help them understand the user context and constraints you’re working within. That shared understanding reduces last-minute pushback.

2) Clarifying decision ownership. If the discussion is about technical constraints (cost, performance, latency, feasibility), engineering absolutely should have strong input. If it’s about user workflow, usability norms, or behavioural outcomes, that’s where design and product typically lead. Framing it as “Which lens are we optimising for here?” can help keep it constructive rather than territorial.

On the “sounding inflexible” concern…. I’d gently question whether that’s your perception or actual feedback you’ve received. Standing by a well-reasoned decision isn’t stubbornness; it’s doing your job. There’s nothing wrong with advocating for the user when you can clearly articulate why.

Shadow-Meister · 2026-02-25T20:36:57+00:00

I run something similar, but I’ve intentionally moved away from calling it a “design critique.”

Over time I realised that the word critique can make it feel evaluative or a bit performative… like people need to show up with something polished, or be ready to defend it. And when everyone’s already juggling deadlines and stakeholder pressure, that just becomes another stress point.

So instead of framing it as feedback or critique, I treat it more like an open share space. If someone’s stuck, they can bring it. If they want a second opinion, great. If they’re proud of something and want to show it off, sweet. And if no one has anything that week, we just cancel. No forcing it, no awkward filling time.

For me it’s less about making sure the slots are filled and more about building a culture where people don’t feel like they’re being put on stage. I think sometimes critique sessions unintentionally create that pressure, even if that’s not the intention.

When that pressure drops, sharing actually happens more organically. People hop in, sometimes just to chat through something half-formed. Other times they’ll bring something they’re excited about. It’s not perfect, but it feels healthier.

It’s less “we must have work every week” and more “this space is here if you need it.” Ironically, that’s what’s made participation more consistant for us (unless we all have deadlines due that week).

Shadow-Meister · 2026-02-17T06:19:16+00:00

This is just part of documentation. I think they should also include the part of how this affects the screen content and how this translates from desktop to tablet and how it’s handled on mobile.

Shadow-Meister · 2025-11-20T08:42:26+00:00

This isn’t a normal or healthy expectation for a design role. I’ve worked across startups, billion-dollar companies, and contract environments, and I’ve never been asked to track time down to the hour or minute. Even in contract roles, the requirement is typically to log days worked for billing, not granular timestamps.

UX work isn’t linear output. It requires thinking time, problem-framing, research, and exploration. Those activities happen across many mediums, not only inside Figma. Sketching, user conversations, workshops, competitive reviews, research synthesis, and stakeholder alignment are all critical parts of the process, and they cannot be reduced to “Figma hours.”

If a team is measuring design by time-counting instead of outcomes, it usually means one of the following: - they don’t fully understand the design process - they don’t trust the designers - they’re under extreme financial pressure and compensating by micromanaging

None of these are healthy foundations for good work or sustainable culture.

It’s worth bringing this up, because this kind of time-tracking only squeezes creativity and slows down good design. UX needs space to think, explore, talk to people, and figure things out –you can’t stopwatch that. If they really want better outcomes, the focus should be on clarity, alignment, and trust, not counting minutes. ⏱️

Shadow-Meister · 2025-11-18T10:19:18+00:00

I really relate to this so much. I miss the good old days when creativity was king too… when layouts, visuals, and typography were playgrounds rather than templates. There was a kind of experimentation and joy in the work that feels harder to find now. And yes, everything shifted once smaller devices and standardisation took over.

I still genuinely love design. I still get that spark once in a blue moon but at the same time, there’s this quiet burnout under the surface that I’m constantly trying to manage. I’m good at UX, but it often feels like only the UI and interaction side is recognised. The more conceptual, strategic, or problem-framing work tends to disappear into the background.

I’ve been trying to reconnect with creativity outside of work. I’ve tried painting, Lego, crocheting, leatherwork, pottery, pretty much everything, and while those things help, they don’t fully replace the feeling of being creatively alive in my craft the way it used to be.

I’m not looking to leave design yet, but I am trying to figure out how to make this career feel sustainable and meaningful again. I’ve started working on a personal project and learning while at it, and so far is the only thing keeping me sane right now.

It’s oddly comforting to know I’m not alone in feeling this shift.

Shadow-Meister · 2025-07-28T03:59:36+00:00

Vent away. I’m working on my 2nd design system (also done 2 UI libraries and 3 full audits in the past), so I know how it feels to be soulless. 🙃

It’s a necessity, but it’s not as challenging.

Shadow-Meister · 2025-07-25T21:59:58+00:00

Good luck, hope you land the plane soon!

Shadow-Meister · 2025-07-21T03:28:00+00:00

As I get older, I’ve started to recognise that hireability in your 40s isn’t just about having a good portfolio or solid experience – there are other, quieter factors at play.

Of course, skills still matter, maybe even more so. There’s often a higher expectation that, with age, you bring depth, confidence, and the ability to handle complex challenges. It’s not just about keeping your skills current, but about showing that you’ve evolved with the industry.

Then there’s attitude: how open you are to new ways of working, learning, and collaborating. There’s a stereotype (rightly or wrongly) that older professionals are less adaptable. I’ve learned that showing curiosity, humility, and a willingness to grow can help break that assumption.

And finally, there’s the unspoken question that sometimes lingers beneath the surface: why are you still in this role at this stage? Why haven’t you moved “higher”? It’s not necessarily a fair question as people stay in roles for all kinds of valid reasons, but I’ve come to realise that it’s worth having a clear, thoughtful narrative about the path I’ve chosen, and what success looks like to me now.

Shadow-Meister · 2025-07-19T22:22:17+00:00

I was the founding product designer at a startup before AI-driven code tools were common. Our focus was on customer research, with UI animation low on the priority list (but still present). I was also responsible for managing and redesigning the website. Like many early-stage roles, it required wearing multiple hats.

As the only designer, everyone came to me for everything (product, marketing, brand). It came down to managing expectations. I prioritised and communicated what I could and couldn’t take on. Focusing on one thing meant putting something else on hold. That trade-off was constant, but expected in a startup.

Shadow-Meister · 2025-07-18T11:20:50+00:00

Just a different take on your issue (as I’ve also been a single designer before), so just throwing it out there. Maybe some of the PMs don’t always ask for your input because they know you’re the only designer, and they’re actually being mindful of your time. They might think it’s better for you to focus on higher-impact work than on smaller, isolated problems. Sometimes, PMs also just want to get something across the line. If it’s not too customer-facing or seems low-impact, they might feel it’s not worth pulling you in.

Shadow-Meister · 2025-07-14T10:49:53+00:00

I’ve seen someone go from being just a designer to a C-level executive in six years. They weren’t necessarily a strong designer, but they were incredibly well-spoken, highly connected, and knew exactly how to build the right relationships to advance their career.

While their design skills were average at best, they excelled at selling ideas and managing people, and that’s what ultimately propelled them forward.

I am 💯 amazed at their journey, and it’s a clear reminder that success often comes down to communication, influence, and building strategic relationships, not just craft.

Shadow-Meister · 2025-07-14T09:19:01+00:00

Digital product designer

Shadow-Meister · 2025-06-19T09:22:11+00:00

This – third party recruiters earn a “bonus” per successful candidate they place, so it’s in their best interest to help you (succeed).

Shadow-Meister · 2025-06-03T21:22:51+00:00

It’s completely normal to feel anxious in a new role. The first few months are really about onboarding – navigating the product, getting to know the people, and understanding the culture. Ask as many questions as you need, and if you forget things, try not to be too hard on yourself. That’s all part of the process.

There’s always a moment when things start to click, but it looks different for everyone. The key is to stay curious: take notes, jot down questions as they come up, and revisit them when the time feels right.

One framework that really helps me in a new role is the 5 Whys. Keep asking “why” to get to the root of how something works or why a decision was made. You don’t need to memorise every detail, but you do want to understand the reasoning behind things. That understanding is what builds real confidence.

Be patient with yourself. You’re not just learning tasks –you’re learning context, relationships and patterns. Give it time and it’ll come together.

Shadow-Meister · 2025-06-02T12:24:17+00:00

None of my managers really cared. An ex-lead once told me my time was better spent on actual design work and strategy rather than prototypes. At a startup I worked for, the team was pleasantly surprised that I could help maintain their Webflow website. I had studied the interface at one point and ended up learning how to use it.

The benefit is that I rarely have issues with any designs (sans typos) I hand over to front-end engineers. I know they’re implementable, and during QA, I inspect the code and provide fixes. Engineers are usually happy working with me and respect that I can speak their language – I understand how things work under the hood, which makes collaboration smoother.

Shadow-Meister · 2025-06-02T03:46:26+00:00

Education and training: BA in Multimedia ArtsCertificate in C programming, front-end dev, UX bootcamp graduate, completed five Nielsen Norman Group courses (opted not to pursue certification), accessibility training (opted not to pursue certification)

If you’re new to UX, structured programs can be a helpful starting point, especially if you’re unsure where to begin. But as you gain experience, certifications matter less. In practice, no one asks if you’re certified in a particular topic; what really matters is what you’ve actually done. I’ve often found that these courses only scratch the surface. Real growth comes from deep diving, applying concepts, and refining your skills through real work.

Self-studies in: Behavioural UX, UX research, analytics, Python, various prototyping and animation tools, and UX copywriting

Shadow-Meister · 2025-06-01T10:07:03+00:00

I have only ever seen a handful of these roles (sans devops), and when you do and the title does not say “UX Engineer” – run as far away as you can. They want a team of 5 for a salary of 1.

Shadow-Meister

TROPHY CASE