Justin, founder of the branding and digital design boutique studio smalltribe brings a new perspective to our Product Comms Series.
Being an external part to developing a product, an agency for instance, brings entirely new challenges to communication. It’s about gaining trust of the client, but also managing expectations as well as giving and particularly taking feedback.
I certainly did have experiences where I could have used some of the advice Justin is sharing in this episode! I hope you guys can take something away from it.
✅ Overcommunication can be beneficial: Documenting decisions, explaining rationales, and using tools like Loom for walkthroughs can enhance understanding and transparency.
✅ Structured Feedback Helps: Directing clients on how to provide feedback, considering the project stage, and consolidating feedback through a single channel can streamline the revision process.
✅ Subjectivity in Design: Recognizing and managing the inherent subjectivity in design feedback is crucial for maintaining creativity while achieving project goals.
Justin (00:00)
Yeah, sure. So without being too specific about the project or clients in that sense, of course, but over the years, if it was in the freelance time or now, it's the studio, communication plays such a huge role. And we've realized that over and over again in many ways, sometimes the hard way, sometimes in a good way that things just worked out.
because our processes and the way we handled things were good in that sense. But many times we realized that the right process for communication, the right tools and the right setup and the tonality and the personalities on the other hand, like on our side and also on the client side, there's so much involved, so many nuances and specific things that you have to consider in the communication to make sure.
The thing that you say and you think is right and the thing that the other person receives is still somewhat the same and you're in the same picture. Yeah. So that's a pretty, pretty big topic. Definitely. Yeah.
Jack (02:38)
For sure. Yeah, that makes sense. I think there's one thing about how you say it. And the other thing about how someone receives it and how they understand it, right? They say kind of communication is that two sided piece. Uh, so you have to ensure that they really, they really get it. And they understand it. Um, dig in a little bit more, if you can, to, uh, a situation, you know, without kind of naming a client per se, but like tell us a little bit in more specifics about the situation where it didn't work so well.
Justin (03:06)
So I think the interesting part is, as mentioned already, even if it went well in many cases, it was quite a lot of work to dive into the nuances of how the specific client was communicating. So that's just a fundamental hurdle that can be there. But specifically, we had...
a couple of projects, I think, but one in specific where, how can I say it? Like the way of providing feedback, like this general thing, like not everyone can do it in the right way. It's still amongst us designers or internally, it's a big hurdle to provide feedback the right way. But we had a client where this was like, let's there was no,
value in that sense or the way they valued our work in terms of how they communicate and communicated was pretty rough so to speak and it just felt hard and harsh on so many levels along the way when they were providing feedback and with a couple of calls and trying to align on like do we understand it the right way, do we understand it the wrong way, like what are we missing maybe, is it just on our side.
But it was not really getting better in the end. So the type of feedback they provided and the way they provided this was just, yeah, pretty rough in many ways. So I can't make it even more detailed, but like it was comments in Figma, for example, or this fundamental thing of just criticizing the negative stuff, right? Without pointing to what has been good.
Which by the way, I think is even something I'm guilty for myself sometimes, especially during the day or if you're working along several projects and stuff. It can be maybe also German mentality, I don't know, but pointing towards something that is obvious to you in that moment, that it's not right, so to speak, or if it's objectively not right, or where you think something should be different maybe. Yeah, to then still mention that the positive part obviously that is
Jack (05:32)
Yeah, sometimes it feels like you, you don't mention the positive parts because, you know, if it's positive, then I don't say anything. And then if it's, it's just pointing to the bits that the need improvement or, um, or that you want to give feedback on. And I'm a hundred percent guilty of that. I think, uh, especially as you said, like, uh, when it's this quick environment, right, and you don't have necessarily so much t me. So you're sharing stuff quickly. And it's like the, there are some things that are jumping out to you, maybe more than others.
Do you have like a way, and I think generally this, this topic of like design crit and design feedback is fascinating, right? Because it's going on this interaction between designers, uh, between product and design, engineering and design. Obviously then you have stakeholders as well who are also jumping on and giving feedback, maybe without some context as well. Do you guys have an approach that you think works better where you say to, to your clients, you know, Hey, this is the structure in which sharing feedback is most effective or that you use internally.
Justin (06:36)
Yeah, definitely do have a process and we also had it in a similar way back then with the client that I mentioned. So basically what we tried or the principles that we follow is trying to over communicate, meaning that we try to document our decisions and our ideas in comments, in Slack messages or in Notion where our projects live.
and we share with the clients, we record looms. So basically where we go through the design and the decision and we try to explain our rational, the blockers that we have, where we are at the moment and make it as transparent as possible. So also in a verbalized way and with our faces. So that the other end can see maybe more of the intention that is behind, not just in a written way, because it can be, you either write an essay, which not everyone has time to read.
to understand the full picture with all of its nuances. And I think on that level, Loom or any type of video recording tool allows for much more transparent communication and helps you present in a better way and think more about how you communicate and what you put in and So this is what we do on that side. yeah, I think for the feedback itself, we try to direct the client to really
point where they have to put the feedback and how they can put it. So for example, we just recently shared a new branding direction with a client. We had a presentation where I went through it and I got the first initial high level feedback. And afterwards I sent the Figma presentation link to the client and was a couple of bullet points explaining, Hey, this is where you see the directions. Just put your comments in the short way, like X, Y, that this is what they could look like.
in the corresponding slide and try to make sure not to get lost in the details at the stage. So trying to incorporate the stage we are currently working in. So is it something where it's necessary to really get a lot of details and aspects from the client or is it rather high level? So giving a direction there basically to try and not leave
leave it to with too much uncertainty, so to speak, on the client side. Because that eventually helped us or helps us to get the type of feedback that we can work with in a better way. And not, for example, in this case, there are four people at the other end. And I was trying to make sure that they internally speak about the feedback that they have, because everyone has an opinion, but that they provide it via one person and comments from one person. So it's already summarized and distilled and not like one says A, the other says B, and they are not even sure what they want.
Jack (09:37)
Yeah, I think it never leads to a very good result if you have four people and four different opinions coming in and then you're trying to, to solve for, for each of those. Um, but I think there's also something you said, which is super interesting, which is like the right style of feedback at the right stage. Uh, and one thing that I really noticed when we were at N26 was we would show stuff to a stakeholder, for example, and they would, and like, maybe it would be like, no wire frames even, and then they would be giving feedback on copy, you know, and then it was like, wait, you know, that is not the feedback we need. We need feedback on the flow or, you know, one of the techniques that one designer used, which I thought was really smart is to, to make the flow just in black and white. So, uh, she would take out all the color to make it very clear that it was, you know, that it wasn't anything final. And that actually helped reframe kind of the conversation around flow rather than individual screens or around copy or whatever.
Justin (10:39)
Yeah, exactly. That's exactly what I meant here. And I mean, that's true for if it's branding direction, product design, focusing on the flow, on the prototype, on the functionality whatsoever. I think framing is the right word here. Frame the client or the respondent who has to provide the feedback in the right way, because the topic of design or especially product design or product development is such a complex topic. And even with simple screen, assumably simple screen. People can get lost in things that are not relevant at that
Jack (11:14)
Totally final question. I'd be really interested in your, your input on this, but like subjectivity in design, I think is, you know, design is inherently subjective, right? I like, I will look at something and, and have an opinion on it. You'll look at it and have a very different opinion. How do you guys handle that kind of internally with, with design, create and with design feedback, because. You know, you can look at something and it can kind of tick all the boxes, but you may think, oh, this doesn't fit what I would imagine or what I would envisage. How do you handle that kind of scenario?
Justin (11:48)
The last 10 seconds hung up. Sorry. I just got the last words. If you could repeat that, please. Like roughly 10 seconds.
Jack (11:55)
Yeah, I think the signal is not. So what I was saying was, uh, design is obviously pretty subjective and we have different opinions around things and sometimes you'll, you'll look at a design from someone and it will, you know, maybe take the boxes in terms of the functionality you want to create. Um, but you yourself may, you know, may not think, oh, this is how I would, how I would do it, or I don't like it personally. How do you approach that kind of topic of subjectivity when giving feedback, especially within your team?
Justin (12:31)
It's definitely a challenge. It's not easy. And I can say that given my role at the moment as a design director, mostly looking from exactly that perspective, like obviously we do have feedback across the team from all sides and we're all in the same level when it comes to the collaboration part here. But it is challenging first and foremost because sometimes
Getting stuck with your subjectivity is what strikes in the very first moment when you see something. And so what I try to do and sometimes it's work, sometimes not depending on the days and stress level is to zoom out a bit and first get the bigger picture of what has been designed there. Do I have all the information about the design? What has been the process? Like are there...
many other versions that I haven't seen maybe. And this is a version that has been decided upon for reason X by that. So just getting the information, the rationale, why this there, what I see. And in terms of subjectivity, what we try to do internally as well with the clients is to set the direction and the strategy in the very beginning. So we try to explain and describe.
and also enhance visually what we want to achieve as good as possible by describing the idea and the goal that we have. Without being too limiting, obviously, like, okay, this is something we like, copy that, by the way. It's more like, okay, how can we try to frame it again without being too restrictive and too limiting, but providing all the information that a designer needs in order to design something that ticks
the marks or text marks that you mentioned, but not just functionally, but also from a design perspective. But I'm sure in the end, there's always a certain level of subjectivity for sure, where you can go into the details and discuss endlessly. We do have this as well. And I think it's also something good eventually. Otherwise, it's blueprinting stuff in the end, maybe where you just try to squeeze something through
Jack (14:54)
Yeah, totally. You have to leave a little bit of space for that subjectivity. Justin, that was super interesting. Thank you so much for your time. It's been great today.
Justin (14:59)
Yeah.
Thank you. Bye bye.
.webp)
.webp)
