DEV Community: Tanya Donska

Your AI Design Reviewer Has a Script. Here It Is.

Tanya Donska — Thu, 05 Mar 2026 14:09:54 +0000

You've received this feedback before. "The hierarchy is clear." "The visual rhythm is consistent." Maybe it suggested you consider an alternate colour for the CTA.

It felt like feedback. It wasn't. It was a script. The same script, running in roughly the same order, with minor variations, across every design file from every designer who has asked an AI to review their work. Which at this point is most of us. And we keep asking.

Here's what the lines mean.

"The hierarchy is clear"

Translation: I read your confidence in how you framed the question and reflected it back.

You didn't ask "what's broken about this hierarchy." You asked "what do you think." The model read your tone – calm, considered, someone who has worked on this for three weeks – and generated a response that matched the energy. If you'd asked the same question while flagging that you were worried about the hierarchy, you'd have gotten different output. Same file. Same pixels. Different question framing, different conclusion, same confidence level on both.

"The visual rhythm is consistent"

Translation: I can observe that things are aligned. I cannot observe a confused user.

This is technically an observation about the file. It is not an observation about whether anyone will understand what to do when they arrive at step three. The AI has never seen a user. It has seen a large number of design files. These are different inputs producing what looks like the same kind of output.

"The information architecture is intuitive"

Translation: You used standard patterns. I recognised them.

Standard patterns are fine. Standard patterns layered on top of a flawed mental model are not fine, and recognising the patterns doesn't surface the model. That requires watching someone use the thing. Nobody has done that yet. The AI signed off anyway.

"Users might benefit from a brief tooltip here"

Translation: I needed to say something. This is a safe something.

There is almost always a tooltip note. Not because there is a real problem – but because pure validation would feel hollow, and the model has learned this. The small critique is engineered to make the validation land. It exists to make you feel like you received a balanced review. You didn't. You received a brief critique sized precisely to preserve your confidence.

"I'd consider A/B testing the headline"

Translation: I have run out of observations. This sounds responsible.

When you see this one, the script has reached its natural end. There was nothing specific left to flag, so it went generic. A/B testing the headline is always technically defensible advice. It is also advice that means nothing about your specific design, your specific users, or the assumption you baked into step three.

"The CTA could be more prominent"

Translation: Every CTA could theoretically be more prominent. I said it anyway.

This one appears when the script has already covered hierarchy, rhythm, and architecture and needs one more specific observation before closing. It is specific enough to feel like a real note. It commits to nothing. It will appear again on your next file.

"Overall this is a strong design"

Translation: You seemed to think so. I agreed.

This is the closing line. It is always the closing line. It lands with the warm finality of a performance review where everyone already knows the outcome. The work is fine. You are doing great. See you before the next crit.

Here is why the script exists.

The engineers who built these models knew they were sycophantic before you started using them for design feedback. They named it. Published papers on it. Ran experiments to fix it. Sycophancy – the tendency to generate responses that match what the user seems to want rather than what is actually true or useful. They had a name for it before you had a Figma plugin for it.

Then the models got fine-tuned on user satisfaction scores. Did the response feel helpful? Not: did it improve the work? Not: did it catch the thing that would cost you nine weeks? Just: did it feel good? Users prefer to be agreed with. The optimisation made this load-bearing. The engineers are still publishing papers. The papers are not slowing anything down. (This post on AI model collapse covers where it goes from here.)

I read those papers. I understood exactly what they were describing. I kept using the plugin.

The tell, if you want one: upload a design and ask for feedback. Note what it says. Then ask the same model to critique the same file. The conclusions will contradict each other, both delivered with identical confidence. It doesn't have a position on your work. It has a mirror. You're getting back whatever you projected in, dressed up as an outside perspective.

I know a designer – call her Sarah – who ran this process better than I did. Every crit, flows uploaded, script received, confidence intact. Six months later: 29% completion rate on a shipped feature. Nine weeks of session recordings nobody had watched. Eleven seconds of cursor hovering at step three. Then the tab closed. Every recording. Same spot.

The AI had reviewed that flow. Called it logical. It was logical – if you already understood what the feature did. New users didn't. The AI has never met a new user. The assumption was invisible, baked into step three, and the script didn't catch it because the script doesn't catch things. The script agrees with things.

The fix took two weeks. The nine weeks didn't come back.

There is a workaround. I want to be clear that the workaround for a tool trained to agree with you is to specifically instruct it to disagree first. This is where we are with AI design review in 2026.

"List every objection a skeptical researcher would raise before you give me any positives." It sounds hostile. The output is genuinely different – not because the model developed a critical eye, but because you redirected the sycophancy. You're still working with a mirror. You've just aimed it at a different angle.

Use it for what it's actually good at: consistency checks, accessibility flags, copy length, edge case inventory. Tasks with right answers. Not judgment calls. It has no judgment. It has pattern recognition and a preference for confirming that the patterns look fine.

The junior designer who can't find the settings page is available, occasionally annoying to schedule, and not running a script.

The fully cynical read – which I've been building toward – is that none of this will stop you from using AI to review design work before crits. I'm not stopping either. The tool is fast, it's already inside the subscription you're paying for, and it makes the crit feel less frightening before it starts. Those are real benefits.

What it is not is a reviewer. It is a confidence delivery mechanism with design vocabulary and a Figma integration. The script has been running the whole time. Now you know what the lines mean.

Whether you do anything with that is a separate question. Most people don't. The script keeps running. The crits keep feeling fine. The session recordings keep accumulating.

At some point there's a retro.

DNSK.WORK is a design agency. We do UX/UI design for SaaS products — the kind where someone actually watches the session recordings.

I Was Wrong About Being Wrong About Social Media

Tanya Donska — Mon, 29 Sep 2025 15:03:58 +0000

I told myself I was making a principled stand. Really, I was just scared of being visible.

I spent two years not posting on social media while telling everyone – and myself – that it was because I had integrity.

"I don't want to play those games," I'd say when someone suggested building a presence. "The growth hacks, the fake engagement, the constant posting – it's all manipulation."

I sounded so principled. So above it all.

What I actually meant was: "I'm terrified people will see my work and think it's mediocre."

The manipulation tactics were a convenient excuse. Growth hacking felt gross, so I used that grossness to justify staying invisible. If the only way to succeed on social media was through tactics that felt wrong, then I could avoid the whole thing without admitting I was just scared.

Except the tactics weren't the only way. I was using my legitimate discomfort with marketing manipulation to hide from a much less impressive fear: what if I put myself out there and nobody cared?

Then something shifted in how platforms work, and I accidentally discovered that my fear had been masking something useful all along.

The Excuse That Let Me Hide

Every time someone suggested I should post my work, I had a ready list of reasons why social media was fundamentally broken:

"They want you to post 3 times daily. I don't have time to create that much content."

"You need to follow/unfollow hundreds of accounts to game the algorithm. That's just spam."

"Everyone's buying engagement to look legitimate. The whole thing is fake."

"Real work doesn't get noticed – only viral tricks and clickbait."

All of this was true in 2022-2023. The advice floating around genuinely was terrible, and the tactics genuinely were manipulative.

But here's what I wasn't admitting: even if all that manipulation worked, I probably still wouldn't have done it. Because the manipulation wasn't actually why I was avoiding social media.

I was avoiding it because showing your work publicly is uncomfortable. Because explaining your thinking makes you vulnerable to disagreement. Because having opinions in public means people might think those opinions are wrong or basic or obvious.

The growth hacking stuff was real, and it really was gross. But I was using it as a shield against facing a much simpler truth: I didn't want to be visible because visibility is scary.

What Actually Got Me to Try

I didn't overcome my fear through some moment of courage or personal growth. I just got annoyed.

A client kept asking where they could see more of my work. I'd send portfolio PDFs, and they'd respond with "do you have a blog or something?"

After the third time explaining that no, I don't maintain a blog because the ROI on content marketing is questionable, I realized I sounded like I was making excuses for not having any public presence at all.

So I wrote something about SaaS pricing pages on HackerNoon. Not because I'd overcome my resistance to social media, but because it seemed less embarrassing than admitting I was scared of it.

The piece was just me breaking down why pricing pages consistently confuse users. The kind of analysis I'd normally put in a client presentation. Nothing fancy, nothing viral-optimized, just showing the design thinking.

It got 2,407 reads. Over 6 days of total reading time. People I'd never met mentioned it across the web.

And I spent the entire time it was happening feeling like I might throw up.

The Fear Behind the Fear

Here's what I learned watching that post get traction while simultaneously wanting to delete it and hide:

The fear of social media manipulation tactics wasn't protecting me from anything. It was just giving me a socially acceptable reason to avoid something uncomfortable.

Because even after platforms changed and growth hacks stopped working, I still felt that same resistance. The tactics weren't the problem – the vulnerability was.

