The ideal process expects you to start from a place of curiosity and openness. You approach a problem without assumptions and bias. You gather relevant data. You talk to users. You map their journeys, dig into pain points, analyse insights, prototype, test, iterate. It's rigorous, unbiased and rather time-consuming. This is the research-first end of the scale. And when you're lucky enough to operate here, your solutions tend to be more targeted and meaningful. But how often do we actually get that luxury?

More often than not, we're handed tight deadlines, fixed roadmaps, pressure to ship. In those moments we often lean on experience. We assume and make informed decisions. We identify pain points based on past patterns, industry knowledge and sometimes even intuition. We prototype faster, test lighter and ship with an eye on iteration post-shipping. It's not wrong, it's necessary. This is the solution-first end of the scale, where design becomes a strategic act of prioritisation.

The key is recognising that both ends of the scale are valid. They just serve different purposes. Relying on assumptions isn't neccessarily bad design, it's just fast design. But you must be aware of the risks. You might miss nuances, misidentify root causes, or design for the wrong problem. That's the cost of speed. On the other hand, thorough research may give you a better view, but it doesn't guarantee a perfect solution. By taking more time you might lose momentum, stakeholder buy-in, or market relevance. That's the cost of time.

As designers, we should be aware of we are on the scale and align our process to the time and resources we actually have. This means being honest with ourself and the team. If we have a week to redesign a feature, we shouldn't pretend we are running a full discovery sprint. But if we're building something foundational or strategic, we should aim for the time to explore it.

The question I often ask myself at the start of a project isn't “What's the right process?” but rather “With this time given, what can I do well?” Sometimes that means designing with constraints. Sometimes it means designing at speed. But it always means designing with intention.

Ultimately, great design isn't about following the perfect process, it's about making the good choices within the constraints you're given. That's the craft. And over time, what separates experienced designers from the rest isn't how much they do, but how well they balance the scale between time and process.

There are stretches where I am moving a lot of work, churning through tasks, putting my everything in it and sometimes I am mentally drained at the end of the day. The quantity of output might be high, but the actual impact is surprisingly small. The product and the business have not shifted, my design approach is not meaningfully better. And even though I might have a brief sense of accomplishment, ultimately I feel like I'm stagnating.

But then there are other moments that feel almost effortless. A conversation that reframes a problem. An idea I have that simplifies a process. A design insight that changes how the team thinks. None of these things are considered hard work, but the ripple effect is enormous. My work and therefor my motivation improves in ways that matter. The team finds clarity and the business feels the benefit. And often I end the day more energised than when I started.

Ultimately if find (Design) work is not measured in hours spent, but in impact created. Sometimes impact comes from relentless execution, but more often it comes from finessing the process, paying attention where you are in the design chain and trying to improve it. I remind myself to care less about being busy and more about having impact.

But even when the strategy is solid, what really gives me pride and satisfaction is often the details. Having the time to create a micro-interaction that is surprising and thoughtfull or a smooth transition that makes a user flow feel natural. I sometimes find myself admiring copy that is just so on point or that is feels brilliantly clever. Those things might seem futile and are often overlooked, but for me they are the difference between something that works and something that resonates.

On the positive side meetings can align teams quickly. They allow for a certain type of nuances that Slack or e-mail cannot capture, like tone and body language. Good meetings accelerate decisions, clarify priorities and create a shared sense of accountability. When things are complex a well-structured meeting or workshop can be the best way to align on ideas.

But the negative side is hard to ignore. Meetings often disrupt people's deep focus required for design or dev work. An ad hoc or poorly scheduled meeting can be detrimental to a productive day, leaving you behind with a scattered brain and unfinished work. Lots of meetings also have too many attendees, lack an agenda or rehash discussions that could have been resolved async. Those meetings are not just inefficient but also frustrating.

So are meetings a necessary evil? Perhaps. They are necessary in that human collaboration requires dialogue. But they become evil when they multiply without clear purpose.

Over time, I've learned a few actions that helped me and the teams I've worked in to get the most out of meetings:

• Use other channels. Ask yourself if a meeting is actually the right channel. Can I gather information async (eg. Slack polls, async design critique, email, etc)
• Protect rhythm. Agree with your team to cluster meetings to allow for long stretches of deep-focus work. Keep to morning stand-ups and/or fixed time rituals.
• Come prepared. A clear agenda with supporting visuals or resources allows for clarity on scope. If you require anyone to bring or prepare anything, let them know beforehand.
• Keep it lean. Invite only those people who are essential to the decision you're after.
• Close with actions. Every meeting should end with everyone knowing what to do and by when.

Meetings will never disappear and nor should they. But if we treat them as a design problem, optimizing for clarity and outcomes, we may finally learn to use them as the tool they are intended to be.