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 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.
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.
Tanya joins the team – 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 notice period.
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.
Tetiana was fantastic to work with. She embodies an exceptional balance of creative ingenuity and highly efficient in producing quality designs. Tetiana was thoughtful and methodical in her approach, leveraging her broad experience to solve crucial UX problems. At the end of our project, Tetiana delivered a clean, crisp and simple design for a relatively complex product. I would definitely engage her services again.
Aziz Ayman
Founder & CEO, FLUX
Tetiana is an excellent designer, she has created a state of the art design for us which was a top notch quality, simply a second to none. I'd like to recommend her work to anyone who's interested in a design work, look no further.
Mark Sholberg
Product Owner, IQVIA
They've been a valuable contributor to our company and have done excellent designs. They have some of the fastest 0 to 1 designers we've worked with, and everything we get back from them is high quality. They've delivered us 5-10 app/website designs over the past few years that we've shipped & implemented. They also help us iterate on the designs and make our products better.
Patrick Lu
Founder, Quant Five
Tanya is a very competent and experienced professional. Embedded within a predetermined timeframe. Do not hurt matters not on the merits. Working with her is getting better from the first minute and remains so throughout the period of work.
Tim Kohen
VP of Product, T-Mobile
DNSK listened to our objectives and worked with us to create a visual aesthetic that from the ground up that worked for our company. She was receptive to feedback and helped guide us to solutions that worked. We are so happy with the final website and brand identity and look forward to working with her again!
Stacy French
VP Digital, Economic Nonprofit
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.