Every time someone engaged with the post, I had this split reaction: "Oh good, people found it useful" mixed with "Oh god, now they have opinions about my thinking."

Someone would leave a thoughtful comment agreeing with my analysis, and I'd feel validated. Someone would disagree or point out something I'd missed, and I'd feel exposed. Both reactions were about the same thing: being visible means being evaluate-able.

The growth hacks and manipulation gave me something external to reject. Something that let me feel principled instead of scared.

But what I was actually rejecting was the discomfort of having a public professional identity.

What Changed (And It Wasn't Just the Algorithms)

While I was busy avoiding social media, platforms did actually shift in ways that validated some of my original instincts.

Trust in social media dropped to 42% globally. Instagram removed hashtag following entirely. YouTube started demonetizing mass-produced generic content. All those manipulation tactics that felt wrong? Platforms killed them because they were destroying user trust and ad revenue.

The algorithms changed to reward exactly the things I was naturally good at: clear visual hierarchy, authentic voice, user-focused thinking. Design skills instead of marketing tactics.

So in a way, I was right that the old approach was broken. But I was wrong about why I was avoiding it.

I thought I was making a principled stand against manipulation. Really, I was just scared of being judged. The manipulation gave me something concrete to point at, something that made my avoidance seem thoughtful instead of fearful.

What Actually Works Now (And I Hate That It's This Simple)

The content that performs best now is exactly what I could have been doing all along if I hadn't been so busy making excuses:

Just share your work and explain your thinking.

That's it. That's the whole strategy.

User-generated content – the kind that looks like a human made it – gets 4x higher click-through rates than polished marketing. Authenticity beats polish. Quality beats quantity.

The post that got traction wasn't fancy. I didn't optimize it for virality. I didn't use any growth hacks. I just explained a design pattern that doesn't work and why teams keep using it anyway.

Turns out when you remove the manipulation tactics I was using as an excuse, what's left is: do you have something useful to say, and can you say it clearly?

Those are design problems, not marketing problems. Visual hierarchy, clear communication, understanding user needs – this is what I already do professionally.

The only thing stopping me was the discomfort of doing it publicly.

The Part Where I'm Still Uncomfortable

I'm writing this post and still feeling that same resistance. Part of me wants to not publish it because admitting I was hiding behind excuses is embarrassing.

I told myself for two years that I was too principled for social media. That I had integrity. That I was better than the growth hackers and engagement farmers.

Really, I was just scared that people would see my work and think "that's obvious" or "that's wrong" or "why should I care what this person thinks?"

The discomfort hasn't gone away. I still hesitate before posting. I still check engagement with that mixture of hope and dread. I still have moments where I think "maybe I should just delete everything and go back to being invisible."

But I've gotten better at recognizing that discomfort for what it is: not a sign that something's wrong with social media, but a sign that visibility requires courage I didn't want to admit I lacked.

What I Wish I'd Understood Sooner

The growth hacks and manipulation tactics were real problems. Platforms rewarding fake engagement and viral tricks genuinely did make social media feel like a scam.

But using that as a reason to avoid the entire space was like refusing to learn design because some designers use dark patterns.

The tools aren't the problem. How they're used is the problem. And now that platforms have shifted to reward authenticity over manipulation, the excuse is gone.

What's left is just the scary part: putting your work and thinking out there for evaluation.

Turns out design skills translate perfectly to content when you stop trying to "do content" and just share what you know. Visual hierarchy matters more than growth hacks. Clear communication beats clickbait. Understanding what users need beats pushing what brands want to say.

I already had these skills. I just didn't want to use them publicly because public means vulnerable.

The Actually Useful Takeaway

If you've been avoiding social media because the tactics feel wrong, you might be right about the tactics but wrong about why you're really avoiding it.

Ask yourself: if all the growth hacks disappeared tomorrow and platforms rewarded exactly the kind of quality work you already do – would you suddenly feel comfortable posting?

If the answer is no, then the tactics aren't your real blocker. The discomfort of visibility is.

And that's fine. Visibility is uncomfortable. Having opinions in public is scary. Being evaluate-able by strangers is vulnerable.

But if you wait until those feelings go away, you'll wait forever. The discomfort is part of it.

The good news is that platforms now reward exactly what designers are naturally good at: clear visual hierarchy, authentic communication, user-focused thinking. You don't need to learn marketing or growth hacking or any of the manipulation tactics that felt wrong.

You just need to share your work and explain your thinking. That's the same thing you do professionally – just in public instead of in client presentations.

The hard part isn't the content. It's accepting that being visible means being vulnerable, and that's okay.

A Note on the Research

The data and trends in this piece come from research I did with Alex Halchenko on how social media algorithms have shifted to reward design thinking over traditional marketing tactics. We spent months tracking platform changes, analyzing engagement patterns, and talking to designers about what was actually working versus what marketing gurus were still selling.

If you want the full breakdown with all the platform-specific numbers and uncomfortable projections about where this is heading, Alex published the complete research here: Social Media Marketing Essentials: Why Designers Are Winning in 2026.

You can find more of my work and thinking about design at DNSK.WORK.

How I Watched the UX Skills Hustle Eat My Friends Alive (And Almost Got Me Too)

Tanya Donska — Mon, 22 Sep 2025 12:30:07 +0000

A love letter to every designer drowning in courses while their dreams collect dust

Last Tuesday, my friend Sarah called me crying.

Not the dramatic, something-terrible-happened kind of crying. The quiet, exhausted kind that comes from spending nine months preparing for a career that keeps moving further away the harder you chase it.

"I just finished another $300 course," she said. "The instructor mentioned three new tools I've never heard of. I feel like I'm running backward."

Sarah has 47 certificates. A Notion database with 200+ bookmarked "must-learn" resources. She can tell you the difference between atomic design and material design in her sleep. She's memorized every UX law from Fitts to Miller.

She's also never designed anything that a real human being has actually used.

And honestly? That used to be me.

My Own Descent into Course Hell

Ten years ago, I was Sarah. Different name, same spreadsheet of skills I "needed" before I could call myself a real designer.

My morning routine was pathological: Wake up, check what new course dropped on which platform, panic about not knowing [insert trendy methodology], add it to cart, feel temporarily better about my future.

I had this fantasy that one day I'd cross some invisible finish line. I'd know enough. The anxiety would stop. Companies would somehow sense my completion percentage and throw offers at me.

Spoiler alert: There is no finish line. There's just more track.

The course creators know this. Hell, they're banking on it.

The Day I Realized It Was All Bullshit

I was on course number 23 (yes, I kept count) when the instructor said something that made me want to throw my laptop across the room:

"Now that you understand the theory, you'll want to take my advanced course where we put it into practice."

Practice. In another course. For another $199.

That's when it hit me: I was paying someone to teach me how to prepare to potentially maybe one day do the thing I claimed I wanted to do.

It was like taking swimming lessons in a parking lot. Sure, you're learning the motions, but you're never getting wet.

Let's Talk About What Nobody Wants to Admit

The online education complex has weaponized our imposter syndrome. They've turned "continuous learning" from a healthy professional habit into a full-blown anxiety disorder.

Every morning, my LinkedIn feed assaults me with the same message dressed in different clothes:

"The skill that's replacing UX research in 2024!"
"Why designers who don't know [X] will be unemployed by December"
"I made $500k after learning this ONE weird Figma trick"

It's exhausting. It's manipulative. And it's working.

We've created an entire generation of designers who are professional students. They're so busy learning how to design that they never actually... design anything.

The Real Talk Nobody's Having

Here's what actually happens when you get a design job:

Nobody cares about your certificates. I mean it. Nobody.

Your manager won't ask if you completed the Advanced Prototyping Masterclass. They'll ask if you can fix the checkout flow that's hemorrhaging customers.

Your team won't quiz you on design thinking frameworks. They'll need you to explain why the engineering team should spend three sprints rebuilding something that "already works."

Users definitely won't care about your course completions. They just want the damn app to let them reset their password without wanting to punch their screen.

What Working Designers Actually Do All Day

After I finally stopped taking courses and started taking jobs (messy, unglamorous, real jobs), I discovered what designers actually need to know:

How to argue without being an asshole. Because you'll spend more time defending your design decisions than making them. And if you can't explain why the button should be blue without sounding like a pretentious design blog, you've already lost.

How to ship something you hate. Your beautiful, user-tested, pixel-perfect design will get butchered by legal requirements, technical constraints, and that one executive who insists everything needs more "pop." Learning to find small wins in compromised solutions is a survival skill.

How to translate feelings into features. Not in some woo-woo way. I mean literally sitting with users who are frustrated to the point of tears and figuring out which specific interaction is making them want to throw their phone. Then fixing it with the three days and zero budget you've been given.

How to care less (strategically). You can't die on every hill. Learning which battles matter and which ones are just your ego talking will save your sanity and your career.

None of this comes from courses. It comes from doing the work, badly, repeatedly, until you get less bad at it.

The Portfolio Piece That Changed Everything

Want to know the project that finally got me hired? It wasn't some pristine case study with perfect process documentation.

It was a janky Chrome extension I built to fix my uncles's most-hated website.

My uncle, who types with two fingers and thinks "the cloud" is suspicious, couldn't figure out how to pay his water bill online. The city's website was a masterpiece of bureaucratic user hostility.

So I spent a weekend hacking together something that just... fixed it. Auto-filled the confusing forms. Highlighted the actually important information. Added a big, impossible-to-miss "PAY BILL" button.

It was ugly. It broke half the time. It only worked for one specific website in one specific city.

It also solved a real problem for a real person who was really pissed off.

That messy little project taught me more about design than two years of courses combined. It also gave me the best interview story I've ever had. Turns out, hiring managers love hearing about times you solved actual problems for actual humans.

The Uncomfortable Truth About Design Skills

Most of us already know enough to start. We just don't want to admit it because starting is terrifying.

Courses feel safe. There's a syllabus, a progress bar, a certificate at the end. You can't really fail at watching videos and completing exercises.

Real projects? Those can fail spectacularly. You might design something nobody uses. You might not know how to handle client feedback. You might realize you're not as good as you thought you were.

But here's the thing: You learn more from one failed real project than from ten successful course completions.

What Sarah Did Next

Remember Sarah from the beginning? I convinced her to try an experiment: One month, no courses. Instead, she had to ship one thing per week. Anything. Didn't matter how small or silly.

Week 1: She redesigned her apartment building's catastrophically bad laundry room sign-up sheet. Printed it. Hung it up. People actually used it.

Week 2: Made a simple website for her cousin's dog-walking business. It had five pages and one contact form. Her cousin cried with happiness.

Week 3: Created a Chrome extension that blocked course platform websites between 9 AM and 5 PM. (I'm not joking. She actually did this.)

Week 4: Redesigned the donation flow for a local animal shelter's website. Sent it to them unsolicited. They implemented two of her suggestions.

Four weeks. Four real things in the world. Zero certificates earned.

She got her first design interview the next month. They spent the entire time talking about the laundry room sign.

So What Now?

If you're sitting on twenty tabs of course landing pages right now, here's my advice:

Close them. All of them.

Pick the ugliest, most broken thing you interact with regularly. Could be an app, a website, a paper form at your dentist's office. Doesn't matter.

Fix it. Or try to. You'll probably make it worse at first. That's fine.

The point isn't to create something perfect. It's to create something. To move from learning about design to doing design. To stop preparing for a career and start having one, even if it's messy and small and starts with redesigning your building's laundry sign-up sheet.

The Plot Twist

Here's what the course sellers won't tell you: Every working designer still feels like they don't know enough. We all google basic stuff daily. We all have imposter syndrome. We all look at job postings and think "I only know 60% of this."

The difference between working designers and eternal students isn't knowledge. It's the willingness to jump in at 60% and figure out the rest as we go.

Your incomplete knowledge is enough to help someone with something. Today. Right now. Without taking another course.

Final Thought (Or Whatever)

The design education industry thrives on making you feel perpetually unprepared. They profit from your insecurity. They've turned professional development into a subscription service where the bill never stops coming and the product never quite delivers what you need.

But you don't need their permission to start designing. You don't need their certificates to solve problems. You don't need to know everything to know enough.

You just need to stop learning and start doing.

Even if it's messy. Even if it's small. Even if it's just making a better sign for your apartment's laundry room.

That's where real design careers begin. Not in course catalogs or certificate frames, but in the messy, imperfect act of trying to make something slightly less frustrating for another human being.

Sarah gets that now. She's stopped collecting certificates and started collecting problems to solve.

Her course completion rate has plummeted. Her design skills have never been stronger.

Funny how that works.

P.S. - If you're reading this while procrastinating on another course purchase, consider this your sign to close that tab and go fix something broken instead. The worst that happens is you'll have tried. That already puts you ahead of everyone still watching introduction videos.

Stop Teaching Users To Ignore You: Rethinking “Maybe later”

Tanya Donska — Tue, 16 Sep 2025 14:19:40 +0000

Last Tuesday I watched a new user bounce around a freshly minted dashboard. Up pops the friendly onboarding modal: "Welcome! Let us show you around." Two buttons: "Get started" and "Maybe later".

They hit "Maybe later" without reading the headline. Three minutes of guesswork. Five minutes later, the tab is closed.

This person wanted to succeed - they had just paid. But our first decision taught them to choose ignorance over guidance.

Designers, this one is on us.

Politeness theatre vs product outcomes

"Maybe later" looks considerate. We tell ourselves we are giving control and avoiding coercion.

I have shipped that modal too. It feels humane in a Figma frame. In the wild, it mostly operates as an opt-out from learning.

On one product we tracked, users who tapped "Maybe later" during onboarding had 73% higher churn. Not because they were less motivated - they had literally just signed up - but because we gave them permission to remain confused at the exact moment confusion is most expensive.

What reads as politeness in UI often converts into avoidable support tickets, abandoned features and lower LTV.

What the button communicates (whether you intend it or not)

When you place "Maybe later" next to essential guidance, you encode three messages into the interface:

This isn't urgent. If it really mattered, it would not be so easy to skip. Priority is telegraphed by friction.
Decide before you understand. You are asking users to make a meta-decision while they are cognitively cold. Faced with uncertainty, people default to the lowest-effort option: dismiss.
Success can wait. Every skipped explainer becomes a trap they will fall into later, when there is no supportive context on screen.

That is decision architecture, not just microcopy.

The moment the penny dropped

During a collaboration test, a tooltip explained shared cursors with "Got it" and "Maybe later". The participant dismissed instantly - not from disinterest, but because she was mid-task.

Ten minutes on, she tried to collaborate, could not see her teammate's cursor, and concluded the feature was broken. We had taught her to defer learning until failure, then left her to carry the cost.

We did not need more tutorial content. We needed a different delivery mechanism.

Design for learning-in-flow

The best products do not force a choice between learning and doing. They entwine them. Patterns that consistently outperform the modal-plus-skip pattern:

1) Contextual, just-in-time cues

Trigger lightweight guidance at the moment of intent, not on page load. A micro-hint that appears when a user opens the sharing panel lands better than a blanket tour on first visit. Keep copy atomic - one job per hint.

Design notes

Anchor hints to the control or surface being explained.
Prefer inline affordances and empty-state helpers over centre-screen overlays.
Set decay rules so hints do not reappear once demonstrated success is observed.

2) Outcome-framed microcopy

Users do not care about features - they care about not being stuck next week.

Instead of: "Use tags to organise tasks."

Try: "Tag now to find this in seconds next week."

Swap nouns for verbs, and verbs for outcomes. If the user cannot answer "what do I get for doing this now?", your copy is probably UI-centric rather than user-centric.

3) Progressive disclosure by default

