# DNSK WORK > DNSK WORK is a London-based UX/UI design studio helping scaling SaaS companies and product teams improve UX, ship faster, and reduce design debt — without hiring full-time. DNSK WORK designs SaaS UX that holds under pressure — and the UI design systems that go with it. Our work covers real digital products: internal tools, B2B SaaS flows, platforms, and dashboards that don’t stop growing. We also create marketing assets to support product launches when they're ready. --- ## Posts - [Why Most SaaS Website Design Is Lying Without Docs](https://dnsk.work/blog/why-most-saas-website-design-is-lying-without-docs/): Docs are presales. If they’re thin or hidden, your saas website is unfinished. In saas website design, docs and changelog... - [Landing Pages Fail When They Look Good but Load Slow](https://dnsk.work/blog/landing-pages-fail-when-they-look-good-but-load-slow/): Slow pages don’t just annoy people; they change their minds. A landing page isn’t a gallery. It’s a decision surface... - [Design Is the Hard Part. AI Is the Helpful Part.](https://dnsk.work/blog/design-is-the-hard-part-ai-is-the-helpful-part/): Good UX is deciding what matters, in what order, for whom, under constraints you don’t control. That’s the job. AI... - [The Ultimate Design Package Alternative for Proven ROI](https://dnsk.work/blog/the-ultimate-design-package-alternative-for-proven-roi/): I’ve lost count of the founders who’ve come to me after buying a “starter” or “small business” website design package.... - [How to Audit Your UX in 15 Minutes: The Brutally Honest Sanity Check](https://dnsk.work/blog/how-to-audit-your-ux-in-15-minutes-the-brutally-honest-sanity-check/): Most UX audits are long, expensive, and full of beautifully formatted reports you’ll never read twice. This isn’t that. This... - [The Painful Truth About UX/UI Debt – and the Essential Fixes to Start Now](https://dnsk.work/blog/the-painful-truth-about-ux-ui-debt-and-the-essential-fixes-to-start-now/): Every product accumulates UX/UI debt — cluttered flows, unloved screens, ghost features no one uses but everyone’s scared to remove.... - [How to Save Time and Money With a UI/UX Design Partner That Delivers](https://dnsk.work/blog/how-to-save-time-and-money-with-a-ui-ux-design-partner-that-delivers/): Founders love hiring. It feels like progress. A full-time designer on payroll? That must mean you’re a real startup now.... - [UI/UX Design and Development That Developers Actually Love](https://dnsk.work/blog/ui-ux-design-and-development-that-developers-actually-love/): If you’ve ever opened a Figma file and wondered whether the designer actually met a developer in their life, this... - [Exposing UI/UX Design Myths – What Real Design Should Look Like](https://dnsk.work/blog/exposing-ui-ux-design-myths-what-real-design-should-look-like/): Quick story before we start. A few years ago, a startup hired a “top-tier” agency for a full UI/UX overhaul.... - [The Truth About Website Development for Startups (It’s Not What You Think)](https://dnsk.work/blog/the-truth-about-website-development-for-startups-its-not-what-you-think/): If you need to message a developer to fix a typo on your homepage, your startup website is already failing... - [We’ll Just Do a Quick Design Audit” (Famous Last Words)](https://dnsk.work/blog/well-just-do-a-quick-design-audit-famous-last-words/): This post isn’t just a rant — though there will be ranting. It’s a spoiler for every team that’s ever... - [You Hired a UI/UX Designer. Now Let Them Do Their Job](https://dnsk.work/blog/hire-ui-ux-designer-trust-process/): This post isn’t a polite reminder. It’s a cautionary tale. A reflection, really — on every well-funded, well-intentioned product team... - [Conceptual Design Isn’t Just a Moodboard — It’s Your Product’s First Strategy Test](https://dnsk.work/blog/conceptual-design-isnt-just-a-moodboard-its-your-products-first-strategy-test/): Conceptual design isn’t your brand’s Pinterest board. It’s the first brutal stress test your product will ever face. Most teams... - [Great UI/UX Design Services Don’t Just Design. They Diagnose and Transform.](https://dnsk.work/blog/great-ui-ux-design-services-dont-just-design-they-diagnose-and-transform/): After seeing enough design proposals crash and burn, you learn one thing: most clients don’t want a diagnosis, they want... - [How to Write a Design RFP That Doesn’t Waste Everyone’s Time](https://dnsk.work/blog/how-to-write-a-design-rfp-that-doesnt-waste-everyones-time/): Design RFPs have a reputation — and not a flattering one. Speaking as someone who’s spent years inside big design... - [Why “All-in-One” Products Fail (And What Users Really Want)](https://dnsk.work/blog/why-all-in-one-products-fail-and-what-users-really-want/): This post is a reflection of my experience working as a UX consultant and Creative Director for a large, well-known... - [Your Product’s Empty States Are More Important Than You Think](https://dnsk.work/blog/your-products-empty-states-are-more-important-than-you-think/): When teams plan new features, they obsess over happy paths: full dashboards, populated lists, satisfying graphs. But the one state... - [What Startup Websites Get Wrong (And How to Fix It in 8 Seconds)](https://dnsk.work/blog/what-startup-websites-get-wrong-and-how-to-fix-it-in-8-seconds/): There’s a quiet crisis in startup web design. Too many teams have traded clarity for theatre. Instead of sites that... - [How to Write Product Copy Users Actually Trust](https://dnsk.work/blog/how-to-write-product-copy-users-actually-trust/): There’s a reason your product copy reads like it was written by a sentient HR policy. It probably was. Not... - [How One Button Teaches Users to Ignore You](https://dnsk.work/blog/how-one-button-teaches-users-to-ignore-you/): It sounds harmless. Polite, even. “Maybe Later” — the soft opt-out on your modal, onboarding flow, or product tour. A... - [The Small UX Fixes That Make the Whole Thing Feel Better](https://dnsk.work/blog/ux-reset-checklist/): You’ve been moving fast. The roadmap’s alive. Features shipped, launches announced, maybe even a few investors impressed. But now the... - [Your Product Isn’t Too Complex – It’s Just Not Modular Yet](https://dnsk.work/blog/not-too-complex-just-not-modular/): When founders or product heads describe their product as “complex,” they rarely mean the business logic. They usually mean the... - [Why SaaS Pricing Pages Fail (And How to Fix Yours)](https://dnsk.work/blog/pricing-page-redesign/): There’s one part of a SaaS product that’s both incredibly revealing and tragically underdesigned: The pricing page. It’s where value... - [Stop Building Features No One Can Find](https://dnsk.work/blog/stop-building-hidden-features/): You built something useful. You shipped it fast. Maybe you even ran a tidy launch thread on LinkedIn. And now...... - [When Your Settings Page Becomes the Product](https://dnsk.work/blog/wall-of-settings/): If your settings page is longer than your actual product, you’re not giving users freedom – you’re handing them your... - [Who Are You Designing For — Really?](https://dnsk.work/blog/who-are-you-designing-for/): A team in mid-sprint, tired but caffeinated. You’re in Figma or Slack or Notion, staring at a half-finished flow someone... - [The UX Mistake That Makes You Sound Unsure](https://dnsk.work/blog/politeness-problem/): Your product is nice. Too nice. Everything says “maybe. ” Every modal wants to know if it’s a good time.... - [Your Product Doesn’t Need a Redesign — It Needs a Reckoning](https://dnsk.work/blog/ui-audit-reckoning/): Your product works. Mostly. The flows are familiar. The nav still kind of makes sense. Nothing’s technically broken. And yet,... - [The First Version Is Supposed to Be Awkward](https://dnsk.work/blog/mvp-first-version/): You know the one. The MVP built by a freelancer over a long weekend, styled with inline CSS, powered by... - [Why Silence Isn’t Feedback — It’s the Exit Sign](https://dnsk.work/blog/silence-feedback/): The feature shipped. The onboarding was polished. The numbers looked fine. And then... nothing. No tickets. No replies. No praise.... - [When You Click — and Nothing Happens: UX’s Quietest Failure](https://dnsk.work/blog/this-button-does-nothing/): Every designer, at some point, ships a button that doesn’t work. Maybe it launches a spinner that spins forever. Maybe... - [Fake Persona Testing: The UX Exercise That Actually Works](https://dnsk.work/blog/fake-persona-test/): Most of your product’s worst UX failures won’t show up in analytics. They’ll show up in a support ticket from... - [Redesigning Other People’s Work Made Us Weirdly Better at Ours](https://dnsk.work/blog/redesigning-without-permission/): This isn’t a pitch. It’s not a teardown. And it’s definitely not for clout. It’s a reflex. A twitch in... - [Startups We Admire (and Would Love to Design For)](https://dnsk.work/blog/startups-we-admire/): We built a tool. That’s it. That’s the post. Okay, not quite. But yes — https://curated. dnsk. work is just... - [How Top-Down UX Design Breaks Teams, Products, and Trust](https://dnsk.work/blog/dont-design-like-pharaoh/): What happens when product teams try to control everything — and what real leadership in UX looks like. The final... - [Why UX Design Should Free, Not Control](https://dnsk.work/blog/designing-for-liberation/): What the Exodus Can Teach Us About Breaking UX Slavery Patterns We’re deep into Pesach season. A time of freedom.... - [How to Build a UX Portfolio That Gets You Hired](https://dnsk.work/blog/lets-not-build-portfolios-for-algorithms/): Not Everything Needs a CTA We’ve all seen them. The clean, confident LinkedIn posts that promise to fix your design... - [Why I Stopped Sounding Like Every Other Designer on LinkedIn](https://dnsk.work/blog/linkedin-update-post/): Award-winning. Passionate. Strategic. Driven. You’ve read that sentence before — probably on my old LinkedIn profile. It wasn’t a lie.... - [Hello World](https://dnsk.work/blog/hello-world/): Why We Built Our Blog on Hugo We finally launched our blog. Not because we had to. Not for SEO.... --- # # Detailed Content ## Posts - Published: 2025-08-28 - Modified: 2025-08-28 - URL: https://dnsk.work/blog/why-most-saas-website-design-is-lying-without-docs/ Docs are presales. If they’re thin or hidden, your saas website is unfinished. In saas website design, docs and changelog are part of the product, not the footer. Here’s a simple truth most "marketing" Saas websites ignore: high‑intent visitors don’t believe headlines — they believe documentation. If I’m a CTO, a staff engineer, or a security‑minded buyer, I will glance at your homepage and then click straight to Docs, API, or Changelog. That’s the real tour. If those pages are thin, dated or hidden, your “website” is unfinished. This is what grown-up saas website design looks like. It’s a plea for product truth. Great saas website design treats docs and the changelog as first‑class citizens: discoverable from the homepage, written for presales as much as for support, and kept alive with a steady drumbeat of visible progress. If your current saas website design agency can’t talk about documentation strategy, you’ve hired decorators. Nothing wrong with decorators — unless you want sign‑ups and sales. Docs are Saas Website presales Serious buyers skim the homepage, then judge you in docs. Docs are where serious visitors check three things: What it does (for real). Capabilities with enough detail to be credible. Not “AI‑powered”, but endpoints, limits, and examples. Where it breaks. Quotas, timeouts, rate limits, data residency, supported browsers, language SDKs, and “we don’t do X yet”. Honesty converts. How long it will take. The “first hour” test: is there a copy‑paste quick start that runs without a committee meeting? If the homepage... --- - Published: 2025-08-26 - Modified: 2025-08-26 - URL: https://dnsk.work/blog/landing-pages-fail-when-they-look-good-but-load-slow/ Slow pages don’t just annoy people; they change their minds. A landing page isn’t a gallery. It’s a decision surface with a clock running in the background. Every extra 200ms is a chance for doubt to creep in, for a tab to steal attention, for a calendar reminder to win. Speed is UX. Treat it like a feature with a budget, not a line item for QA to “optimise later”. And if your landing page design agency can’t talk in budgets and trade‑offs, you’re buying decoration, not outcomes. The UX Audit bit (not just Core Web Vitals) Momentum is trust. Fast pages feel competent; slow pages feel risky. Users won’t say this aloud—your bounce rate will say it for them. Latency creates micro‑decisions. Every pause is a chance to reconsider. Remove pauses, remove exits. Perception beats perfection. Skeletons beat spinners. Progressive reveal beats “loading... ”. Optimistic UI feels kinder than anxious UI. Stop the thinking tax. Fewer fonts, fewer motion gizmos, fewer layout jumps (CLS). Simpler is easier to parse and faster to ship. Truthful motion. Animation should explain change, not conceal lag. Sub‑200ms transitions unless there’s a real narrative reason. The Landing Page Budget (without adding UX debt) Speed is not a polish pass. It’s part of the promise. Keep it, or users won’t keep reading. Publish this before you design anything. Then defend it like a product requirement. TTFB < 200ms (edge hosting/CDN) LCP < 2. 5s on mobile INP < 200ms, CLS < 0. 1 Critical above‑the‑fold... --- - Published: 2025-08-19 - Modified: 2025-08-19 - URL: https://dnsk.work/blog/design-is-the-hard-part-ai-is-the-helpful-part/ Good UX is deciding what matters, in what order, for whom, under constraints you don’t control. That’s the job. AI in UX can help, but it doesn’t do the deciding. Think of it as a tireless junior: fast, keen, occasionally delusional. Useful, supervised. I’m not anti‑AI; I’m anti‑theatre. I use AI in UX design every week, but never to replace judgement. Here’s how I actually use it, where I won’t, and why UX work still matters even as every second product claims to be “AI‑powered”. UX is about choices, not pixels UX isn’t pixels. It’s priority. It’s trade‑offs. It’s choosing what not to ship. Most of my day is spent saying no: no to yet another step in onboarding, no to a clever animation that hides a slow query, no to five versions of the same CTA with different adjectives. Users don’t care how much effort you put in. They care that it works and they understand what to do next. In AI UX design, the real interface is uncertainty. Models are probabilistic; they guess. Your job is not to pretend certainty. Your job is to make uncertainty usable: show confidence (without drama), admit failure (without shame), and give people a fast way to correct the system without losing their work. That is product design, not press‑release design. Where AI UX helps — so I can think I don’t ask a model to be my creative director. I ask it to remove friction so I can get to the decisions... --- - Published: 2025-08-14 - Modified: 2025-08-14 - URL: https://dnsk.work/blog/the-ultimate-design-package-alternative-for-proven-roi/ I’ve lost count of the founders who’ve come to me after buying a “starter” or “small business” website design package. Same story every time: a tidy PDF proposal, a fixed number of pages, a timeline that fits neatly into a calendar, and a site that looks vaguely competent but somehow does nothing. Pretty. Punctual. Pointless. Packages are procurement theatre. They optimise for deliverables, not outcomes. And if you’re measuring progress by how many pages you’ve bought, rather than whether anyone understands what you do or actually buys it, you’re optimising the wrong thing. Anyway. I’m Tanya. I lead UI/UX work for early-stage and growth-stage teams, and I’m allergic to waste. Here’s what years of fixing package-shaped websites taught me. Fixed scope ≠ fit Every business is weird. Your audience, your message, your funnel, your operational reality — all messy in their own special way. Web design packages pretend none of that exists. You get “five pages + blog + contact form,” as if the shape of your site can be decided before we even talk about your users. Personal example: a B2B SaaS team hired me after a package build. They had the full line-up — Home, Features, Pricing, Blog, Contact — and a conversion rate hovering around ‘why are we doing this’. Their product didn’t fit the choreography. Prospects needed a detailed demo first, not a self-serve trial. We threw out half the pages and rebuilt around a single flow: problem → proof → book a walkthrough. Same content, different shape.... --- - Published: 2025-08-12 - Modified: 2025-08-12 - URL: https://dnsk.work/blog/how-to-audit-your-ux-in-15-minutes-the-brutally-honest-sanity-check/ Most UX audits are long, expensive, and full of beautifully formatted reports you’ll never read twice. This isn’t that. This is the UX sanity check — the quick-and-dirty, seven-question sweep I use when I want to know if a product is healthy enough to survive the week. It’s not a replacement for a proper deep-dive audit, but it’s a great way to find the obvious leaks before they sink you. And yes — you can actually do this in less than 15 minutes. No post-its. No mood boards. No design thinking theatre. Why Bother With a 15-Minute UX Audit? Because most teams wait until things are on fire before asking, Hey, should we maybe check if users can actually use this? By then, you’re already hemorrhaging conversions, support tickets are piling up, and your developers are quietly updating their LinkedIn profiles. A quick UX sanity check gives you: Immediate insight into where you’re losing users A prioritised list of fixes (without the analysis paralysis) The ability to stop making the same mistakes on new features If you pass all 7 checks, you can sleep a little easier. If you fail more than 2... well, we should probably talk. The 7-Point UX Sanity Check Each of these takes 2 minutes or less. Yes, really. 1. Can a First-Time User Get to Value in 3 Clicks or Less? If it takes 12 steps, 4 forms, and a welcome video to get someone to the thing they signed up for, you’ve lost them.... --- - Published: 2025-08-07 - Modified: 2025-08-07 - URL: https://dnsk.work/blog/the-painful-truth-about-ux-ui-debt-and-the-essential-fixes-to-start-now/ Every product accumulates UX/UI debt — cluttered flows, unloved screens, ghost features no one uses but everyone’s scared to remove. But here’s the catch: fixing everything at once isn’t just unrealistic, it’s usually a massive waste of time. You don’t need a redesign. You need a triage plan. We once audited a SaaS dashboard so overloaded with icons, tooltips, and leftover design system fragments, it looked like someone had sneezed components all over the canvas. A mess, sure. But guess what? None of it was what users were complaining about. So we left it alone — for now. The Real Cost of UX/UI Debt UX/UI debt isn’t about things looking a bit off. It’s about pain: Broken flows that lead to customer support tickets Bad onboarding that quietly kills conversion Inaccessible UIs that open legal doors you don’t want opened Unclear CTAs that lose you revenue every single day Some of this is annoying. Some of it is lethal. Here's a quick sniff test. UX/UI debt is expensive when it: Confuses first-time users Forces internal workarounds Breaks across devices Creates friction in core money-making flows Gets reported more than once a week Everything else? It can probably wait. A Brutally Simple Prioritization Framework Let’s stop pretending all UX problems are equal. Here’s a framework I use with clients to figure out what’s actually worth fixing — now vs. later. Tier 1: Survival-Level Problems The stuff that hurts your product today. Users get stuck or abandon core flows Conversions are tanking... --- - Published: 2025-08-05 - Modified: 2025-08-05 - URL: https://dnsk.work/blog/how-to-save-time-and-money-with-a-ui-ux-design-partner-that-delivers/ Founders love hiring. It feels like progress. A full-time designer on payroll? That must mean you’re a real startup now. Except... most of the time, that hire ends up babysitting a Figma file for three months while the product spec changes fifteen times and your runway quietly dies. Here’s the truth: you don’t need a full-time designer. You need a senior UI/UX design partner who actually works like your business depends on it. The Problem With the Full-Time Fantasy Startups love the idea of owning things. Their stack. Their roadmap. Their team. But hiring a full-time designer too early is like putting marble countertops in a kitchen that doesn’t have walls yet. What usually happens: The product isn’t validated. The roadmap is murky. The designer becomes a glorified slide monkey or landing page re-sizer. I once had a founder (Hey, J! ) tell me they were "bored" of their designer after two weeks because they ran out of things to assign. And let’s be honest — unless you’re pushing major design iterations weekly (and have real product-market fit), a full-time hire will be: UnderutilisedOverpaidBored to death So what’s the alternative? What a UI/UX Design Partner Actually Does A proper UI/UX design partner isn’t waiting around for tasks. They’re embedded. Adaptive. Strategic. They shape what needs designing, not just decorate it. Let me give you an example: A client of mine needed a booking flow redesigned. But once I dug into it, it turned out they didn’t even need a booking... --- - Published: 2025-07-31 - Modified: 2025-07-31 - URL: https://dnsk.work/blog/ui-ux-design-and-development-that-developers-actually-love/ If you've ever opened a Figma file and wondered whether the designer actually met a developer in their life, this post is for you. Most of the time, "UI/UX design and development services" are treated like a relay race — design runs a few laps, then throws a bloated figma file over the wall and hopes for the best. Except real product work isn't a relay. It's more like a tightrope walk across a flaming pit — and someone forgot the rope. The Problem With the Pretty Figma File Pixel-perfect mockups. Smooth interactions. Sleek components. And then... no dev can build it. Or they try, and the whole product turns into a spaghetti mess of inconsistencies and guesswork. I've been on the receiving end. I've had to fix them. And I’ve watched teams burn two months trying to make sense of a handoff that included three design systems and zero developer notes. UI UX design and development should be a handshake, not a handoff. Yet so many teams treat it like two separate planets. One shiny. One functional. Rarely aligned. Why Most UI/UX Work Breaks at Handoff Let’s break down a few red flags: 1. Design Systems Built for Behance, Not Web Developers It looks amazing in the showcase. But under the hood? Variants nested inside variants, with spacing rules that collapse the minute you resize anything. No naming conventions. No token logic. Just vibes. I once inherited a file where every button was a unique component. Thirty buttons. Same... --- - Published: 2025-07-29 - Modified: 2025-07-29 - URL: https://dnsk.work/blog/exposing-ui-ux-design-myths-what-real-design-should-look-like/ Quick story before we start. A few years ago, a startup hired a “top-tier” agency for a full UI/UX overhaul. Six weeks and a slick deck later, they launched. Two weeks after that, they were back — asking why their users still didn’t understand the product, why the bounce rate hadn’t changed, and why devs were filing support tickets just to make sense of the flows. That’s when I got involved. What I found was equal parts depressing and predictable. And that’s where this post really begins. Most agencies sell UI/UX design services the way fast food joints sell meal deals — predictable, templated, and guaranteed to leave you wondering why you're still hungry. I’ve worked inside those setups. I’ve inherited their Figma files. And I’ve had to fix what they left behind. So this post isn’t a polite industry critique. It’s a painfully honest reflection on what real UI/UX design services look like, and why so many clients have been trained to expect far less. The Red Flags I See Too Often Let’s start with three usual suspects. If you’ve been on the receiving end of UI/UX services, these might feel disturbingly familiar: 1. Template-Led Thinking “Here’s your homepage, based on the same layout we used for that fintech app last week. ” You know the vibe. Everything looks slick, but nothing quite fits. The grid’s perfect, but the messaging’s vague. I’ve seen startup websites where the only truly unique element was the logo — and even that was... --- - Published: 2025-07-24 - Modified: 2025-07-24 - URL: https://dnsk.work/blog/the-truth-about-website-development-for-startups-its-not-what-you-think/ If you need to message a developer to fix a typo on your homepage, your startup website is already failing you. It’s 2025. You're a startup. You’re iterating fast, tweaking your pitch, updating your messaging weekly (or hourly). But your website? That’s frozen in time — a glossy WordPress monolith guarded by an agency, a dev, or some mysterious “guy from Upwork. ” This post is for every founder who's stared at their own site and thought: "Why can’t I just change this? " Spoiler: you can. And you should. If your website isn’t something you can control and evolve easily, then it’s not a startup asset — it’s a liability. The Developer Bottleneck Is Real (and Dumb) We’ve worked with startups backed by top-tier VCs. Smart teams. Bold ideas. But you’d be shocked how often their websites are stitched together with inflexible CMS setups, half-documented custom code, or completely opaque dev handovers. Their “simple marketing site” ends up requiring: GitHub access Custom component updates Manual deploys All for what? Changing a headline? You don’t need engineering resources to update your About page. Or swap a testimonial. Or launch a landing page. You just need a better stack. Do a quick search on Framer — it’s become the go-to approach when it comes to website development for startups. Why Framer (Actually) Works Framer isn’t a toy. It’s not just for pretty animations. It’s a production-ready, founder-friendly tool that lets you build, edit, and launch genuinely fast — without sacrificing polish... --- - Published: 2025-07-22 - Modified: 2025-07-22 - URL: https://dnsk.work/blog/well-just-do-a-quick-design-audit-famous-last-words/ This post isn’t just a rant — though there will be ranting. It’s a spoiler for every team that’s ever said: “Let’s just do a quick design audit” with the same energy as someone saying “I’ll just Google the symptoms. ” So, you’re staring down sluggish conversion numbers, vague user complaints, or an executive Slack message saying: “The product feels... off. ” Suddenly, someone suggests the magic cure-all: the ‘quick design audit. ’ It sounds practical. Low-lift. Almost responsible. It rarely is. Here’s the usual setup: The product’s live. Things are kind of working. But conversions are sluggish. Users are confused. Feedback is inconsistent. So someone (usually in marketing or product) floats the magic phrase: “Let’s do a quick design audit — just to check for obvious stuff. ” By “obvious,” they mean: spacing inconsistencies, button colours, maybe a weird font size here and there. By “quick,” they mean “can you do it by Thursday. ” WHAT THEY EXPECT: A neat little report. A tidy list of UI tweaks. Maybe some “low-hanging fruit. ” Something they can forward in an email thread with the subject line: ‘Insights! ’ WHAT THEY GET (if it’s done right): A full-blown intervention. Not a vibe check. A product-wide reality check. And it rarely fits in a tidy PDF. What a Real Design Audit Involves A proper design audit isn’t about judging your typography alignment from a pedestal. It’s about exposing where your product’s design is lying to you. Where it pretends to be working... --- - Published: 2025-07-18 - Modified: 2025-07-18 - URL: https://dnsk.work/blog/hire-ui-ux-designer-trust-process/ This post isn’t a polite reminder. It’s a cautionary tale. A reflection, really — on every well-funded, well-intentioned product team that hired UI/UX designers... and then slowly suffocated them in a pile of Slack threads, Notion checklists, and “just a quick thought” Figma comments. Let’s call it what it is: pixel micromanagement with a smile. The invisible hand (that ruins everything) Somewhere around week three, you start feeling itchy. You know the work is progressing. The flows are being shaped. But your product’s future is sitting inside a Figma file, and your inner control freak starts asking questions like: “What if the CTA was blue instead of black? ” “Can we add a third variant for this? ” “I know this wasn’t scoped, but we should probably rethink onboarding too. ” By week five, it’s full-blown panic seasoning: adding more screens, injecting new features mid-sprint, questioning every label, and scheduling emergency calls because your co-founder’s cousin said the dropdown “feels off. ” This isn’t collaboration. This is what happens when people get nervous and try to Photoshop their way out of strategic uncertainty. From a freqently hired UI/UX Designer We once worked with a startup — Series A, slick branding, investors with podcasts. They brought us in to “rethink the UX holistically. ” (Their words. ) Week 1: Alignment sessions, clear goals, promising start. Week 2: We share core flows. Quiet optimism. Week 3: Their CEO sends us a 27-minute Loom (really? ) critiquing icon choices “from a narrative perspective. ”... --- - Published: 2025-07-15 - Modified: 2025-07-15 - URL: https://dnsk.work/blog/conceptual-design-isnt-just-a-moodboard-its-your-products-first-strategy-test/ Conceptual design isn’t your brand’s Pinterest board. It’s the first brutal stress test your product will ever face. Most teams treat it like a chance to pick some fonts, shuffle a few colours, and pat themselves on the back for being “visionary. ” But that’s exactly how you end up with a pretty coffin for a dead product. More than surface-level decoration Conceptual design isn’t about vibes. It’s about proving whether your big idea can stand up before you waste months (and entire budgets) making it pretty. It asks the real questions no one wants to touch: Does this actually solve anything? Do people understand it in five seconds? Or are you decorating an empty promise? Conceptual design is like the ugly prototype garage phase before the big car show reveal. It’s messy, unglamorous, and absolutely essential. You don’t skip the garage just because you’re impatient to show off the shiny exterior. I once worked with a well-established (American, off course) 'startup' that came in hot with a $250k brand book, an army of marketing consultants, and a pre-approved UI kit they believed would “revolutionise the space. ” They had moodboards for days, shiny mockups, and brand slogans that could make a poet gag. But after all that noise? Users still didn’t understand what the product actually did. Conversion rates were flatlining, and churn looked like a ski slope in January. When I finally dragged them (kicking and screaming) back into conceptual design, we discovered the core flow was an... --- - Published: 2025-07-10 - Modified: 2025-07-10 - URL: https://dnsk.work/blog/great-ui-ux-design-services-dont-just-design-they-diagnose-and-transform/ After seeing enough design proposals crash and burn, you learn one thing: most clients don’t want a diagnosis, they want a quick fix — and it shows. When some new clients approach our UI/UX design services, they often treat them like a tidy takeaway menu: “We’ll grab a couple of wireframes, throw in a quick prototype, maybe sprinkle in a usability test. ” It might feel efficient and controlled — but this mindset is deeply flawed. UX isn’t a collection of à la carte items you casually select. It’s a diagnosis-first practice, grounded in investigation and honesty. You don’t walk into a doctor’s office asking for an MRI and three specific pills because you Googled your symptoms. You describe your pain, they investigate, and then they decide on the treatment. It’s the same with real UX design services. The danger of shopping-list thinking I once worked with a fast-growing SaaS company as a part-time Creative Director that insisted on a fixed “gold package” as a part of design bundle other company pitched them — shiny dashboards, re-skinned interfaces, and a few quick usability tests. After launch, churn stayed exactly the same, and users still didn’t understand the core value proposition. They had spent months (and a small fortune TBH) on screens that looked beautiful but solved nothing. That’s the real danger. So, when you approach UX as a list of deliverables, you skip the actual hard thinking: the discovery, the root-cause analysis, the messy user truths. You might get beautiful... --- - Published: 2025-07-08 - Modified: 2025-07-10 - URL: https://dnsk.work/blog/how-to-write-a-design-rfp-that-doesnt-waste-everyones-time/ Design RFPs have a reputation — and not a flattering one. Speaking as someone who’s spent years inside big design teams and consulting for large product organisations, I can say this bluntly: most RFPs are a mess. They reveal more about a company’s internal politics than their actual design goals. They’re often contradictory, stuffed with self-important brand jargon, and read like a therapy session no one asked for. This isn’t theoretical — it’s firsthand, bruised-by-experience reflection. I’ve seen talented, well-funded teams paralyse themselves with 25-page documents no one actually reads. I’ve watched great design partners quietly walk away from promising clients because the design RFP hinted at chaos. Writing a good RFP isn’t just polite; it’s the first signal you understand design as a serious, strategic investment — not just a slide deck flourish. Here’s how to create one that is actually informative, respectful, and — dare I say — useful. Stop treating your RFP like a treasure map Many RFPs read like you’re hiding the real problem behind vague hints and poetic slogans. They’re full of abstract aspirations — “We want to disrupt the space,” “We’re looking for a partner who can channel our innovative DNA” — instead of clear problems to solve. Instead of outlining business goals or explaining what’s broken, they bury details under endless slides and metaphor-heavy mood boards. Design partners shouldn’t have to decipher cryptic “vibes,” decode brand mantras, or guess priorities by reading between the lines. Your design RFP isn’t a test of psychic... --- - Published: 2025-07-03 - Modified: 2025-07-07 - URL: https://dnsk.work/blog/why-all-in-one-products-fail-and-what-users-really-want/ This post is a reflection of my experience working as a UX consultant and Creative Director for a large, well-known product team — big budget, big ambitions, and genuinely talented people. I liked the work, respected the team, but saw firsthand how the "all-in-one" temptation leads to scattered focus and diluted impact. This isn’t armchair critique — it’s a lived observation from inside the beast. Why “all-in-one” seduces founders and investors “All-in-one. ” It sounds efficient, intelligent, maybe even futuristic. In reality? You’re usually buying a bloated toolbox full of half-broken gadgets that look good in a pitch deck but fail in daily use. The pitch is irresistible: simpler stacks, single billing, more cross-sell opportunities, higher valuations. Founders imagine capturing every possible workflow under one roof, while investors dream of infinite upsell ladders. It feels like a shortcut to category dominance. But the promise is a mirage — what looks like a golden strategy on slides often becomes an execution nightmare in real life. These pitches usually focus on potential market size instead of real user pain. They prioritise breadth over depth, mistaking optional add-ons for meaningful solutions. The result? A product that checks boxes for everyone but truly satisfies no one. How feature bloat kills focus (and user trust) Every new feature added to an all-in-one product is another leak in the focus bucket. Instead of doubling down on solving one core problem brilliantly, teams spread thin across shallow add-ons. Support teams struggle to answer endless edge cases. Engineers... --- - Published: 2025-07-01 - Modified: 2025-07-01 - URL: https://dnsk.work/blog/your-products-empty-states-are-more-important-than-you-think/ When teams plan new features, they obsess over happy paths: full dashboards, populated lists, satisfying graphs. But the one state that usually gets the least love? The empty state. Empty states aren’t just placeholders or cosmetic afterthoughts. They’re critical moments — tiny psychological battlegrounds where your product either earns trust or quietly pushes users away. While everyone fawns over hero sections and fancy motion graphics, empty states do the quiet, unglamorous work of user education and reassurance. Most teams default to the tragic combo of a sad icon and a limp line of copy: “No data yet. ” This isn’t design; it’s design theatre. The first time a user lands on an empty state is often their moment of maximum vulnerability: they’re unsure if they’ve set things up right, they’re hesitant to click, and they’re hoping your product won’t betray them. The psychology of nothing When faced with an empty state, users don’t interpret it as a casual blank slate. They see it as an immediate question: Did I mess up? Did something break? What am I supposed to do next? A good empty state is a subtle psychological handshake. It says: “You’re fine. Here’s where to go next. ” It reduces friction, anxiety, and the urge to rage-quit and blame the product. Effective empty states answer three essential questions: What should be here? Paint a clear picture of success — whether that’s a list of tasks, a populated chart, or a shared workspace. Why is it empty? Set context... --- - Published: 2025-06-26 - Modified: 2025-07-24 - URL: https://dnsk.work/blog/what-startup-websites-get-wrong-and-how-to-fix-it-in-8-seconds/ There’s a quiet crisis in startup web design. Too many teams have traded clarity for theatre. Instead of sites that inform, we get sites that perform — full of gradients, animations, and slogans so vague they might as well be lorem ipsum. The result? Users scroll. They’re impressed. And then they leave. The modern startup website is starting to look less like a homepage and more like a marketing hallucination. A single-page scroll odyssey packed with personality, but starved of purpose. It’s style over structure. Vibes over value. And it’s killing your conversions. If your homepage can’t explain what your product does in 8 seconds or less, it’s not working. Full stop. And no, that’s not just a bounce rate problem. It’s a trust problem. Users — especially early-stage customers — don’t want to be wowed. They want to be reassured. They’re trying to understand what you offer, how it helps them, and why they should stick around. If they can’t get those answers quickly, you’re not memorable — you’re forgettable. Stop Designing for Applause There’s a dangerous temptation to treat your website like a trophy shelf. To build for the Dribbble crowd. To impress investors. To show you’ve “got taste. ” And fair enough — you want to look the part. But somewhere along the way, many teams forget the real audience: the person who needs to use what you’re selling. Great startup web design isn’t about being admired. It’s about being understood. A flashy site with abstract copy might win awards. But... --- - Published: 2025-06-24 - Modified: 2025-06-24 - URL: https://dnsk.work/blog/how-to-write-product-copy-users-actually-trust/ There’s a reason your product copy reads like it was written by a sentient HR policy. It probably was. Not literally. But by the time your crisp, punchy, human line made it through your product lead, your marketing head, your legal review, your VC’s opinion, and your cousin who “has a way with words,” it lost every bone in its body. What started as: “Delete forever” ... became: “Permanently remove this item from your storage history (this action cannot be undone). ” And somehow, nobody in the room thought that was a problem. Let’s talk about why that happens — and what it’s doing to your product. 1. Safety is killing clarity The biggest crime in interface copy is the pursuit of safety over clarity. Everyone wants to sound “professional. ” No one wants to offend. And that means your product ends up sounding like a chatbot intern who trained on corporate slide decks. Real users don’t care if your modal is polite. They care if they understand what it does. Here’s what we see: IntendedWatered-down Version“Start trial”“Activate limited-time promotional access”“Change plan”“Modify existing subscription preferences”“Sign out”“Log out of current session”“Upgrade”“Explore additional tiered options” Do any of those second options feel human? Memorable? Actionable? Exactly. 2. Nobody is fighting for the voice In small teams, UX copy often falls to whoever has a free hour and a passing familiarity with English. Or ChatGPT. In large teams, it gets passed between three departments and a product owner who says things like, “Let’s... --- - Published: 2025-06-17 - Modified: 2025-06-26 - URL: https://dnsk.work/blog/how-one-button-teaches-users-to-ignore-you/ It sounds harmless. Polite, even. "Maybe Later" — the soft opt-out on your modal, onboarding flow, or product tour. A UX safety valve. A peace offering to the anxious user. But here’s the problem: “Maybe Later” almost always means “Never. ” And worse — it trains users to avoid learning your product at the very moment they most need help. This post isn’t a rant. It’s a teardown. Of why defer buttons do damage. Of how they quietly sabotage product clarity. And of what better design patterns look like — especially for SaaS teams juggling activation, education, and growth. Let’s break it down. What ‘Maybe Later’ Is Actually Doing When you give users a "Maybe Later" button, you’re doing at least three things — none of which are helping your product: 1. You’re making the user choose ignorance You're asking someone who just signed up, or just discovered a new feature, to decide whether they want to learn more — before they understand why it matters. That’s like pausing a cooking tutorial after 30 seconds and asking: "Want to skip the part about the oven? " They say yes, because they’re overwhelmed. But they pay for it later. 2. You’re deferring friction — not removing it Every click they skip now becomes a bump later. The onboarding flow they dismissed reappears as support tickets. The feature they ignored turns into churn. It’s delayed confusion. UX debt, wrapped in a friendly button. 3. You’re sending the message: “This isn’t important” If it... --- - Published: 2025-06-12 - Modified: 2025-06-26 - URL: https://dnsk.work/blog/ux-reset-checklist/ You’ve been moving fast. The roadmap’s alive. Features shipped, launches announced, maybe even a few investors impressed. But now the product’s feeling... messy. Not broken. Just a bit bloated. A little stiff in places. UX that used to feel sharp now feels like it’s whispering through bubble wrap. If you’re here — you don’t need a website redesign. You need a reset. Here’s the checklist to run before you start polishing pixels or opening a fresh Figma file. 1. Start With the Screens You Avoid You know the ones. The account settings panel. The onboarding that never quite worked. The billing page that got postponed four times. These are the parts of your product that haven’t been touched since MVP design — and users still visit them every day. If your own team avoids them, chances are your users are getting stuck in them. 2. Check for Modal Sprawl How many modals are in your product right now? How many can be open at once? It starts with one helpful prompt — and ends with three-stacked overlays, each asking for slightly different things. Use this rule of thumb: if you can’t diagram the full flow without apologising, the modal logic is broken. 3. Find the Tooltips That Became Crutches Tooltips are great — until they start doing too much. If a feature can’t be understood without hovering over six icons, it’s not intuitive. It’s hidden. Kill the tooltips that try to do the job of proper interface copy. Especially the... --- - Published: 2025-06-10 - Modified: 2025-06-19 - URL: https://dnsk.work/blog/not-too-complex-just-not-modular/ When founders or product heads describe their product as “complex,” they rarely mean the business logic. They usually mean the UX is buckling. New features take longer to ship. The interface feels inconsistent. Users are getting lost – and support calls are rising. But here’s the truth: most products in this state aren’t actually too complex. They’re just not modular yet. What Complexity Really Feels Like It shows up as: Teams rebuilding the same component five slightly different ways. New flows that break old patterns without meaning to. A backlog full of UX tweaks that never feel worth prioritising. Copy that shifts voice mid-journey because no one owns the language. The real problem isn’t scale. It’s a lack of structure. Not a big design system – just a set of shared rules the product can build on. Why Most Design Systems Don’t Work at This Stage For small SaaS teams, full-blown design systems are usually overkill: No one has time to maintain them. The codebase is still evolving. The product is shipping weekly, not quarterly. What’s needed instead isn’t systemisation – it’s modular thinking. A mindset, not a framework. What Modularity Looks Like (Practically) 1. Repeatable Flows, Not Just Reusable ComponentsA button isn’t a pattern. A flow is. Instead of designing screens in isolation, modular UX builds around outcomes: “How do users add something? ” “How do they undo? ” “Where do they go after success? ” 2. A Clear VocabularyStart small. Agree on the names of things. If your... --- - Published: 2025-06-06 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/pricing-page-redesign/ There’s one part of a SaaS product that’s both incredibly revealing and tragically underdesigned: The pricing page. It’s where value meets clarity. Or confusion. Or cowardice. And it’s usually the page that gets the least love – stuck in Notion, half-baked by a product marketer, or styled like it’s still 2014. We’ve seen it all. The infinite scrolling grids. The footnotes. The asterisks. The dreaded toggle between monthly and annual (that moves the CTA button just enough to be annoying). Let’s talk about what’s broken – and how we’d fix it. What Pricing UI Says (Whether You Mean It or Not) Your pricing page is more than a table. It’s a statement. And like any good interface, it speaks volumes – even when you don’t intend it to: “We’re scared to commit” – when every feature is hidden behind a tooltip or vague label. “We don’t understand our users” – when tiers are arranged by internal logic, not real use cases. “We’re desperate” – when every plan includes everything because someone said “no friction. ” “We copied our competitor” – when the entire layout looks like a Notion clone with blue buttons. In short: your pricing page often says more about your confidence than your product does. It reflects how much you trust your offer, your positioning, and your audience. Common Sins of SaaS Pricing UX 1. Feature Creep TablesTables with 30+ rows of micro-differentiators don’t help anyone. They introduce confusion and encourage anxiety. Users feel like they need to... --- - Published: 2025-06-03 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/stop-building-hidden-features/ You built something useful. You shipped it fast. Maybe you even ran a tidy launch thread on LinkedIn. And now... it’s dead weight. Buried in your UI. Ignored. This isn’t a development problem. Or even a design one. It’s a discovery problem – and it’s killing your product. Discovery Is the Bottleneck Most founders we speak to are obsessed with building. Features, integrations, dashboards, new flows – always new flows. But the real bottleneck, the thing that quietly crushes adoption, is this: “Can users find and understand what we’ve already built? ” If the answer’s no, it doesn’t matter how clever or clean the thing is. It won’t get used. It won’t create value. It won’t stick. This isn’t just a UX detail. It’s a growth ceiling. Why Good Features Go Unused A few reasons: Built fast, introduced poorly: The changelog went out, the feature was live... but no onboarding, no prompts, no in-context help. Buried behind layers of UI: Think: three-dot menus, obscure settings, modals-within-modals. Over-reliance on user memory: Just because you tweeted about it once doesn’t mean users remember. In most early-stage products, even flagship features get hidden behind bad timing, vague icons, or mental load. And when that happens, the product doesn’t feel more powerful. It feels more confusing. Founders: Shipping Isn’t the Finish Line You think you shipped it. But did you? Let’s define “shipped” properly: Can a first-time user find it within 2–3 clicks? Do they understand what it does without reading a doc? Can... --- - Published: 2025-05-29 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/wall-of-settings/ If your settings page is longer than your actual product, you’re not giving users freedom – you’re handing them your design indecision. Settings pages that stretch endlessly downward aren’t empowering – they’re exhausting. Each toggle, checkbox, or dropdown represents a decision your team refused to make. It’s your uncertainty passed directly onto the user. A Symptom, Not a Feature Every setting you add without clear justification dilutes your core product experience. Unable to commit to a default theme? You offer users “dark mode,” “light mode,” and even “automatic mode” – each presented equally without recommendation. Unsure about the right frequency of user notifications? Instead of research and decision-making, you provide daily, weekly, immediate, and custom alerts – piling complexity onto the user rather than addressing it yourself. Settings aren’t always about user empowerment. Often, they’re an admission that your team didn’t fully resolve the user’s underlying problem. Real-World Consequences Consider this common scenario: A new user opens your settings page for the first time. Instead of clarity, they encounter: “Advanced features” toggles with vague descriptions. Notification settings duplicated in multiple locations without context. Privacy options hidden beneath unclear labels like “Enhanced Personalization. ” Feature toggles intended for power users but never clearly explained. This complexity creates friction, anxiety, and decision paralysis. Users don’t feel more control – they feel confused, worried they’ll choose incorrectly. Why It Happens Design indecision is rarely intentional. Typically, it’s incremental: Stakeholders want maximum flexibility, without considering cognitive load. Legacy features remain active due to fear... --- - Published: 2025-05-27 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/who-are-you-designing-for/ A team in mid-sprint, tired but caffeinated. You’re in Figma or Slack or Notion, staring at a half-finished flow someone labeled “v3-final-ish. ” Someone says, “Let’s just tweak the copy so it’s less confusing. ”Another chimes in: “Legal needs to approve it anyway. ”A third shrugs: “Our sales team just needs something to demo. ” No one asks: “Who’s struggling right now that this helps? ” And that’s where real UX dies. The “Who Are We Helping? ” Test Every feature. Every flow. Every headline. Should answer one thing: Who does this remove friction for — today? Not in theory. Not eventually. Not after a product launch. If your answer is:– “The client from three months ago who wanted exports”– “The board”– “It makes our roadmap slide look complete” You’re not helping. You’re appeasing. Example Walkthrough: The Reporting Tab Say you’re building a reporting tab. Bad answer: “It looks good to show stakeholders what we’ve built. ”Worse answer: “One customer mentioned they wanted more visibility. ” Better answer: “Our current customers export data just to run simple weekly summaries. This gives them what they need in 2 clicks — no export. ” This shift changes everything:– You remove bloat– You prioritise defaults– You write copy that tells users why it exists, not just what it does Red Flags You’re Designing for the Wrong Person 1. “Nobody’s complained. ”Silence ≠ success. It often means “I gave up. ” 2. “It’s good for the demo. ”Cool. But can your actual users even... --- - Published: 2025-05-22 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/politeness-problem/ Your product is nice. Too nice. Everything says “maybe. ” Every modal wants to know if it’s a good time. Every tooltip apologises for existing. It’s all lowercase and softly rounded — like if Helvetica had social anxiety. We get it. You want to be helpful, human, inoffensive. You want to sound like a warm breeze. But here’s the problem: no one trusts a UI that whispers. The Tone That’s Too Careful Modern UX is obsessed with friendliness. But friendliness isn’t clarity. You’ve seen this voice:– The banner that says, “Heads up, something might not have gone quite right... ”– The empty state that gently chirps, “Looks like nothing’s here just yet, but that’s okay :)”– The button that offers, “Let’s maybe try saving this now? ” It’s all just slightly damp. What it doesn’t say:– What happened. – What to do next. – Whether or not the product is in control. Politeness ≠ Trust Let’s be clear. Users don’t want to be coddled. They want:– Confidence– Precision– A UI that knows what it’s doing Politeness avoids conflict. But real UX helps people make decisions. When your product won’t commit to anything — a flow, an action, a sentence — users start assuming you can’t. Because clarity signals competence. Some Real Offenders (We’ve Fixed These) “Oops! Something might’ve gone wrong. ”→ What went wrong? What happens now? What do I do? “This is taking a bit longer than usual! ”→ Is it broken? Should I reload? Will I lose progress?... --- - Published: 2025-05-20 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/ui-audit-reckoning/ Your product works. Mostly. The flows are familiar. The nav still kind of makes sense. Nothing’s technically broken. And yet, everything feels... off. This post is for product managers, founders, and leads who’ve started asking themselves: “Should we redesign? ” Before you book a redesign sprint — stop. You might not need a redesign. You might need a reckoning. What’s Actually Going On? Redesigns fix visual inconsistency. Audits fix functional drift. Over time, your product collects:– Legacy features no one questions– Settings screens full of toggles you no longer support– Microcopy that references workflows from three roadmaps ago– Tooltips, modals, and checkboxes added “just in case” It’s not broken. It’s bloated. Which means the fix isn’t a new coat of paint. It’s a hard look at what actually needs to be there. Who Should Care (and Why) → Product managers:You’re making decisions based on how things look, not how they work. A UI audit helps you reduce scope creep, clarify feature strategy, and cut dead weight. → Founders and CEOs:If your product’s UI still reflects your MVP-era thinking, users will feel that. A UI audit helps you re-align the interface with the business you’ve actually built. → Designers and UX leads:You can’t redesign your way out of structural clutter. This gives you the input you need to prioritise what’s real — not just what looks nice in Figma. DNSK’s UI Audit Checklist Here’s what we walk through before touching visuals: 1. Navigation sanity check– Can each nav item be described... --- - Published: 2025-05-15 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/mvp-first-version/ You know the one. The MVP built by a freelancer over a long weekend, styled with inline CSS, powered by a Google Sheet and a thousand silent prayers. And somehow — it worked. The team raised money. Got users. Found traction. It looked like hell, but it proved a point. That something about the idea mattered. That’s what a first version is for. MVP ≠ Final Product A good MVP is supposed to make you slightly uncomfortable. If it doesn’t, you’ve probably spent too long smoothing out the wrong things. You don’t need a design system. You need a working path from problem → value. But here’s the bit founders forget: just because your awkward MVP shipped and survived... doesn’t mean it should stay that way. First = Fast. Not Forever. There’s value in speed. There’s value in duct tape. But there’s also a moment when it turns into tech debt, UX rot, and product confusion. We’ve seen it happen:– MVPs that go unchanged for 18 months– Design held hostage by early dev decisions– Broken onboarding covered up with clever copy It’s fine. For a while. But if your product starts getting traction — and you don’t clean it up — it’s not scrappy anymore. It’s sloppy. Users Will Forgive Early. They Won’t Forget Later. Your first 100 users don’t care if your UI is ugly. They care if it works. But once you have traction? You can’t keep blaming the MVP. – Users expect clarity– Teams need systems– Bugs... --- - Published: 2025-05-13 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/silence-feedback/ The feature shipped. The onboarding was polished. The numbers looked fine. And then... nothing. No tickets. No replies. No praise. No complaints. No usage. Just empty sessions and quiet churn. And the worst part? Everyone in the room thought that meant success. This is a post about the signal inside that silence — and how to design with it in mind. Silence Isn’t Neutral No feedback isn’t good feedback. It often means:– They didn’t get far enough to care– They didn’t find the value– They forgot you existed Real users don’t file tickets unless they think the product is worth fixing. They only complain when they believe someone might respond. Silence, most of the time, is quiet resignation. It’s people saying: “It didn’t break. It just didn’t matter. ” Sound Familiar? You launch a dashboard tab. Nobody uses it. Not because they hate it — they just... don’t notice it. You craft a beautiful 3-step onboarding. Users bounce after screen two, but never leave a comment. You send a survey. No one replies. No bugs. No rage clicks. Just polite disengagement. That’s the signal. Why We Miss It We build for action. Metrics. Feedback loops. But silence doesn’t show up in Jira. So we write it off. We assume if there’s no friction, there’s no problem. But often, the problem isn’t friction — it’s disconnection. Silence means:– Your product didn’t click with real use cases– The benefit wasn’t immediate enough– The interface didn’t create momentum– You lost their attention and... --- - Published: 2025-05-01 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/this-button-does-nothing/ Every designer, at some point, ships a button that doesn’t work. Maybe it launches a spinner that spins forever. Maybe it opens a modal promising a feature that hasn’t been built. Maybe it just... refreshes the page and hopes you don’t notice. We don’t talk about these buttons much. They’re awkward. They’re compromises. But they happen — and they happen for a reason. This post is about why we ship them, why they’re not always bad, and what every fake button is quietly telling your users. The Illusion of Progress When you’re building fast, sometimes the UI gets ahead of the functionality. The frontend team finishes a flow before the backend API is ready. The marketing team needs screenshots for launch day. The investor deck demands a polished product. So you leave the button in. “It’s not wired up yet, but it shows intent. ” And honestly? That’s not a bad instinct. A button that does nothing signals what will exist. It plants the idea: “You’ll be able to do this soon. ” And in early-stage products, signaling intent matters. A Promise in Disguise But here’s the catch: a button is a promise. Every affordance you show tells the user, “This is available to you. ” So even if you’re shipping that button as a placeholder, you’re training an expectation. You’re inviting trust. And trust comes with a clock. The longer that button doesn’t work, the more it shifts from promise → tease → betrayal. The first click: curiosity. The... --- - Published: 2025-04-30 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/fake-persona-test/ Most of your product’s worst UX failures won’t show up in analytics. They’ll show up in a support ticket from someone who accidentally backspaced their way out of a signup flow. Or rage-clicked a modal five times on a cracked screen. Or tried to use your beautifully designed pricing table through the lens of Safari Reader Mode on an iPad from 2016. That’s where the Fake Persona Test comes in. It’s not real research. It’s not a replacement for user interviews. It’s just a fast, funny, internal tool for breaking out of your bubble — and spotting the friction you’re too close to see. What It Is Fake personas are exaggerated, fictional user types you pretend to be while navigating your own product. Not based on demographics — based on odd habits, misinformed instincts, and cursed device setups. They’re built to surface the edge-case weirdness that often breaks otherwise “perfect” UX. This isn’t about mocking users. It’s about seeing your product through entirely different eyes — the kind that scroll too fast, type too slow, or never click anything that looks like a button. The Crew Here’s our cast of test personas. Not comprehensive. Not research-backed. Just extremely effective. Edith, 69, retired librarian – Uses an iPad Mini with 2% battery– Double-taps everything– Doesn’t trust autofill, Google, or QR codes– Thinks Wi-Fi is “a bit aggressive” Edith is not here to explore. She wants to complete a task, get her info, and go. Your clarity bar has never been higher.... --- - Published: 2025-04-24 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/redesigning-without-permission/ This isn’t a pitch. It’s not a teardown. And it’s definitely not for clout. It’s a reflex. A twitch in the brain. The quiet urge to take something you admire and... move a few things around. We’re talking about unsolicited redesigns — the ones that happen in your head, on a napkin, in a Figma frame titled something totally non-committal like “Redesign_Maybe_IDK_v1”. We do them all the time. Not to be clever. Not to be right. But because it’s how we think. This post is about why that impulse matters — and what we’ve learned by redesigning other people’s work without asking. (Sorry. ) Let’s Get Something Clear We’re not dunking. If a product made it onto our radar, that means something. Most products don’t. (Truly. Have you seen the internet? ) When we redesign something unsolicited, it’s because it’s almost there. It has shape. Signal. Structure. It just needs a bit of clarity. Or courage. Or whitespace. Redesigning without permission isn’t about critique. It’s about curiosity. And, okay, maybe a little compulsion. The Reflex You know the feeling. You sign up for a product. First click — smooth. Second click — wait, what’s this doing here? Third click — oh no. Or you admire a clean landing page, but the pricing logic feels like a riddle. Or the dashboard hierarchy feels like someone’s cat walked across the wireframes. Or the signup flow is like a maze designed by a particularly petty minotaur. You can’t not see it. And suddenly... --- - Published: 2025-04-21 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/startups-we-admire/ We built a tool. That’s it. That’s the post. Okay, not quite. But yes — https://curated. dnsk. work is just a simple, slightly obsessive tool we made to track the startups we keep accidentally redesigning in our heads. It’s not a lead gen gimmick. Not a case study hub. Definitely not SEO-driven (sorry, robots). Just a lovingly maintained public list of “Hey... why aren’t we working with these people? ” You know those internal Slack threads where someone drops a product link and says “This is kind of great. But also... ” — followed by 15 messages about onboarding flows, font weight choices, and how their navbar would look better with less cognitive debt? We took that energy, put it on a webpage, and made it click-safe. Why We Made It Because taste isn’t just about what you ship. It’s also about what you notice. We kept catching ourselves watching certain startups closely — not because they were clients, but because they were interesting. Clear signals. Sharp products. Great ideas just a few pixels away from greatness. Stuff that makes you want to roll up your sleeves. At some point we realised we were doing the same dance over and over: Admire it. Critique it (with love). Mentally redesign a few things. Wonder aloud how we’d approach it. Forget to write it down. Repeat. So we built a home for it. That’s the whole origin story. One part nerdy admiration, one part creative impulse containment system. What It Actually Is... --- - Published: 2025-04-17 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/dont-design-like-pharaoh/ What happens when product teams try to control everything — and what real leadership in UX looks like. The final days of Pesach are about walking forward. Not escaping anymore — moving. Through the sea. Into the unknown. It’s messy, unscripted, and very human. So this is a story about control. About what happens when design becomes fear-driven. And about why trying to manage every click, every user move, every pixel of behaviour — ends up hurting the people we’re supposed to help. In other words: Pharaoh UX. The Pharaoh Problem in Product Design Pharaoh’s core fear? Loss of control. That people might act freely. That things might change. Sound familiar? You see it in: – Onboarding flows you can’t skip– Interfaces that require everything before you do anything– Products that lock data inside– Cancel flows designed to shame you There’s a pattern here. It’s the same logic: “If we let people decide for themselves, we’ll lose them. ” We’ve seen this play out:– In project kickoffs where someone insists the login screen needs four fields (minimum! )– In apps where the “X” to close the popup has the same colour as the background (a subtle power move)– In platforms that treat their own users like enemies of the state It’s all Pharaoh energy. “Stay here. Work harder. Don’t ask questions. ” When the Sea Splits, Let People Walk Let’s get one thing straight: the sea didn’t split so the Israelites could walk. It split because they walked. Progress required... --- - Published: 2025-04-15 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/designing-for-liberation/ What the Exodus Can Teach Us About Breaking UX Slavery Patterns We’re deep into Pesach season. A time of freedom. Of storytelling. Of asking difficult questions. And as odd as it sounds, it’s also a perfect time to talk about UI and UX. Because the Exodus isn’t just a historical escape — it’s a metaphor. A lens through which we can look at systems, constraints, and the experience of moving from stuck to free. In product design, we talk a lot about “user journeys. ” But what happens when that journey is more like slavery in Egypt — rigid, extractive, and hard to leave? UX Slavery Is Real (Metaphorically) Okay — not slavery in the literal sense. But how often have you used a product and felt trapped? – You try to cancel your subscription and the button is hidden behind five dropdowns– You want to export your data, but that feature is locked or “coming soon”– You’re forced to onboard with ten unskippable steps and a fake progress bar These are dark patterns. But more than that, they’re signs of a system built to control, not enable. Pharaoh wouldn’t let the Israelites go — and some products won’t let their users leave. Design can liberate, or it can dominate. And too often, we choose the latter because it “improves conversion. ” When a product turns every click into a contract, every screen into a trap, it starts to feel less like a tool — and more like digital Egypt.... --- - Published: 2025-04-09 - Modified: 2025-06-20 - URL: https://dnsk.work/blog/lets-not-build-portfolios-for-algorithms/ Not Everything Needs a CTA We’ve all seen them. The clean, confident LinkedIn posts that promise to fix your design portfolio in five bullet points or less. “Keep your colour scheme minimal. ”“Pick three projects. ”“Add a CTA to request the full deck. ” It sounds efficient. Actionable. Like you’re finally going to make progress on that dusty Figma file you’ve been avoiding. But here’s the thing: portfolios aren’t landing pages. And you’re not running an ad campaign. So why are we designing portfolios like we’re trying to boost conversion rates? The LinkedIn Portfolio Industrial Complex Take this post we stumbled across the other day: It’s not malicious. It’s not even wrong — for a certain kind of designer, at a certain point in their career. But advice like this spreads because it feels safe. It gives structure. It’s tidy. And when you’re stuck, anything that helps you feel like you’re moving forward is seductive. The problem is, this kind of advice flattens the craft. It reduces portfolios — which should be rich, strange, and deeply personal — into sales collateral. Design isn’t simple. It’s nuanced. So your portfolio shouldn’t be overly simple either. What Portfolios Are Actually For A portfolio isn’t there to convince someone to click a button. It’s there to: – Show how you think– Communicate what it’s like to work with you– Reveal how you navigate ambiguity, feedback, and constraints In short, it’s there to help someone imagine you solving their problem — not admire the... --- - Published: 2025-04-04 - Modified: 2025-07-21 - URL: https://dnsk.work/blog/linkedin-update-post/ Award-winning. Passionate. Strategic. Driven. You’ve read that sentence before — probably on my old LinkedIn profile. It wasn’t a lie. But it also wasn’t helping. I’m a designer. A good one. I’ve led design across enterprise tools, scaling platforms, internal systems, and launch-day MVPs. But you wouldn’t know that from the way I used to talk about myself online. My profile read like it was trying to win a scholarship. Or worse — like I wasn’t sure who I was talking to. And that’s a problem, especially when you’re part of a small studio trying to attract the right kind of clients. The Real Problem I wasn’t trying to land a full-time job at a bank. I’m not looking to freelance either. What I needed was positioning that reflected how I work now — as a product design partner, embedded in client teams, helping them untangle messy UX and scale their products with intention. The kinds of clients we work with at DNSK WORK — founders, product leads, startups post-MVP — move quickly and expect clarity. They don’t want a CV. They want to know if you “get it. ” But instead, my old bio opened with: “An award-winning UI/UX designer with experience in a diverse range of sectors such as tourism, automotive, entertainment, healthtech, fintech... ” Which is the design equivalent of saying: “I like people and enjoy solving problems. ” Cool. But not helpful. Not memorable. Not positioning. These kinds of phrases flood LinkedIn, and most of them... --- - Published: 2025-04-02 - Modified: 2025-06-23 - URL: https://dnsk.work/blog/hello-world/ Why We Built Our Blog on Hugo We finally launched our blog. Not because we had to. Not for SEO. And definitely not to churn out clickbait. We launched it because we’ve got things to say — and Hugo felt like the right place to say them. If you’re curious why we chose Hugo over the dozens of shinier, trendier options out there — here’s the story. It’s not technical. It’s not philosophical. It’s just what made sense for the way we work. We Wanted Something Fast — No, Really Fast We spend our days designing and shipping products where speed isn’t a “nice to have” — it’s table stakes. If our own blog took ages to load or felt bloated, it would undermine everything we believe about good UX. Hugo compiles to static HTML. That means: No CMS wait times No hydration delays Just content — instantly available, everywhere We care a lot about first impressions. Hugo helps us make a good one — fast pages, clean markup, and no performance debt. We Don’t Need a CMS to Write We don’t think of content as something that needs to be “managed. ”We think of it as an extension of design — another medium we shape. That means: Writing directly in Markdown Committing changes via Git Reviewing drafts like we do code or design No dashboard. No login screen. No scheduling tools. Just one unified workflow. And because everything lives in the same repo, our designers and developers can tweak... --- ---