How DNSK works
Most agencies have a process. The process has phases. The phases have deliverables. The deliverables have a timeline. By the time the timeline ends, someone's left the company, the product has changed, the brief is unrecognisable, and the deliverables are technically complete, which is the best thing anyone can say about them.
DNSK.WORK skips the phases. Tanya gets inside the product, finds what's broken, and starts on it without check-in to schedule the check-in. Retainer or sprint – whichever fits the way the team works. The first week looks like work, not onboarding.
Process
No lengthy document to fill out before anything starts. Tanya looks at the actual product and forms her own view of what's wrong. The team's version of the problem is useful context. It's not the starting point.
The designer who looked at the product on day one is the same one doing the work on day thirty. Nothing gets translated, summarised, or handed to someone junior while the senior attends the kickoff.
One call per week. Everything else in writing – Figma comments, Loom walkthroughs, a shared doc for decisions. Work gets reviewed when it's ready, not when a calendar slot opens. Faster than it sounds.
The first conversation usually ends with Tanya already in the product. Not a proposal for when the work might start. The work.
Every call, every direction change, every "let's go with option B" gets written down. Nothing lives in someone's head. Nothing needs re-explaining three weeks later when the context is gone.
Specs in Figma. Edge cases designed. Error states accounted for. The developer doesn't need to invent anything or book a call to ask what something means. The handoff call that doesn't happen because everything was already in writing.
Engagement models
We know something's wrong. We don't know what.
Tanya gets into the product, finds what's broken, and fixes it into dev-ready Figma – the kind that ships without a three-hour handoff call.
We need senior design. We're not ready to hire.
When product needs a senior designer but hiring takes three months and the headcount isn't there yet. Tanya embeds part-time – in the sprints, in the Figma, in the decisions – and runs the design the way a senior hire would. Without the onboarding, the equity conversation, or the six-month notice period if it doesn't work out.
We know what's wrong. We need it fixed.
Tanya scopes it, designs it, and hands over dev-ready Figma or clean code – full specs, async support through the build. Defined scope, defined output, no surprises.
Hear it from the teams
The best way to know if this works is to hear it from someone who's already been through it.
The work behind the reviews
Clients who trust DNSK.WORK with their products aren't the ones who can afford to get it wrong. Here's what the process produces in practice.
FLUX
Malaysia’s first all-inclusive monthly car subscription service
Argyle
Argyle delivers real-time, user-permissioned income and employment data straight from payroll systems
The ASH Research Collaborative
ASH RC is a nonprofit accelerating research and care for blood diseases
DERE Portal for The American Dental Association
Launching DERE, the first national platform built to improve patient outcomes through smarter insight
/ 01
How does the process actually work?
How does the process actually work?
It starts with a call – 20 to 35 minutes. No lengthy brief to fill out, no deck to prepare. Tanya will ask about the product, the team, and what's not working. From there she'll look at the actual product and come back with a proposal – what needs fixing, in what order, and what working together looks like.
Once the engagement starts, everything runs async. Work happens in Figma, decisions get documented, handoffs are dev-ready. There's one scheduled call per week for alignment – everything else happens in writing, no Slack firefighting, no last-minute "can you just" requests.
/ 02
What does async mean in practice?
What does async mean in practice?
In practice it means: work gets reviewed when it's ready, not when a calendar slot opens up. Feedback happens in writing – in Figma, in a shared doc, or over Loom. Decisions get documented so nothing gets lost between calls.
There's one scheduled call per week. Everything else moves async. It's faster than it sounds.
/ 03
How much input do you need from us?
How much input do you need from us?
More at the start, less as things move. The first call is the heaviest lift. After that, the work is mostly hers.
During the engagement, expect to review work in Figma, answer specific questions, and join one call per week. No workshops, no lengthy feedback sessions, no "can you fill out this brief" requests mid-project. The goal is to take work off your plate, not add to it.
/ 04
How fast does this move?
How fast does this move?
A diagnostic sprint takes one to two weeks. A project engagement runs four to eight weeks depending on scope. A retainer moves at a consistent pace. Enough to see real progress every week without burning through the work that actually needs thinking time. The goal is work that doesn't need redoing in six months. That takes the time it takes.
/ 05
What tools do you use?
What tools do you use?
Figma for everything design wireframes, UI, prototypes, dev-ready specs. Loom for walkthroughs and async feedback. Google Doc or a shared doc for decisions and documentation. Email for everything that needs a paper trail.
AI is changing design work faster than most studios want to admit. DNSK.WORK isn't here to pretend otherwise. The approach is simple: use it where it makes the work sharper, skip it where it doesn't. Not as a shortcut, not as a replacement for judgment – as a tool that expands what's possible in the time available. Microcopy, front-end generation, pattern recognition. The parts that used to take three days now take three hours. That time goes back into the work that actually needs thinking.
/ 06
How do you handle feedback and revisions?
How do you handle feedback and revisions?
Feedback happens async and in writing – in Figma comments, a shared doc, or over Loom. Not in a meeting where half the room hasn't seen the work yet. Revisions are part of the process, not a negotiation. If something isn't right, it gets fixed. The goal is work that's actually right, not work that's been approved by the most people in the room.
/ 07
What happens if the project scope changes?
What happens if the project scope changes?
It depends on why it changed. If something new comes up during the work that's genuinely connected to the problem – that's normal, it gets absorbed. If the brief changes because internal priorities shifted or someone new joined the conversation – that's a different scope and it gets treated as one.