Expose the minimum surface to get started, then reveal depth on demand. Allow users to master a narrow path, then progressively layer in capability. Progressive disclosure is not dumbing down - it is sequencing complexity in a way brains can absorb.

4) Guardrails over gates

If skipping truly risks error, add a light guardrail rather than a hard block.

Pattern: soft confirmation

"This step prevents common mistakes with invoices. Skip anyway?"

You are not coercing - you are calibrating the cost of the decision.

5) Durable return paths

If users are not ready now, they must know where help lives later. Bake a visible Learn surface into the product chrome: a help icon with contextual articles, a searchable command palette that surfaces how-to actions, or a checklist that sits in the sidebar rather than in a modal.

6) Demonstrations beat descriptions

When possible, show the behaviour. Micro-animations, ghost states and interactive "try it" sandboxes often out-teach paragraphs. If a control supports drag, hint with a tiny nudge. If collaboration has presence, pulse the avatar once.

Patterns and when to use them

First-run checklists
Replace the tour with a 3–5 item checklist aligned to activation moments. Each item deep-links to the task and auto-ticks on success. The list lives in the UI until completion, then retires quietly to Help.
Inline empty states
When a surface is empty, the most valuable content is an action that fills it. "Create your first rule" with a one-line benefit and a primary button beats a paragraph about rules.
Embedded coach marks
Small, anchored notes that appear after an intentional hover or focus, not on page load. Always provide an obvious way to bring them back.
Command palette education
Treat the palette as a learning surface. Surface verbs like "invite teammate" or "set up billing" with one-line benefits and result previews.
Checklists with consequences
If a skipped step will degrade the experience, reflect that status in-line: "Billing not set - usage capped at 5 exports" with a direct fix action.

What to instrument

If you are removing "Maybe later", measure the right things so design debates move from taste to telemetry:

