Last updated: 


How to make friends and influence designers

In my career, I've been used to being one of one or one of two designers on the team. It was always a pretty lonely experience but also empowering because I was the sole design decision maker, or, I only had to convince one other designer of why we should take a certain direction.

On the flip side, I ended up missing out on a large chunk of design education. I never had the benefit of learning from my peers or gaining lots of great feedback through structured critiques.

Somewhat arrogantly in the beginning, I told myself that I didn't need that. Not that I knew enough about designing but that I could figure it out on my own. That being part of a bigger team would dilute my influence and I'd be worse off in my career.

The truth is, being part of a larger design team that offers a structured critique process is actually one of the best things you can experience. But only if your team defines a process.

Never forget Context

When I first joined Moneybox, we were already actively doing design crits on a Friday afternoon. They were a relatively informal affair and we'd show up, say if we wanted to show some work, then jump into an Overflow file or Sketch file and just zoom around the canvas sharing some relatively unfiltered and unstructured thoughts about our design and open it up to the room to comment.

The problem was, there was little to no context. As a growing company, we're split into separate workstreams which we call missions. This allows us to separate our individual strengths and deliver across the different areas of the business. As a design team, we're no different. We split against these missions too and whilst this makes it a lot easier to focus our individual energy on a specific and consistent area of the business (such as Payments or Retirement), it also means our knowledge of the wider design changes is fragmented.

As such, context is really important when we share our work with each other. Without proper context, we lose any hope of offering great feedback. However, it's very possible to over or under contextualise, and finding the balance can be extremely tough.

So how do you create good context?

Firstly, utilising slides is a powerful approach. Much like presenting your portfolio to get a job or sharing a monthly update with the wider business, slides offer a set of constraints that ensure you don't share too much at a time. They act as a container for your explanation and ensure that you must only show the highest clarity visual explanation of your solution.

It also offers a way to create a proper sense of storytelling and setting yourself up for success comes from setting up a great story.

Using a design process to build your story

  1. Start with what you're going to share
  2. Set the business context / business problem
  3. Define your customer problem statement (if applicable)
  4. Share any hypotheses you have
  5. Show a couple of experiments but never more than three
  6. Showcase the solution you're most convinced solves these problems
  7. Ask for specific feedback on your designs

There's plenty of other approaches to storytelling and lots of great articles on what you can do, but this is the approach I always aim to take.

You may ask "what if my work is still really early stage?" Or "I don't have a problem statement". Well, you're in luck, this process still works.

If you're in the early stages, the only difference should be the fidelity of the work. You can also show three experiments and ask for your team's thoughts on which direction to dig deeper into.

If you're more focused on the earlier stages and don't have a problem statement. Front load a bit more heavily on the context and ask for support in getting to a great problem statement. But, remember that a crit session is aimed at providing feedback, not solving problems. So be careful of converting it into a workshop. Always ensure you have a starting point which you're asking for feedback on, rather than asking your team to help craft it.

A critique is not a workshop or ideation session

I've seen crits turn into sessions where a designer is essentially trying to solve their problem by getting lots of design heads together. This is important, but it's not the goal of a crit. A crit is intended to receive **feedback **on an approach, idea, solution, not to get the answers to your problem.

As a designer, it's your responsibility to bring your ideas to the table and create enough context to get meaningful feedback. Going into a crit expecting your team to solve your problems is like going to a bar and expecting the barman to drink your drink for you.

After a few failed sessions, it became clear to me that slides were necessary. But rather than enforcing that approach on the team we chose to take a "learn by observing" approach.

I went into my next critique armed with a well considered deck that followed the earlier process.

I shared my work, got excellent and actionable feedback, went away and updated my designs and presented them back the following week to high fives all around. The process worked, and worked well. But what I also noticed was that most other designs on the team came to the next session armed with excellent presentations and the process continued.

A critique is not criticism

Something I struggled with earlier in my career was receiving feedback. Feedback often felt like a criticism of my work, of me.

It's very common in the earlier stages of your career to feel emotionally attached to your work. To think of the design as a little piece of you. But the truth is, it's just an artefact. A fragment of an idea that you've been the one to extract.

It took me several years to learn to detach "me" from the work. Whether that's my id complex expecting instant gratification for the work I've put in to everything or just because of the time it took to create, it's been hard.

But detachment is key to getting great results. A critique shouldn't feel like it's harmful or personal. It shouldn't feel like an attack. If it does, there's two things wrong:

  1. Your critique isn't structured well for feedback and the context isn't clear enough
  2. You've not been able to disconnect yourself from the work

Number 2 is harder to solve, that's something you'll need to take time to work through. But number 1 is the point of this article.

Through a great design process and through structured communication, you can ensure that crits don't fall to criticism. If you feel personally attacked, it is likely unintentional but it's worth discussing with the other designer(s) afterwards to resolve the personal conflict.

The other approach is to be very clear about what you're not looking for feedback on. That'll help structure your feedback and help the rest of the team narrow in on what you need.

"I'm looking for feedback on the execution of this new call to action style. What I'm not looking for is feedback on the illustration or customer journey as I'm not able to change this within the project scope".

Being upfront and clear avoids any confusion or misinterpretation. And if someone feeds back on one of those things, politely explain that it wasn't in scope for this session and move the conversation on.

Continuing a great process

As we onboard new designers to the team, again, we don't explicitly mention that we should follow this process anymore. It's not that we can't, but we just don't need to. By default our team shares in this way and new designers learn by observing when they join.

One of my team mates built a fantastic presentation library in Figma that we leverage for crafting our crit presentations. These have become so admired that our wider business want them for their use too...

Every week now, I look forward to our crit sessions and see them as a valuable opportunity to offer my recommendations or to ask lots of questions. It's a safe place for designers to push each other out of our comfort zones or challenge and approach without it having to feel critical or unreasonable.

Our crits are completely invaluable to our process and our success.

Squaring the circle

Ultimately to bring it back to my origins. I thought that joining a bigger team would lead me to have less influence but it goes to show that no matter how small of a change you encourage, it can have a wildly large impact.

Hopefully you've learnt a bit about "how to make friends and influence designers." Shoot me a message if you've experienced anything similar and let me know if you disagree with anything I've shared.

First published: 

    More to explore