How to Get Good Work From a Remote Design Agency

Hiring a remote design agency is a common choice for startups and small companies. You get a team with set skills without hiring, and the time zone gap can even mean progress overnight. It can also go badly: a week of silence, a first draft that misses the point, a feedback round that arrives as 40 unrelated comments.

We are a remote-first agency ourselves, so this post is written with our own bias. It is advice for the client side, and it applies to most agencies, not only us. The goal is to help you get useful work with fewer rounds of revision.

Before you sign: pick for fit, not only portfolio

A portfolio shows taste. It does not show how a team communicates. Before choosing, ask for the following.

• Who will actually work on your project? Ask for names and roles, and whether the same people stay through the project.
• How do they handle time zones? Ask what hours overlap and how they handle questions that arise outside that window.
• What does a typical week look like? Look for a concrete answer: a weekly demo, a shared board, a short written update.
• How do they handle disagreement? A good partner explains the reasoning and takes it seriously when you push back.
• What do you own at the end? Source files, design system, code and assets should be yours. Confirm this in the contract.

Write a brief that can be acted on

The brief is the most important document in the project. A weak brief gets a weak first round, and a remote team cannot walk to your desk and ask. Include:

1. The problem, in plain words. Not "redesign the app", but "new users do not finish setting up their first booking, and we want to understand why and fix it".
2. Who it is for. Describe the actual users: where they are, what device they use, what they are trying to do. If you have research, share it. If you do not, say so, and the team can plan a short discovery phase.
3. What success looks like. A measurable outcome, such as "more people complete setup", or a launch date and a defined scope. Do not invent a target number you cannot justify.
4. Constraints. Budget range, deadline, technology limits, brand rules, legal or accessibility requirements.
5. What exists already. Links to the current product, brand guidelines, analytics access, past designs, competitor examples you like and dislike (and why).
6. Who decides. Name one person who gives final approval, and list others who give input.

A one-to-two page brief is plenty. Then schedule a kickoff call to talk it through, since a call surfaces the unwritten assumptions in 30 minutes.

Agree the working cadence early

Remote work runs on rhythm. Without one, projects drift into long silences followed by large surprises. Agree on these in the first week and write them down.

A weekly rhythm that works across time zones

• Monday: a short written plan. The agency posts what they will deliver this week and what they need from you.
• Midweek: work in progress. A link to a draft or prototype, even if rough, with a note on what is being tested. Early views prevent big misses.
• End of week: a demo. A 30-minute call, recorded for people who cannot attend, plus a written summary of decisions and open questions.

If overlap hours are short, use that window only for conversation that needs it: demos, disagreements, decisions. Everything else can move asynchronously.

Asynchronous habits

• One shared place for the work. A single board and a single channel. Scattered messages across email, chat and direct messages get lost.
• Questions in writing, with context. "Can we use a different colour?" is hard to answer. "On the checkout screen, should the primary button stay green, given the error state also uses green?" is easy.
• A decision log. Keep a running list of decisions with the date and the reason. It saves arguments about what was agreed six weeks ago.
• A stated response time. For example, same working day for questions, and 48 hours for formal feedback rounds. Both sides keep to it.

Give feedback that moves the work forward

Feedback is where most remote projects lose time. A designer who receives conflicting comments from five people will either guess or ask for clarity, and both cost days.

Consolidate before sending. Collect comments internally, resolve conflicts, and send one set per round. Name one person to merge them.

Describe the problem, not only the solution. "Make the logo bigger" is a solution. "The logo is hard to recognise on the mobile header" is a problem, and the designer may solve it better than you guessed. If you do have a specific change in mind, say it, and also say why.

Tie comments to the brief. "This does not help new users finish setup, which was the goal" is more useful than "I don't like it". Personal taste is allowed, but label it as taste.

Separate levels of feedback. Raise structural concerns (flow, content, layout) before visual polish (colours, spacing). Commenting on button colours while the flow is still wrong wastes both sides' time.

Use the right format. Comment directly on the design file or prototype where possible. For complicated points, a short screen recording of you clicking through and talking is faster to make and clearer than a long message.

A feedback template:

Round 2 feedback, from [name], [date]

Keep:
- The new onboarding layout. Clear and fast.

Problems (priority order):
1. High: The date picker on screen 3 is hard to use with a thumb. Users book mostly on phones.
2. Medium: The pricing table buries the cheapest plan.
3. Low (taste): I would prefer a warmer shade for the header.

Questions:
- Can we see a version of screen 4 with the long form split into two steps?

Handle the time zone gap on purpose

Treat the gap as a scheduling problem, not a quality problem.

• Share working hours and holidays at the start, including public holidays in both countries.
• End each day with a handoff note. What was done, what is blocked, what to review. The other side can then act while you are offline.
• Avoid urgent requests at the end of your day. A message sent at 6 p.m. your time may arrive in the middle of someone's night. Plan requests a day ahead.

Plan the handover from the beginning

A project that ends with a zip file and an apology is a failed handover. Ask for the following during the project, not at the end.

• Organised source files, with named pages, components and layers that a new person can follow.
• A design system or style guide covering colours, type, spacing and components, with notes on usage.
• Specs and assets, exported in the formats your developers need, or developer-ready design files.
• Documentation of decisions, including what was tried and rejected, and why.
• A walkthrough call with your developers, recorded.
• A defined support window after delivery for questions and small fixes, written into the contract.

If the agency also builds the product, ask for the repository to be in your account from the start, with regular commits and a README that explains how to run it.

FAQ

Do we need a project manager on our side?

Someone must own decisions and consolidate feedback. It does not have to be a full-time role, but it has to be a named person with time set aside each week.

How many revision rounds should we expect?

It depends on the contract. Agree the number up front, and make each round count by consolidating feedback. Clear briefs and early drafts reduce the need for rounds.

Talk to us

If you are considering a remote design partner and want to discuss your brief, timeline or ways of working, we are happy to talk it through. Email hello@risingstation.com or visit risingstation.com/contact-us.