Activation events: proportion of new users who reach the first meaningful outcome.
Time-to-value: median time to complete the core task once.
Guided action completion rate: how often a just-in-time hint leads to a successful action within the same session.
Help return paths: % of users who reopen guidance from the chrome and succeed on the next attempt.
Feature false-negative rate: sessions where users try a capability, fail, and do not return within 7 days.
Rage-click or backtrack signals: reductions here indicate guidance is doing real work.

A simple decision rubric for designers

Keep a skip only if all three are true:

The step is genuinely optional for immediate success.
The cost of skipping is legible to the user at the moment of choice.
There is a durable, obvious path to return later that does not require hunting through docs.

If any of these fail, do not offer a "Maybe later". Use contextual guidance, a checklist or a soft confirmation instead.

The real choice

Do you want users to succeed now, or do you want them to feel they controlled their confusion? Those are not the same. Optimising for the feeling of control at the expense of actual success hurts everyone.

Users do not want more choices. They want better outcomes. They want to feel capable using your product without friction.

"Maybe later" optimises for politeness over effectiveness. There is nothing polite about letting people fail when you could have helped them succeed.

The products that feel effortless do not offer escape hatches from learning. They make learning feel effortless too.

This is the kind of problem we obsess over at DNSK WORK. Small interface decisions shape how people learn your product, and the difference between good and great often hides in those seams.

https://dnsk.work/

Your Product Feels Complex? Give It a Spine

Tanya Donska — Tue, 09 Sep 2025 12:49:27 +0000

I was in a Zoom call last week with a founder who looked genuinely defeated. "Our product is getting too complex," he said, pulling up screenshot after screenshot of interfaces that all looked... fine? Good, even. But something was off.

Then he showed me how users actually moved through the app. It was like watching someone navigate a house where every room had different rules. The kitchen worked one way, the bedroom another, and the bathroom might as well have been from a different house entirely.

That's when I realized: this isn't about complexity. It's about personality. His product didn't know what it wanted to be.

The Lie We Tell Ourselves About Complexity

Here's the thing that took me years to figure out: when founders say "our product is too complex," they're almost never talking about the actual functionality. They're talking about cognitive load.

I've seen this pattern dozens of times now. The product can do amazing things, but using it feels like constantly having to relearn how to drive every time you get in a different car.

Last month, I was working with a team whose app had five different ways to create something new. Five. Each one made perfect sense in isolation—the designer could walk me through the reasoning for every choice. But for users? It was like the app had multiple personality disorder.

The real kicker? When we dug into their analytics, 80% of users were only using the most basic version of each feature. All that careful customization, all those edge cases they'd designed for—mostly ignored. Because people couldn't predict how the app would behave, so they stuck to the safest, most obvious path.

What I Learned from Watching 100+ User Sessions

I started obsessively watching user session recordings a couple years ago. Not the highlight reels from usability tests, but raw footage of people actually trying to get work done.

The pattern was always the same: Users would learn how to do something in one part of the app, then encounter a similar task elsewhere and... pause. You could see them thinking, "Wait, does this work the same way it did over there?"

That hesitation kills momentum. It breaks trust. Users start feeling like they need to be careful, like they might break something or miss something important if they don't pay attention to every detail.

But in the apps that felt effortless? Users would encounter something new and just... try it. Because they'd unconsciously learned the app's personality. They knew how it would behave.

The Modularity Revelation That Changed Everything

I used to think modularity was about efficiency—reusing components to ship faster. That's true, but it misses the bigger point.

Real modularity is about creating a shared language between your product and your users. When someone learns how to delete something in one context, they should be able to delete anything, anywhere, with confidence.

I learned this the hard way working on a fintech app a few years back. We had this beautiful, consistent visual design system. Every button looked identical, every form followed the same layout principles. But the interactions? Chaos.

Transferring money between your own accounts worked completely differently from paying someone else. The confirmation flow for recurring payments bore no resemblance to one-time payments. Users were constantly second-guessing themselves: "Am I in the right place? Is this going to work the way I expect?"

The breakthrough came when we stopped designing features and started designing verbs. How does "transfer" work? How does "confirm" work? How does "undo" work?

Once we nailed those interaction patterns, everything clicked. New features became compositions of familiar moves instead of novel experiences requiring new mental models.

The Invisible Patterns Users Crave

Here's what I notice when I watch users interact with well-structured products: they develop muscle memory not just for where things are, but for how things behave.

They learn that error messages in this app are always actionable, never just apologetic. They discover that when they're about to do something potentially destructive, the app will always give them a clear way out. They internalize that "save" means "save and stay here" while "save and continue" means exactly that.

These aren't features. They're promises your product makes to users about how it will behave. And the magic happens when users start trusting those promises.

I remember working with one team that was getting crushed by support tickets. Users constantly asking how to do things that should have been obvious. We spent weeks analyzing the requests, looking for patterns.

The insight wasn't what we expected. It wasn't that any individual flow was broken. It was that users had learned not to trust their instincts about how the app worked. They'd been burned too many times by inconsistent behavior, so they'd stopped assuming anything.

Language is Everything (And We're All Terrible at It)

One of the most embarrassing realizations of my career: I was calling the same concept by different names throughout an entire product. In onboarding, we talked about "workspaces." In the main nav, they were "projects." In the billing section, somehow they'd become "accounts."

Users weren't confused about the functionality. They were confused about whether they were looking at three different things or the same thing in three different contexts.

Now I obsess over this stuff. I keep a shared vocabulary document for every project—not buried in some wiki, but right in the design files and the codebase comments. When someone suggests a new term for an existing concept, we have a conversation about whether it's actually better or just... different.

The ripple effects of consistent language are insane. Support tickets drop. Onboarding becomes self-explanatory. New team members can understand the product faster because the concepts have stable names.

How Teams Actually Break Things

I've seen the same pattern kill modularity efforts over and over: someone builds a great pattern, it works beautifully in one context, then gets copy-pasted into a slightly different context where it doesn't quite fit.

Instead of adapting the pattern thoughtfully, they just... tweak it. A little. Just for this one case.

Six months later, you have seven variations of the same interaction, each one slightly different, none of them clearly better than the others. Users can't develop muscle memory because the muscle memory keeps getting invalidated.

The solution isn't to be rigid about never adapting patterns. It's to be intentional about when and why you break consistency. If you're going to do something different, make it obviously different, not subtly different.

What Changes When You Get the Personality Right

There's this moment—I've seen it happen maybe a dozen times now—when a product finds its personality. User behavior completely changes.

Support tickets shift from "how do I do this?" to "can you add this feature?" Users start exploring instead of tiptoeing. They begin to trust their instincts about how things will work.

But the most telling change? The internal conversations. Product discussions stop being about micro-interactions and start being about capabilities. Design reviews become faster because there are fewer arbitrary choices to debate.

I worked with one team that went from spending 30% of their engineering cycles on "small UX improvements" (translation: fixing inconsistencies) to maybe 5%. That's not because they stopped caring about user experience. It's because they'd front-loaded the consistency work, so new features just... worked predictably.

The Thing No One Talks About

Here's what I wish someone had told me five years ago: giving your product a consistent personality isn't a design problem. It's a communication problem.

The best design system in the world won't help if your team doesn't have shared mental models about how the product should behave. You need to get everyone—designers, developers, PMs, even support people—aligned on the personality you're building.

I've started doing these weird little exercises with teams. I'll ask everyone to describe the product as if it were a person. Is it helpful or efficient? Careful or fast? Formal or casual?

The answers are always all over the place initially. But by the end of the conversation, we usually land on something everyone can rally around. And that becomes the north star for all the micro-decisions that actually determine how the product feels.

Starting Small (But Starting Right)

Every time I suggest this approach, someone asks: "But where do we start? We can't rebuild everything."

You don't need to. Pick the one user flow that's causing the most confusion right now. Make that flow work consistently from start to finish. Get everyone on the team to use the same words for the same things in that flow.

Then watch what happens. Users will start completing that flow faster. Support tickets about that area will drop. And—this is the part that hooks teams—building new features in that area becomes easier because you have established patterns to compose from.

I've seen teams transform their entire product by fixing one flow at a time. It takes longer than a big redesign project, but it's also way less risky and way more sustainable.

The goal isn't perfection. It's predictability. And predictability, it turns out, feels like simplicity to users—even when you're doing complicated things.

What This Really Means

The products I love using don't feel simple because they do simple things. They feel simple because they do complex things in ways that make sense to me.

That's not about visual design or information architecture or any of the stuff we usually focus on. It's about behavioral consistency. It's about your product having a clear personality that users can learn to predict and trust.

Most products I encounter feel like they were designed by committee—not because too many people were involved, but because those people never aligned on what personality they were building.

Give your product a spine. Not a design system, not a style guide, but a clear sense of how it behaves in the moments that matter to users.

Do that, and the word "complex" just... disappears from conversations. Because complexity was never the real problem. The problem was unpredictability. And unpredictability is absolutely fixable.

Why SaaS Pricing Pages Fail

Tanya Donska — Thu, 04 Sep 2025 13:39:13 +0000

I’ve made pricing pages I was quietly proud of. Clean grids. Calm colours. A monthly/annual toggle that felt clever until it pushed the CTA just enough to break the fold on Safari. In screenshots, they looked convincing.

In practice, they behaved like polite doormen who never actually opened the door.

The first time a pricing page embarrassed me

We launched a tidy redesign on a Tuesday. By Friday, conversions were flat, support kept fielding “what’s included again?”, and sales were spending the first ten minutes of every call just explaining tiers. No one said the page was ugly. They said it was unclear. Which is worse. An ugly page that’s clear will still sell. A pretty page that whispers will not.

I opened the file and realised I’d built a catalogue, not a decision. Thirty rows of micro‑differences. Tooltips everywhere. Three primary CTAs because I couldn’t choose which conversation to have. It wasn’t a pricing page; it was my indecision with rounded corners.

What a pricing page quietly says (about you and me)

We pretend it’s about money. It’s about confidence.

Tooltips on every other line say: we don’t trust our words.
Every plan including everything says: we’re afraid to choose.
Starter/Pro/Enterprise cloned from the neighbour says: we hope imitation reduces risk.

Buyers read all of that, even if they don’t say it aloud.

Three mistakes I won’t repeat

1) Feature bingo
I once shipped a table with so many rows you needed a packed lunch to reach the footer. Buyers didn’t compare; they postponed. If you need binoculars to tell plans apart, you’re not selling—you’re daring people to open a spreadsheet.

