“I can’t get any actual work done.”

That’s what a colleague of mine, a senior product designer at a fast-growing startup, told me last week. Her calendar looked like a game of Tetris:

• Design review at 9
• Feedback session at 11
• Stakeholder alignment at 2
• Developer handoff at 4

23 hours per week. In meetings.

The crazy part? This is normal. Most product teams spend more time talking about design than actually designing.

I know because I’ve been there. I’ve been a product designer for over 7 years now and in the beginning, my clients and myself were under the impression that meetings are good, especially when remote first.

​

However, the best remote teams I’ve worked with rarely meet to get things done. The ideal customers for my design agency Grauberg.

Instead, we used a different process. One that cuts meetings by 80% while making collaboration better, not worse.

​

Today, I want to share this exact process with real examples, so that you can design better, happier and faster.

Disclaimer: This process is what I use, and it works for me. I’m sure it’s not perfect, but I truly believe it will be helpful to some.

Ideally, I could share the perspective of a remote design process from many different designers, so if you are up for a podcast session on your design process, send me a message here: nik@grauberg.co

A Better Way: The Async-First Design Process (in 5 Steps)

After years of studying how companies like Linear, Figma, and GitHub work, + experimenting while working with clients like Telekom, Deltia AI and Enso, I’ve developed a process that keeps the collaboration but kills the meetings.

Here’s how it works:

1. The Draft

Most of my work starts in either FigJam (like Miro) or Figma. Depending on the task at hand, we either need to research and map things in FigJam (like an onboarding flow for a mobile app) or actually design something in Figma (like a new chart for the dashboard).

Either way, it is always called a “Draft”. Signalling to not only myself, but especially to the team that this is nowhere near the final design.

Pro tip: Use FigJam’s user story template to structure your thinking clearly.

What is considered a draft?

Everything without proper feedback is a draft.

This took me years to learn.

You can spend weeks on a website or a design feature, but once you show it to the client or your team, there will be things you need to adjust or improve.

This can be frustrating, unless you already know you have to readjust things.

Knowing this also helps with setting a realistic timeline.

You can’t set the deadline for Friday and then present the first design… on Friday. You need time to get the feedback and to implement it.

2. The Video

Rather than walking through your work live:

• Record a Loom explaining your thinking
• Share context and rationale
• Point out areas where you need feedback
• Make it short (watching a 15min walkthrough of a feature can be daunting)

Real example: “Hey team, I’ve explored three approaches for our onboarding flow. Here’s why I recommend option B…”

I usually share the link of the Loom + a short explanation of why this is important in the main communication channel or attach it to the user story in Jira.

Why is this important?

Because

A: By just sharing a design file, people (even designers) often don’t understand how you got to this conclusion, and

B: to collect feedback from multiple people in one place, but on their time schedule.

Bravo, you saved everyone a meeting!

3. The Feedback

Gathering feedback is one of the biggest pain points for me when working with high-meeting clients or in-person projects, because it’s so easy to forget what you talked about. After 2 weeks, no one remembers why there is a download button next to a cart item.

Don’t get me wrong, when working fully remote and async you can still lose and forget about feedback.

That’s why Loom is great, because you can

1. Link it anywhere (e.g a user story)
2. You have the feedback collected in one place
3. People can rewatch the video even months later.

However, I need to point out that this is not perfect.

Sometimes you need feedback in Figma on specific components, or you comment text snippets in a Google Doc.

It’s still possible to get feedback somewhere else.

The decision point

Now it’s time to decide how to proceed.

Option A: Based on the Feedback, loop back and create another draft with the implemented feedback, and record another Loom.

You should do this when there are a lot of questions, or different opinions on your draft. Basically when your team is not fully aligned yet.

The likelihood of this design being signed off by leadership or shipped is low.

Option B: Do some smaller fixes and finalize the design/document.

You should do this when you only get a few minor comments, or a lot of “i like this a lot”-type of comments. This means your design is generally in sync with what the others think.

The likelihood of this design being signed off by leadership or shipped is high.

4. The “Go-Button Meeting”

In my remote-work-fanboy opinion, you only need meetings to decide things.

Making a decision asynchronously is incredibly hard and takes a lot of time, however the outcome is usually a clear A or B, or A, then B, then C.

Now that you’ve created a draft, got feedback and implemented it, you want to present the final version to your team or client, to get approval and finalize it.

Without this meeting, even if everyone agreed to your Loom presentation, people might feel left out or that they miss information.

I could write a whole blog post on how to run good meetings, but here are the essentials:

1. You lead the meeting
2. Invite only relevant people
3. Share the agenda before and at the start of the meeting
4. Present your final design/document/idea in a way that everyone gets it
5. Provoke a decision (and manage the discussion)

Essentially, you want to discuss if you can press the go-button on this and ship it or if it needs rework (or it’s not relevant anymore).

I like to use Figma for presentations like this, as it allows me to present slides as well as clickable prototypes.

5. The Handoff

Once your team is on board, you finalize the design, move on to the next step or hand it off to the developers.

Doesn’t matter if you designed a new screen in Figma or a user flow in FigJam, you need to hand it off, a.k.a writing documentation, moving the file in the right folders, and more. Depends on the company really.

The important thing is that even after 2 months you should be able to find the final result and what led you to it.

Final Words

Cool, you are done, and the hero of the team.

Without interrupting anyone else’s workflow, you still managed to get your whole team on board and slowly turned a draft into a finished feature.

And you saved a sh*tload of time, as you did not go back and forth with feedback, but structured the whole process around getting feedback in the first place.

The Full-Stack Designers Toolbox:

Visual Design

Use transparent colors in designs, especially for hover states.

Adham talks about it in his book about Practical UI Design.

Research

Do you have 5min to help me with my research?

I started this newsletter only a few weeks ago, and I would love to know how you like it, or what we could improve.

You can share your thoughts here.

Business

Like packaging for products in the supermarket, your designs also rely a lot on how you present them.

Does the audience have all the context they need?

Can you present complex topics in a single slide?

Does it seem important to spend 15min listening to you?

Answering these questions will help you present your designs and get approval more often.

Tools

Honestly, Loom. I would consider myself a power user haha

Collaboration

In the beginning, I shared Loom links to 12-person products teams and while some people shared feedback, the most important ones didn’t.

What really helped was to set a deadline to review the video.

“Please provide your feedback until tomorrow 5PM”.

That way, people are more likely to watch it.