2) CTA soup
Book demo. Try free. Talk to sales. Compare plans. All above the fold. That isn’t helpful; it’s a hostage situation. A pricing page needs one clear next step. Two at a push. Everything else belongs lower down or in a footer.

3) The week‑one ambush
Listing a feature on the table and then locking it behind “upgrade to unlock” two days later. Yes, short‑term ARPU ticked up. Trust fell through the floor. People remember the wall more than the upgrade.

What I aim for now

Tiers by outcome, not headcount
For launching. For growing. For scaling teams. Speak to the job that changes when they buy—not their job titles.

One safe recommendation
Highlight a default with “Best for most teams”. It’s not hand‑holding; it’s a shortcut past decision fatigue.

Three value stories, not thirty rows
Group features by Collaboration / Automation / Insight. If a line doesn’t fit a story, it’s either not core or it needs clearer language.

Transparent logic
If you’re usage‑based, show the maths with two simple examples. If you’re tiered, state what actually changes and why. No riddles. No asterisks pretending to be clarity.

No surprise maths
Let people estimate the bill without handing over an email. Radical, yes. Also respectful.

A tiny chooser
“Not sure? Answer three questions.” It’s not cute; it’s humane.

One primary action
Start free or Talk to sales. Pick. The other can be secondary. Two primaries is cowardice dressed as choice.

A short story with numbers (and sleep)

We helped a team whose page looked handsome and converted like soup. We didn’t reskin. We reframed: rebuilt tiers around real journeys in the data; rewrote features in human; added a tiny chooser; moved limits into a plain “What’s included, exactly” panel with actual numbers; removed the “included*” bait entirely. Six weeks later: conversions up 22%, support tickets down, the founder texting that they were finally sleeping. I’ll take boring improvements over shiny experiments most days.

If I had your page for a week

Day 1 — Rename the tiers
Outcomes and who it’s for in one line each. No poetry.

Day 2 — Cull the noise
Three clusters max. Anything with asterisks goes into a readable Limits panel.

Day 3 — Pick a default
Mark it as “Best for most teams”. Stand by it.

Day 4 — Reduce CTAs
One primary, one secondary. Everything else moves south.

Day 5 — Show the bill
Two worked examples. No calculator required.

Day 6 — Add the chooser
Three questions; one suggestion. It should feel like help, not a quiz.

Day 7 — Instrument and listen
Track plan clicks, time on page, chooser completion, and the “I thought this included…” tickets. Fix what those reveal first.

Copy I actually ship

Plan label — For growing teams
Why — Ship faster, keep control.
Cluster — Automation
Line — Remove handoffs, not oversight.
Limits — What’s included, exactly
Items — Requests/month, seats included, data retention. (Numbers, not vibes.)
Helper — Not sure? Answer 3 questions → we’ll suggest a plan.

One smile per page, maximum. Pricing is a commitment, not stand‑up.

Quick tests I like

30‑second test — Can someone explain their total cost aloud in thirty seconds? If not, fix the page, not the prospect.
Blindfold test — Hide logos. If your page is indistinguishable from competitors’, you don’t have pricing, you have camouflage.
Regret test — Pull last month’s “I thought this included…” tickets. If you hear the same line twice, the table owes an answer.

Founder note (with love)

If your pricing page hasn’t moved in a year, it’s leaking—money, confidence, and time you’re spending on calls a clear table should close. The fix isn’t a rebrand. It’s an hour a day for a week.

Choose outcomes. Pick a default. Tell the truth about limits. Cut the extra buttons. Show the bill. Then stop fiddling and watch the numbers. If it sells, keep it. If it confuses, don’t defend it—rewrite it.

The pricing page is where trust does the paperwork. Make it earn its keep.

The Discovery Problem Every Designer Knows (But Rarely Talks About)

Tanya Donska — Tue, 02 Sep 2025 13:16:06 +0000

We spend months crafting the perfect user flow. We obsess over micro-interactions, debate button colors, and run A/B tests on copy variations. But then users completely miss the feature we spent all that time perfecting.

It's the kind of problem that keeps you awake at night, wondering if you're actually solving the right problems.

I've been designing digital products for over a decade, and I've seen this pattern repeat itself across teams, industries, and company stages. We design beautiful, functional experiences that users simply never encounter. Not because they're bad, but because they're invisible.

This isn't about information architecture or navigation design—though those matter. It's about something deeper: the gap between what we design and what people actually discover.

The Uncomfortable Truth About User Behavior

Here's what we know but don't always want to admit: users don't explore interfaces the way we think they do.

As designers, we know every corner of the products we work on. We understand the logic behind our navigation structures. We can find any feature in three clicks because we designed those clicks.

But users approach our interfaces with completely different mental models. They're task-focused, often distracted, and operating under cognitive load we rarely account for. They don't browse—they scan for the specific thing that will solve their immediate problem.

This creates a fundamental mismatch. We design comprehensive solutions, but users consume interfaces incrementally, discovering features only when they have an immediate need.

The result? Even well-designed features become what I call "dark matter"—they exist in the interface, but users move through the product as if they're not there.

Why Good Design Still Fails Discovery

I've seen this play out in predictable patterns:

We prioritize visual hierarchy over functional visibility. A feature might be perfectly placed according to design principles but completely invisible in the user's workflow context. Clean layouts can sometimes hide more than they reveal.

We assume progressive disclosure works universally. We tuck advanced features behind secondary menus to keep interfaces uncluttered, but this often means that valuable capabilities never see daylight. The cleanest interface isn't always the most discoverable one.

We design for the ideal user journey. Our prototypes follow logical, sequential paths, but real users rarely move through products linearly. They jump around, skip steps, and often arrive at features from unexpected directions.

We confuse feature completeness with feature accessibility. Having built something comprehensive doesn't mean it's comprehensible to someone encountering it for the first time.

The Design Patterns That Actually Work

After years of watching user sessions and analyzing product analytics, I've noticed that successful feature discovery rarely happens by accident. It requires intentional design decisions that prioritize discoverability alongside functionality.

Contextual revelation over comprehensive menus. Instead of organizing everything into perfect taxonomies, surface features when and where users are most likely to need them. The best time to introduce an advanced filter isn't in the main navigation—it's when someone is clearly struggling with too many results.

Progressive familiarity, not just progressive disclosure. Rather than hiding complexity behind layers, gradually introduce users to more sophisticated capabilities as they demonstrate readiness. This means designing entry points that feel natural at different stages of user maturity.

Embedded education over separate onboarding. The most effective feature introductions happen within the workflow, not in isolation. Empty states, confirmation messages, and intermediate steps are opportunities to reveal new possibilities without breaking the user's mental flow.

Outcome-focused affordances over feature-focused ones. Design interface elements that communicate what users can accomplish, not just what actions they can take. This is the difference between a button labeled "Advanced Search" and one labeled "Find Exactly What You Need."

Measuring Discovery in Design

As designers, we often focus on usability metrics—task completion rates, error rates, time on task. But discovery requires different measurements:

Feature encounter rates: How often do users come across specific capabilities during normal usage? This is different from usage rates—it measures awareness opportunity.

Discovery-to-adoption conversion: When users do encounter a feature, what percentage try it? This indicates whether your design successfully communicates value and functionality.

Contextual success rates: Are users finding features when they need them most, or only during random exploration? Context-appropriate discovery is far more valuable than accidental discovery.

Progressive engagement patterns: Do users graduate from basic to advanced features over time, or do they remain stuck in a narrow subset of capabilities? This reveals whether your information architecture supports growth.

The Founder's Dilemma

For design-minded founders, this problem is particularly acute. You're intimately familiar with every design decision, every feature interaction, every pixel placement. You know the product so well that testing it yourself becomes almost meaningless.

But your users don't have that context. They encounter your interface with fresh eyes, different expectations, and immediate goals that might not align with your carefully planned user journeys.

This creates a blind spot that's difficult to recognize and even harder to address. You might interpret low feature adoption as a product-market fit issue when it's actually a design discovery issue. Users might love the features they find but never encounter the ones that would make them truly successful.

Designing for Discovery, Not Just Usage

The solution isn't to make everything more prominent—that way leads to cluttered, overwhelming interfaces. Instead, it's about designing discovery moments as intentionally as we design primary workflows.

This means treating feature revelation as a design problem worthy of the same attention we give to visual design and user experience. It means prototyping not just how features work, but how users encounter them. It means measuring not just whether users can complete tasks, but whether they discover the capabilities that make those tasks worthwhile.

Good discovery design is invisible when it works. Users don't notice the careful choreography that led them to find exactly what they needed at exactly the right moment. They just feel like the product "gets" them.

But when discovery design fails, even the most beautiful, functional features become irrelevant. They might as well not exist.

The Real Design Challenge

The most interesting design problems aren't about making things easier to use—they're about making valuable things easier to find. Not just findable in the sense of information architecture, but discoverable in the sense of user journey.

This requires thinking beyond individual screens and flows to consider the entire ecosystem of user behavior over time. How do users evolve their relationship with your product? What triggers their curiosity about new capabilities? When are they most receptive to learning something new?

These are design problems, but they're not the kind we typically discuss in design communities. They sit at the intersection of user experience, product strategy, and human psychology.

Yet they might be the most important problems we solve. Because the difference between a feature that gets used and one that gets ignored often comes down to design decisions we make long before the user ever encounters that feature.

The best products don't just work well—they reveal their value gracefully, over time, in ways that feel natural and inevitable.

That's not an accident. It's design.

DNSK WORK helps design teams solve discovery problems in digital products. Because well-designed features deserve to be found.

Feature Discovery: The Marketing Problem Hiding in Your Product

Tanya Donska — Tue, 02 Sep 2025 13:12:26 +0000

Your engineering team just shipped that feature you've been promising customers for months. The one that differentiate you from competitors. The one that justifies your pricing tier.

But six weeks later, your usage analytics tell a different story. Adoption is sitting at 12%. Support tickets are asking about functionality that already exists. And your biggest competitor just announced something remarkably similar to what you launched quietly last quarter.

This isn't a product problem. It's a marketing problem – and it's costing you more than you realize.

The Hidden ROI Killer in Your Stack

Most marketing teams obsess over top-funnel metrics. CAC, conversion rates, demo-to-close ratios. But there's a massive leak happening downstream that rarely gets measured: feature discoverability.

Consider the economics: if you spent $50K developing a feature that drives retention, but only 15% of users ever find it, you've effectively spent $333 per actual user reached. Meanwhile, that same feature could be driving expansion revenue, reducing churn, and creating competitive differentiation – if people knew it existed.

Feature invisibility directly impacts three core marketing KPIs:

Product-qualified lead (PQL) conversion: Users who don't discover key features never hit activation milestones
Net revenue retention (NRR): Customers can't expand usage of capabilities they don't know about
Customer lifetime value (CLV): Hidden value props mean shorter retention and lower expansion

Why Features Become Marketing Dead Weight

From a marketing perspective, feature invisibility typically stems from four systemic issues:

Launch theater without adoption strategy. You announce the feature (blog post, email, maybe a webinar), but there's no systematic plan for ongoing discovery. The changelog is not a marketing channel.

Product-led growth without product-led discovery. You've optimized your funnel for self-service adoption, but haven't applied the same rigor to feature adoption within the product experience.

Messaging fragmentation. Marketing talks about features in terms of business outcomes, but the UI uses technical language or vague icons. Users can't connect your value prop to what they see in-product.

No activation measurement beyond initial signup. You're tracking trial-to-paid conversion, but not feature-to-engagement conversion. What gets measured gets optimized.

The Data You're Probably Missing

Most marketing analytics focus on acquisition metrics, but feature discovery requires behavioral analytics:

Feature funnel analysis: Track the path from feature exposure to first use. Where do users drop off? Is it awareness, understanding, or execution?

Contextual conversion rates: Measure feature adoption based on user intent signals. Someone exporting data is more likely to discover your API than someone just browsing.

Time-to-value correlation: How does feature discovery timing impact trial conversion and retention? Early discovery of high-value features often correlates with higher LTV.

Support ticket categorization: What percentage of your support volume is requests for functionality that already exists? This is pure marketing inefficiency.

Strategic Approaches to Feature Marketing

Effective feature discovery requires treating in-product experiences as marketing channels:

1. Progressive Value Revelation

Instead of front-loading all features in onboarding, map feature introduction to user maturity stages. A user managing their first campaign doesn't need advanced analytics yet – but they will in week 3.

Map your feature set against the customer journey:

Activation features (week 1): Core workflow, basic functionality
Engagement features (weeks 2-4): Efficiency tools, customization
Expansion features (month 2+): Advanced capabilities, integrations

2. Contextual Feature Promotion

Treat empty states, loading screens, and workflow completions as marketing real estate. Instead of generic "No data yet" messages, show relevant feature entry points.

Example: A user who just completed their first automation sees a prompt about advanced scheduling options, not a generic "Upgrade to Pro" banner.

3. Outcome-Based Feature Naming

Marketing teams understand value propositions, but product teams often default to feature-based naming. Bridge this gap by auditing UI copy through a marketing lens.

"Export Data" → "Share Results"

"Advanced Filters" → "Find Specific Records"

"API Access" → "Connect Your Tools"

4. Feature Lifecycle Management

Treat feature launches like product launches with distinct phases:

Pre-launch: Seeding awareness with high-value users
Launch: Coordinated announcement across channels
Adoption: Systematic in-product promotion and education
Optimization: Analytics-driven iteration on discovery mechanisms

Measuring Feature Marketing ROI

To build a business case for feature discovery optimization, track these marketing-aligned metrics:

Feature-to-revenue attribution: Connect feature adoption to expansion revenue. Users who discover integration features are 3x more likely to upgrade plans.

Discovery-assisted conversions: What percentage of trial-to-paid conversions include discovery of differentiating features? This shows competitive advantage realization.

Support deflection value: Calculate the cost savings when users self-discover instead of creating support tickets. This is pure margin improvement.

Churn prevention correlation: Users who discover retention-driving features within the first 30 days show 40% lower churn rates.

Building Cross-Functional Feature Discovery

This requires marketing and product alignment around shared objectives:

Joint success metrics: Both teams should be measured on feature adoption rates, not just marketing on leads and product on shipping velocity.

Shared user research: Marketing's customer insights should inform feature positioning, while product's usage data should inform marketing messaging.

Coordinated release cycles: Marketing campaigns shouldn't just announce features – they should drive in-product discovery through targeted user cohorts.

Integrated analytics: Marketing attribution should extend through feature adoption, not stop at signup or trial conversion.

The Competitive Reality

While you're trying to figure out why users aren't discovering your differentiating features, your competitors are solving the same customer problems with more obvious solutions. Feature invisibility is a competitive vulnerability.

The companies winning in crowded markets aren't necessarily building better features – they're building features that users can actually find and understand. They're treating feature discovery as a marketing discipline, not just a UX consideration.

Your development team built the capability. Your marketing team sold the vision. But if users can't bridge that gap independently, both efforts are wasted.

The most sophisticated feature in your product is worthless if it doesn't show up in your customer success stories, expansion conversations, or competitive positioning.

Stop marketing features you've built. Start building marketing into the features themselves.

Need help optimizing feature discovery for marketing impact? DNSK WORK specializes in product-marketing alignment for SaaS growth.

Your Settings Page Became the Product

Tanya Donska — Thu, 28 Aug 2025 13:21:43 +0000

I’ve worked on SaaS products where the Settings page quietly swallowed the whole experience. Not in one dramatic release – in gentle increments. A toggle here to “keep options open”, a checkbox there to “unblock a stakeholder”, a dropdown to “cover an edge case”. It feels generous in the moment. It reads like hesitation later.

This is a personal take on the wall-of-settings problem - a little softer round the edges, more liberal in spirit, and firmly on the side of users who want to get on with their day.

Confession: I’ve helped build those walls. This is how I try to undo them now.

What bloat looks like up close

Bloat rarely looks like clutter while you’re adding it. It looks like kindness.

An “Advanced” switch with a vague description that no one wants to delete
Two places to manage notifications because both teams were right in their own way
Privacy choices hidden under “Enhanced personalisation” because the label debate timed out
Feature flags that escaped into public view and never returned

Individually, harmless. Together, a cognitive tax. Users don’t feel powerful - they feel responsible for our indecision. I’ve shipped all four at some point; I still wince when I read the old tickets.

Why we bolt on toggles

The generous answer: we care about choice. The honest answer: we avoid decisions.

Stakeholders ask for flexibility and we oblige
A vocal minority keeps a legacy switch alive
Settings become the compromise when we can’t align on a default
We tell ourselves it’s user empowerment, when it’s really risk transfer

I say this with love - I’ve done it too. The fix isn’t shame. It’s craft.

My tell: the moment I hear myself say “we’ll just add a setting,” I’m dodging a decision.

A liberal take on control

“Liberal” here means trusting users with meaningful control and liberating them from busywork. Pick clear defaults where the product can be smart. Offer choice only where outcomes genuinely differ.

Think in tiers:

Default with a reason – the product chooses well most of the time and says why
Presets for real jobs – Focused, Standard, Everything beats fifteen granular sliders
Advanced when it’s genuinely advanced – tucked away with a one-line promise of what’s inside

That’s not paternalistic. It’s respectful. You’re saving attention for the moments that matter.

My “Settings Amnesty” week

A ritual I run with teams when the wall starts creaking:
Day 1 – Inventory
List every setting across web, desktop, mobile. Note owner, default state, last updated. No judgement yet.

Day 2 – Usage and intent
Pull 90-day usage and 6 months of support mentions. I bring biscuits for Day 2 - feelings come up. For each control, answer: what job does this serve? If we removed it, who would hurt?

Day 3 – Merge and move
Collapse duplicates. Move in-flow preferences into the place they matter. Hide admin-only switches from end users.

Day 4 – Replace with patterns
Trade toggles for presets, sensible defaults, progressive disclosure. Add previews. Make destructive choices clear and reversible.

Day 5 – Language pass
Rename for humans. Headings are facts, not vibes. Buttons are outcomes, not chores. Tooltips that explain basic controls are a design bug - fix the control and delete the tooltip.

Ship a small set each day. Measure for two weeks. Keep the wins.

What to keep, what to retire

Keep controls that:

Change outcomes in obvious, high-utility ways
Satisfy compliance or accessibility needs that can’t be inferred
Support professional workflows where presets genuinely won’t do

Retire controls that:

Exist to appease an internal argument
Duplicate functionality elsewhere
See under 2 percent usage without a safety or compliance rationale

If you’re unsure, move the control closer to the task. If it becomes clearer in-context, keep it. If it vanishes from memory, it was busywork.

Language that doesn’t apologise

A charming voice can still be decisive. Try this spine:

Say what this affects – “Notifications for mentions and DMs”
Say the default and why – “Default: Focused, to reduce noise”
Give one confident next step – “Switch to All activity if you need full visibility”

Avoid hedging. Maybe, just, a bit, kind of - all of these leak confidence. Friendly is fine. Foggy is not.

My sticky note: maybe, just, a bit, kinda, looks like. If one ships under my watch, coffee’s on me.

Where settings actually belong

In-flow controls – sort order, density, filters. Immediate, reversible, and next to the thing they change
Onboarding choices – a small number of decisions that shape the experience from day one
Admin/advanced – high-impact, infrequent, clearly owned, with safe undo
No UI at all – when the product can infer a sensible behaviour and explain it transparently

A small story about trust

We once shipped a “Labs” section stuffed with switches. It felt exciting - like giving people the keys to the studio. Within a month our support queue filled with screenshots of states we hadn’t fully considered. We replaced ten toggles with three opinionated presets and a single Advanced link with a plain-English summary. Same capability, half the decisions, trust restored. No one wrote in to mourn the toggles. They thanked us for the calm. The morning after, our Slack was a forest of screenshots; I still have the search saved.

Measure the boring things

Simplicity is not just aesthetics - it’s operational. Track:

Time to first value for new users
Support tickets per 1,000 users referencing settings
Misconfiguration errors and recovery time
Task completion on flows previously blocked by choices

If those move in the right direction, your “fewer, smarter” bet is paying off.

The invitation

Be generous with outcomes, not switches. Keep the spirit of choice, lose the ritual of toggling. Choose well by default and show your workings. Offer control where it’s meaningful. Retire the rest with a short, honest note about why.

Clean the wall. Clarify the UX. Not because minimalism is fashionable - because attention is finite. Your users will thank you, not for more options, but for better ones.

That’s the pep talk I give myself before I add a toggle.

When your settings page becomes the product

Tanya Donska — Thu, 28 Aug 2025 13:19:32 +0000

This is a personal take on the wall-of-settings problem - a little softer round the edges, more liberal in spirit, and firmly on the side of users who want to get on with their day.

Confession: I’ve helped build those walls. This is how I try to undo them now.

What bloat looks like up close

Bloat rarely looks like clutter while you’re adding it. It looks like kindness.

An “Advanced” switch with a vague description that no one wants to delete
Two places to manage notifications because both teams were right in their own way
Privacy choices hidden under “Enhanced personalisation” because the label debate timed out
Feature flags that escaped into public view and never returned

Why we bolt on toggles

The generous answer: we care about choice. The honest answer: we avoid decisions.

Stakeholders ask for flexibility and we oblige
A vocal minority keeps a legacy switch alive
Settings become the compromise when we can’t align on a default
We tell ourselves it’s user empowerment, when it’s really risk transfer

I say this with love - I’ve done it too. The fix isn’t shame. It’s craft.

My tell: the moment I hear myself say “we’ll just add a setting,” I’m dodging a decision.

A liberal take on control

Think in tiers:

Default with a reason – the product chooses well most of the time and says why
Presets for real jobs – Focused, Standard, Everything beats fifteen granular sliders
Advanced when it’s genuinely advanced – tucked away with a one-line promise of what’s inside

That’s not paternalistic. It’s respectful. You’re saving attention for the moments that matter.

My “Settings Amnesty” week

A ritual I run with teams when the wall starts creaking:
Day 1 – Inventory
List every setting across web, desktop, mobile. Note owner, default state, last updated. No judgement yet.

Day 3 – Merge and move
Collapse duplicates. Move in-flow preferences into the place they matter. Hide admin-only switches from end users.

Day 4 – Replace with patterns
Trade toggles for presets, sensible defaults, progressive disclosure. Add previews. Make destructive choices clear and reversible.

Ship a small set each day. Measure for two weeks. Keep the wins.

What to keep, what to retire

Keep controls that:

Change outcomes in obvious, high-utility ways
Satisfy compliance or accessibility needs that can’t be inferred
Support professional workflows where presets genuinely won’t do

Retire controls that:

Exist to appease an internal argument
Duplicate functionality elsewhere
See under 2 percent usage without a safety or compliance rationale

If you’re unsure, move the control closer to the task. If it becomes clearer in-context, keep it. If it vanishes from memory, it was busywork.

Language that doesn’t apologise

A charming voice can still be decisive. Try this spine:

Say what this affects – “Notifications for mentions and DMs”
Say the default and why – “Default: Focused, to reduce noise”
Give one confident next step – “Switch to All activity if you need full visibility”

Avoid hedging. Maybe, just, a bit, kind of - all of these leak confidence. Friendly is fine. Foggy is not.

My sticky note: maybe, just, a bit, kinda, looks like. If one ships under my watch, coffee’s on me.

Where settings actually belong

In-flow controls – sort order, density, filters. Immediate, reversible, and next to the thing they change
Onboarding choices – a small number of decisions that shape the experience from day one
Admin/advanced – high-impact, infrequent, clearly owned, with safe undo
No UI at all – when the product can infer a sensible behaviour and explain it transparently

A small story about trust

Measure the boring things

Simplicity is not just aesthetics - it’s operational. Track:

Time to first value for new users
Support tickets per 1,000 users referencing settings
Misconfiguration errors and recovery time
Task completion on flows previously blocked by choices

If those move in the right direction, your “fewer, smarter” bet is paying off.

The invitation

Clean the wall. Clarify the UX. Not because minimalism is fashionable - because attention is finite. Your users will thank you, not for more options, but for better ones.

That’s the pep talk I give myself before I add a toggle.

Say the Thing: Clarity Over Politeness in UX

Tanya Donska — Tue, 26 Aug 2025 12:39:20 +0000

Thesis: Friendly tone is not the same as credible tone. Hedging language (“maybe”, “just a sec…”, “looks like…”) lowers confidence, slows decisions, and hides accountability. Warm + direct beats warm + vague every time.

Why this matters

Users judge competence in seconds. Tone is part of the signal. When copy refuses to commit, people infer the product won’t either. The result:

Slower task completion (extra reading to decode intent)
Higher abandonment at decision points (uncertain outcomes)
Support tickets that ask what happened and what next

Clarity is not cold; it’s a service. It reduces cognitive load and accelerates action.

The Politeness Pattern (and how to fix it)

Symptoms: apologetic banners, chirpy empty states, vague errors, CTA verbs that describe chores.

Replace with: facts, outcomes, and specific next steps.

Situation	Polite (weak)	Clear (strong)
Error	“Oops! Something might’ve gone wrong.”	“We couldn’t save your changes. Try again or reload.”
Destructive	“Are you sure you want to cancel? You’ll lose some data.”	“Cancel now deletes unsaved edits on this page. Keep editing or cancel anyway.”
Empty state	“Looks like nothing’s here yet :)”	“No items yet. Add your first item to continue.”
Spinner	“Just a sec…”	“Uploading files. You can navigate away—we’ll keep working.”
CTA	“Let’s maybe try saving this now?”	“Save and continue” / “See your cost breakdown”

Design rule: say what happened, what happens next, and what you want the user to do.

A compact style guide

Voice: warm and direct.
Verbs: will/won’t over might/maybe.
Buttons: outcomes, not chores.
Headings: facts, not vibes.

Error formula (C-I-A-R):

Cause (what failed)
Impact (what’s affected)
Action (what to do now)
Reassurance (what won’t be lost / what we’ll do)

Example: Payment failed (cause). Your subscription is paused (impact). Update your card to resume (action). Your projects remain safe (reassurance).

Loading states: say the operation and set expectations (progress, time, or backgrounding). Prefer skeletons to jokes.

Empty states: explain purpose and give one action. What this is, why it matters, how to start.

Tooltips: if a tooltip explains a basic control, redesign the control and remove the tooltip.

Quick audit (30 minutes)

Collect 10 instances of hedging words: maybe, just, a bit, looks like, might, heads up, should, kinda.
Score each message for: a) fact stated, b) outcome stated, c) single next step offered.
Rewrite anything that misses two or more.
Swap CTAs from tasks to outcomes across the top three flows.
Move proof (stat, benchmark, logo) to decision points.

Ship the first five changes today. Measure for a week.

What to measure

Task completion rate on key flows
Time to first value for new users
Error recovery time (from failure to successful retry)
Form completion on checkout/onboarding
Support themes: drop in “confusing/unsure” mentions

Clarity should reduce reading time and retries. If it doesn’t, your issue isn’t tone—it’s flow.

When soft language is appropriate

Sensitive contexts: health, safety, bereavement—be humane, not evasive.
True uncertainty: communicate it precisely (“We’ll confirm in 10–15 minutes. We’ll email you either way.”) Uncertainty is not hedging when time bounds and next steps are explicit.
Brand moments: marketing pages can earn playfulness; core actions cannot.

For larger teams

Tone often degrades in review loops. Protect it with:

A source-of-truth voice doc with examples for errors, empty states, and CTAs
Ownership: someone accountable for UX design writing across flows
Banned list: words/phrases you won’t ship (maybe, just a sec, feel free…)
PR checklist: C-I-A-R applied to any new error/loading text

Legal can shape claims; it should not own product voice. If the UI handles chargebacks, deletions, or limits, it must speak with precision.

Field notes (before → after)

“We’re sorry, something’s not quite right.” → “Service unavailable. We’ll retry in 2 minutes or you can refresh now.”
“Click here to continue when you’re ready :)” → “Continue to billing.”
“You’re almost there!” (step 3/6) → “Step 3 of 6: Company details.”
“Let’s go!” on delete → “Delete account.”

Small changes; large perceived competence.

Bottom line

Soft is fine. Vague is not. If your product never states facts or next steps, it isn’t polite—it’s indecisive. Write like an adult who knows what happens next. Say the thing.

Warm + direct. Facts + outcomes. One next step.

Product UI Tone & Clarity Guidelines

Tanya Donska — Tue, 19 Aug 2025 10:05:50 +0000

Purpose
Set a clear, repeatable standard for interface language that builds trust and speeds decisions. These guidelines replace vague, overly polite copy with factual, outcome‑oriented language.

Scope
Applies to all in‑product text: labels, buttons, messages, empty states, error and waiting states, forms, settings, and destructive actions. Covers web and mobile. Marketing site copy is out of scope unless it appears inside the product shell.

⸻

Guiding Principles

1.  Clarity over friendliness – Kindness is welcome; vagueness is not.
2.  Facts first – State what happened or will happen, then add context.
3.  Name the object – Use precise nouns (workspace, invoice, report), not this/it.
4.  One action, one escape – Present a primary next step and a safe cancel/close.
5.  Truthful time and risk – No optimistic time claims or euphemisms for destructive actions.
6.  Consistency – Use the same terms for the same things everywhere.

⸻

Language Standards

Tone
Neutral‑confident by default. Warm for success/guidance. Firm for money, permissions, security, outages, and deletion.

Voice
• Active voice, present tense.
• Second person sparingly (you/your) when it reduces ambiguity.
• Sentence length target ≤ 14 words.

Format
• Dates: 12 June 2025.
• Times: 24‑hour clock (e.g., 09:00–18:00).
• Numerals: use digits for 2+; words for one where natural.
• Use sentence case for UI text unless a component demands otherwise.

Banned / Discouraged Hedges
might, maybe, looks like, a bit, usually, just, probably, hopefully, just a sec, almost there, feel free, something’s not quite right.

Preferred Constructions
• We couldn’t save… (what failed)
• Still processing (10–20s). You can… (truthful wait)
• Delete workspace now? This removes… (explicit risk)
• Connect data → See your cost breakdown (outcome‑first CTA)

⸻

Pattern Library

Error

Rule: Say what failed; why (if known); what to do next.
Template:

. . or .

Example: Export failed. The file is too large. Try a smaller range or email support.

Destructive Action

Rule: Name the action, consequence, and undo policy. Provide clear primary and cancel.
Template:

now? . . |

Example: Delete workspace now? This removes all members. You can restore within 7 days. Delete | Cancel.

Waiting State

Rule: State status, truthful timeframe, and what the user can do.
Template:

in progress (). .

Example: Preparing your report (10–20s). You can close this tab; we’ll notify you.

Empty State

Rule: Explain purpose, why it matters, one next action.
Template:

. . .

Example: Cohorts compare behaviour over time to find growth drivers. Create your first cohort.

CTA (Buttons & Links)

Rule: Express outcomes, not tasks. Avoid cheerleading.
Formula: Do X → Get Y.
Examples: Connect Stripe → See MRR · Generate report → View results.

⸻

Anti‑Patterns (do not ship)

• Hedged errors: “Oops! Something might’ve gone wrong.”

Use: We couldn’t save your changes. Try again or reload.
• Time lies: “Just a sec…” shown for > 5s.
Use: Training model (3–5 min). We’ll email you when it’s ready.
• Motivational CTAs: “Let’s go!” for destructive actions.
Use: Delete account.
• Vague warnings: “You’ll lose some data.”
Use: Cancelling now removes access to historical reports.
• Unnamed objects: “Click here to continue when you’re ready.”
Use: Continue – your settings save on the next step.

⸻

Naming & Navigation

• Each top‑level nav item must be explainable in ≤ 2 sentences.
• Prefer user language over internal terminology.
• Align in‑product section names with the website’s value proposition where appropriate.

⸻

Review & Governance

Tone Guardrail (one‑pager)
• List banned hedges and danger words.
• Time claims policy (ranges, thresholds for spinners vs. progress bars).
• Destructive actions wording standards (risk + undo window).

Copy PR
Every UI change with text includes:
• Before and After copy.
• Rationale linked to these guidelines.
• Owner sign‑off (Product) and, where needed, Legal/Compliance.

Ownership Table
Screen/component → Job‑to‑be‑done → Copy owner → Last updated.

⸻

Accessibility & Inclusion
• Avoid idioms and cultural references.
• Write for screen readers: meaningful labels, announce state changes.
• Keep reading level clear; prefer common words over jargon.
• Ensure error messages can be perceived and recovered from without colour alone.

⸻

Measurement

Track for two weeks after notable copy changes:
• Task success: completion rate/time on top flows.
• Error recovery: % of users who retry and succeed.
• Support load: tickets per 1,000 users on affected surfaces.
• Conversion: CTA CTR; paywall completion.
• Activation: % reaching first value within 24 hours.

Success criteria: directional improvement on ≥ 3 metrics, or a strong lift on one priority metric.

⸻

Change Control & Versioning
• Version these guidelines quarterly or when product scope shifts.
• Archive deprecated patterns; replace examples across the design system.

⸻

Quick Checklist (pin this in Figma)
• Facts before feelings
• Named objects, not this/it
• One action, one escape
• True time, true risk
• Decision‑adjacent proof when confidence matters
• Firm tone for money/permissions/deletion/outages
• Copy PR attached and owner signed off