Deep Dive
Shownotes Transcript
You start by saying what's the objective of the design, the problem and what it's trying to achieve. And then you present the elements of the design that tie to that particular objective. And then you ask people, do you feel that these elements are effective in achieving that goal? And then discuss it. Why and why not?
Hello, everybody, and welcome to the next episode of Honest UX Talks. Today, we're going to talk about communicating design progress and asking for the feedback. That's one of the listeners submitted question by Itham. Thank you so much for submitting the question. The question is actually consists of three parts. He added questions all around the same topic. So we decided to pick it up and actually break it down into three parts.
questions. Very excited about it. I think it's a very, very important part of everything we're doing, collaborating, communicating, and asking for feedback. But before doing that, we actually have Joanna back. So, Joanna, how are you doing? How was your last two weeks? We were missing you. Yay.
Thank you. I missed you all as well. I missed you very much, Anfi, because we didn't get to have our honest UX chats. And so that was one pillar of inspiration missing for the past two weeks. But I had other pillars, new pillars for inspiration, because as some of our listeners might know, if you're following me, I've been to the US to
Austin, Texas, attending South by Southwest. And that was for me a dream come true. This was actually a ticket that I acquired in 2020. And then of course, it got canceled. And I kept postponing because I had a baby. And so this was like, three years later, finally, I was there.
And South by Southwest was definitely everything I imagined and more. If you know this festival, it's a really big festival that initially was just about music and film and some art. But in the past few years, they added a tech track. So for the first couple of days, there were mostly tech tracks.
talks. So there was a design track, there was an AI track, machine learning tracks, all sorts of the new juicy topics. David Sinclair was there talking about biohacking, so a lot of medical stuff, medical advancement, so just the new things that are happening in technology today. I was like on this, let's say, this
Sprint marathon. I don't know how to call it because I kept going to as many talks as possible, sometimes five talks per day. And it was exhausting, but it was also very nourishing intellectually because I was infused with new ideas that otherwise I wouldn't make the time to visit.
read articles about biohacking and stuff. So I don't have the time to do that. But in this setup, I could expose myself to different ideas, fields, news, and so on. So that was very exciting. Just a couple of observations that probably might be interesting for everyone. Of course, we all know that AI is the name of the game. Like literally every conference
I went by people, they were talking about AI or chat GPT or something that had to do with the way the world is changing. I have a couple of observations about that. Maybe I'll do a one off podcast by myself where I tell people everything that I've learned in this conference and in the past year working on. So I don't have one year working on an AI product, but I have six months now and I've been immersed in the space and I'm going to have some talks. Hmm.
none of them are announced yet, but I will have at least one in May, one in June talking about AI and how that will impact the careers of designers. So that's going to be very interesting because I think we are all on one hand excited, on the other hand concerned on how our jobs will change. Are we prepared for that and how to build the right mindset? So I will talk about that formally, but also maybe we could have a podcast episode about that in itself. I think it
It might be interesting. So feel free to text us if you want this episode to happen because I need the motivation. Just jet lag, you can imagine going to the US. I felt like very tired. I came back from the US very tired. A lot of work that accumulated.
just trying to survive and I think that's my two weeks in a nutshell and I know you've been doing a lot of interesting things at least having interesting conversations with our latest guests Sarah and Tanner I'm a huge fan of both I was super excited to see them join and if you haven't listened to their episodes make sure you do and yeah how about you how did you spend the last weeks I
I mean, not as exciting as you, I guess. I wish I could say the same. I feel very jealous of that. I feel like it's the best thing that happens with us in our industry. All those events for me, it's always the best timing I can remember, best memories. It's always obviously very tiring, but it's just this energy you get and
And then it's so hard to go back on track with your like sometimes dull routine. So I can't imagine how hard it is for you right now. Yes, every time I was seeing your photos and it reminded my student years when it was all so easy and breezy, lunch outside, great weather, great people, a lot of interesting insight to digest. It's just beautiful. I mean, I was definitely jealous of you. Yeah.
Maybe one day I'll also go for that conference because it looked really nice. But yeah, my two or three weeks were not as great because I got sick. We had a conference at my job and it was really fun and cool. We had like the whole R&D, which is basically people who work on a product came to Prague. We have two days event. So it was really nice to see everyone, to hang out, to party a bit. But yes, there was this little virus going on.
And so after the conference, half of the product, so like 200 people or something, got sick. It was insane. We had like this R&D conference virus going on. And yeah, I'm still kind of recovering after it. It's a bit crazy. I think it was some sort of a COVID or maybe flu. I'm not sure exactly, but it was really strong. But like you said, yes, the thing that keeps me excited and motivated, I guess, was trying to keep this podcast up and
And we had really amazing guests. So yes, make sure you check them out because I think those are really gem episodes, both of them. Other than that, nothing too much. I think I'm still going on with my work. Actually, we started the new project. So it's going much better this time. Remember, again, I talked about shape up process. We had a two weeks cool down period when we were planning the next project. Now we started the new project.
It goes much, much smoother because we actually had the preparation time and now it's kind of easier to communicate, navigate, share the progress to the point of this topic. And everybody's more aligned with what design needs to be like. It's still in progress, but everybody knows the direction and it's just much easier to communicate it. So yeah, very happy that we at least have more buffer time this time and can work productively.
And also I will have two small things coming up. So next week, I also have a presentation or talk here in Prague offline. Very excited for this because I haven't been doing offline talks for a while. First one is about how to find your niche in design. It's a very, very juicy topic because many people feel lost. There's more and more UX titles coming up, specialities, niches. It's just so hard to understand where you fit in naturally. So that's what I'll try to talk about.
And then I also am about to publish another template, which will be about CV or resumes that will be ATS friendly. Because what I'm seeing today in the market is that there are a lot of people sharing resumes. A lot of great designers, to be honest, are sharing like resume templates. But there is one big problem and I can't help but like being triggered by it, I guess. That a lot of people are sharing those beautifully designed resumes.
over-designed, to be honest, graphical resumes. And they never did research for some reason to check that those kinds of resumes never go through the system. So you get filtered out. And as the candidate, especially applying for a product company, especially for a serious product company, your resume that doesn't look kind of boring and standard and doesn't capture most important sections
in a format that is system-friendly, ADS-friendly, you're just literally eliminating yourself from that bulk of people, from hundreds of people who apply to that role. So I actually want to emphasize the importance of the structured resume and that it's really not a place for designers to show their creativity, but to actually structurally explain the key bullet points of their career progress. So yeah, that's something I'm going to publish next week. And yeah, that's kind of it.
Let's get into the topic. I think I was talking a little bit too much. Alrighty, basically the topic of today is again, communicating and sharing your design. Thank you again, Idham for submitting the topic. The topic is consistent of three kind of sub questions. So let's just get started with that. The first part of the question is sharing the progress, right?
There are three aligning questions to this because when we're talking about sharing the design, sharing your progress, we're talking about three types of things. First thing, sometimes you don't have a space for feedback yet because maybe you have this recurring weekly syncs and you're just sharing in which stage you are, where you progressed, maybe some concerns you're having. So really what you're looking for is just alignment.
Second part is that sometimes you're actually open for the feedback. Maybe you're in the right stage. There are typically two main stages in the design process when you can ask for the feedback. Usually it's either in the very discovery, first like conceptual stage, very high level when you're trying to understand the direction the whole team should take. And then second is more like validation or even testing when you want to actually get the feedback on like details, copy, I don't know, icons, small things, like really the interaction part of things and stuff like that.
In those two spaces, maybe you're open for the feedback and then there is feedback tackled to different audiences, right? There is a feedback for your technical partners, maybe PMs, maybe the design team, maybe sometimes all together. And the sub-question that Inham also shared with us is how do you present it in a way that you're not dominant, that you're not saying, this is what we're going to do. This is my design and no questions asked, please. So how do you
presented in a way that everybody feels included, aligned, contributed, and also give you the constructive feedback. All right, huge intro. Let's dive into it. Ioana, how would you say the feedback is different from sharing progress and when you should do what?
It's a big question indeed and a big intro. I'm going to try to take a stab at it like answering this and pick some parts and try to unpack them. I want to start with a distinction. So I think that the best conversations happen when they're in a way led or
they have boundaries, they have a clear goal, they have, let's say, constraints. So there are rules to that conversation. So these are, let's say, formal feedback sessions when you go to your team in whatever setup, like some of the setups you've mentioned. Sometimes it's a technical meeting, you're meeting with developers and you're going for
particular kind of feedback. And then you might meet with other designers, your peers, and maybe designers that are not on that project. And you're just trying to get like fresh eyes, fresh challenges, and so on. And that's a different kind of feedback. So regardless of the setup you're going for, you can structure that conversation and you're going to get probably less annoyed.
If you are very clear about the goal you have in mind when you open that conversation, like be very specific. I know there are multiple frameworks for capturing feedback, but essentially I think what most of them have in common is that you tell them, hey, today we're going to be looking at this particular problem that I tried to solve. Here's the problem. The user is unable to do whatever in the platform. So we were trying to find a way for the user to be able to achieve that particular task.
This is the solution I'm currently at. Maybe you could show some different explorations, like here's another thing I tried and why I decided to not go for it. And here's another thing I tried and why I decided to not go for it. So this is how I decided to solve the problem.
And now I'm looking for feedback on that. Or it could just be, I just want to get feedback on the visual layer of this design. Like just let's look at the UI and tell me how you feel. If you're spotting any mistakes, like the inconsistencies and stuff like that. So the thing is that you want to frame the conversation and you're going to get more targeted feedback.
However, even if maybe this is a more, let's say, controversial or it's not a recipe kind of advice, I've personally learned in my career and in my experience so far that sometimes even conversations that feel a bit loose or they feel like they lack structure, they lack direction, they're just, let's say, reactive, impulsive, emotional conversations, sometimes they elicit interesting feedback as well. So sometimes I would just rapidly pop up the work...
I'm currently doing in a meeting and tell them, hey, here's where I'm at. It's not final. It's work in progress. Treat it like intermediary stage to something. But tell me how you feel. Tell me how this looks. Tell me if you spot any problems, if you feel like the problem I'm trying to solve is addressed here. And sometimes even less formal feedback, let's say capturing can surface a lot of interesting insights.
So where I'm trying to get with this point is that you could go for a very formal, framed, controlled conversation, and that's going to give you better clarity on the particular design goal you were trying to solve. Or you could just have random feedback sessions, sometimes even go to the desk of your product manager or your developer or whatever and show them, hey, here's what I've done today. What do you feel? And just rapidly pick their brains. And some things will still arise
even if it's not very formalized and not everyone is at the table and there's no control path. So my point is that there's a time and place for all types of conversations. The point is to just have these conversations. So just go ahead and ask for feedback as often as possible.
And then I think later in this conversation, we can move deeper into how to ask for feedback. How much feedback do you want to incorporate? How do you politely tell people, hey, thank you, but I'm going to go for my thinking, my particular solution. How do you operate with things that might hurt your ego and stuff like that? Let's go into that later. But for now, the point I want to start with is that feedback is a gift. Yeah.
It's very important. You can design without feedback. Ask for it as often as possible in different setups and contexts, depending on your needs. So yeah, pretty generic conclusion to my first point. But I want to hear your thoughts on feedback in general. And if you want to dive into any particular place of this conversation. It's actually a beautiful context setup for our conversation. I think I totally agree with Juk.
main point here is that every time you're about to communicate your design and we're talking not just about the feedback by the way it's also about the communication the progress updates alignment and stuff like that i think that's an equally important part because it's very hard to dive into details especially if you're looking for like specific kind of feedback without alignment without people understanding why we're even doing this sometimes people actually need extra sort of homework or
extra knowledge up front. But what I'm trying to say and what I'm agreeing with you on is that every time we're communicating our design and opening it up and sharing it, right, not closing ourselves in a small little room in a bubble, being afraid to show and expose ourselves, because that's obviously usually a very like junior or early stage designer mindset.
But every time we're communicating our design, and it's very important, it's a huge part of everything we're doing, we always recommend to be prepared and set up the rules. This is like a bottom line. Without preparation, it's very hard to tailor your message and be specific about what you're looking for. And also without rules, it's very hard to navigate that dynamic, especially having different audiences.
and working with different audiences. So with that bottom line in mind, right, preparation is important. Rules are important. A few things I want to mention also to set up this scene for the conversation is that why it is important is because every time you're opening up your design to the audiences, to different types of audiences, you need to tailor your message because designers will want to hear maybe the story, the
process, the details, the things you have explored, the things that worked and didn't work. This information may be irrelevant for other type of stakeholders, for technical stakeholders. They don't care how many explorations you did. They don't care how broad you went, how divergent you were in your process. All they care about is like, what's the direction? Give us something more specific, something that we understand could be
And it doesn't mean that you show them like 20 options or different concepts, but give them more like two or three directions where they can discuss and kind of give you the suggestions around the best approach for us, for this project, even against strains, given the goals of the project, right?
It's really important to keep in mind who are you presenting to. And without preparation, you will have this default speech, all sides fits all. You'll kind of do this very long and sometimes even boring story that people will not understand or will not need to hear.
That is why preparation is important. Tailoring your message and the story for different audiences is important. Also, what I think is very important every time we're talking about communicating your design is kind of setting up, let's say, process, but also ceremonies, maybe like stages and ceremonies. Because one thing...
that you don't want to happen is like a cause in the process because if you are not very sure about where you are right now in your stage and what are you trying to say to whoever is your audience, you will start people being confused around...
what feedback are you trying to get from us? Like, are you looking for like exploratory feedback yet? Are you looking for specific like design details, copy feedback? What are you trying to learn from us? Because people on the opposite side who are trying to understand the design and giving you the constructive feedback, they will also need to be navigated in like, what do we need to focus on? We can focus on 55 different things right
now what do you want from us right so again kept coming up with some sort of process of stages and ceremonies would be as for me very important to communicate in your design and what I mean here is that usually try to break it down into like sort of sinks so basically
either with my team or with my design team. Usually I'm reporting or hearing the progress with two types of stakeholders. Design team that doesn't work specifically with me on the project, but they want to be a part of that because we are still part of the same product. And then the actual product team, right? Who's going to build it?
And so with both of those teams, I try to create like some sort of cycles on how often we communicate, like singly, weekly, whatever. So it's either recording like videos with me sharing the progress on the week and everybody understanding the context on the same page, or it's actually some sort of standups twice, I don't know, a week or three times a week depends on your cycles where everybody's again aligned on the progress and understanding where you are, what to expect from you next.
stuff like that. And then everybody's aligned, right? Synchronization is happening. The second part of it is to be open for the feedback. It's what Ioana was just telling to us. Really trying to set up some sort of feedback cycles, as for me, is very important. Because if you ask for feedback literally every second, sometimes you're like, you didn't even progress so much.
and you're already asking for the feedback. So you kind of need like this time when you're exploring, you're designing, you're doing your thing and then you're opening up again and getting, you're having this perfect space right now when you collect the feedback and you have energy and time to digest it and update it. But then again, you need some time to update everything to be open again to the next stage of feedback.
So usually I try to communicate with whatever team I'm working with. How often are we going to get those feedback cycles? Is it every two weeks? Is it every week? Again, depending on the group of people you're working with, because every company is different. But it's very important to set this up in an upfront. First time you're doing the feedback, you want to get like the general feedback around, hey, here is the context. Am I missing something out? Is there something I didn't think about that we need to consider for the project? So setting up the context, right? Maybe
Maybe next time in a week or so, I want to start exploring it and I want to show all the ideation stages and all the ideas that I come up with. So maybe that's when I'm open to like more ideas or maybe somebody can tell me which directions they believe we should go for. And then moving forward again in the next cycle, maybe you want again specific feedback about the icons, the interactions and stuff like that. And so what I'm trying to say is that there are two types of things, right? First, preparing and tailoring your story to different audiences.
Second, preparing these ceremonies and stages when you're giving the progress updates. And then how often you ask for feedback and what kind of feedback it is. Where are we looking at the moment, given your project progress stage? I guess that's all from my side in terms of setting up the stage for the communication and opening up your design. I think an important part of it is really trying to navigate the conversation, right? So once you have the process, once you have agreed on the rules,
Actually, talking about the rules, there are the two things that I think we need to discuss is how do you set up those rules for communicating or asking for feedback? And the second one is really how do you make it constructive? Because we all want to avoid the situations when whoever we work with is asking us to make the bottom bigger, right?
We're giving you this very reactive, I don't like this color kind of feedback, which we all hate, we all want to avoid. And that's always one of the challenges for designers, especially early stage, to kind of set up the scene in a way that people don't feel inclined to giving the feedback.
What is your take, Ioana? Before I answer that question, I just want to add something to the, let's say, setting the scene. I think that you've touched on it. I just want to build my own perspective on how important it is to kind of understand the setup of your team, organization, product, like the flavors of how your company collaborates, and then find a process that you can rely on that works for you in that ecosystem, right? So a very quick example of where I'm currently at within UiPath, because I'm
working as a senior designer from Romania, but the rest of the design team I'm working with, specifically another senior designer, the manager of the product I'm working on, and then the VP of design, which is my direct managers and UX researcher. So the rest of my design team is based in Seattle. So we have to, this is a very, let's say, particular context.
for us, right? We're on a 10 hour time zone difference. So we have to make the most of, okay, working around the clock, but still being able to efficiently sync. So this is something that's particular to this project. And then other things that are particular to this project are that we have been doing a lot of like the state we're in, it's an incubation product. It's launched now,
We're learning. We're doing a lot of research. We're trying to de-risk all the assumptions and everything and learn as much as possible. So this is the stage we're in. So take factor in when you go for a process or when you try to figure out how often do I ask feedback? Who do I ask feedback for? Who do I need to build alignment with? How do I make sure that everybody stays on the same page and so on? Factor in the kind of particularities of your project.
And so for me right now, what works is that I sync with the senior designer, the researcher every Monday, and then on every Wednesday, the entire team syncs, the entire design team, as well as the product manager is there. And then we also have, I joined the daily syncs with developers and then give them feedback on how they implement the design, but also ask for feedback for the latest thing that's going to go into implementation. And so find a recipe, right? But that recipe
isn't universal. It always depends on the context, the setup, the specificness of your organization. And so that's the last point I wanted to make on setting the scene. And remind me what the question was. How do you build the right mindset? Well,
Let's start from the first sub question. How do you prepare the rules, right? You mentioned a little bit something along the lines of having the rules for the feedback session, feedback session or sharing session. How do you navigate it? What are the rules? Who comes up with the rules? Yeah, there's a book that I want to recommend. We're going to link it in the show notes. It's called Discussing Design. It's a book that really helped me understand how to collaborate better and how to have conversations about design. So yeah, Discussing Design. And this book
kind of proposes a framework for asking for feedback and setting up the rules. That framework is very essential. So you start by saying what's the objective of the design, the problem and what it's trying to achieve. And then you present the elements of the design that tie to that particular objective. So this is what we need to do here. These are the things that achieve that goal that we're going for.
And then you ask people, do you feel that these elements are effective in achieving that goal? Do you feel that I am solving the problem that I'm trying to solve? And then discuss it. Why and why not? So you always tie everything back to a goal or the thing that you're trying to achieve. Now, sometimes it might happen. And in my case, it happens very often that I end up in a creative block.
Or let's say sometimes I'm in a point where I have two very strong concepts that I'm unable to choose from and maybe we don't have the time and space and freedom to test them. And so sometimes I just need help. Right?
So sometimes it's just not capturing feedback, but asking other people to help me unblock and find the next step or the next direction for my iterations or making a decision on a UI level or whatever point I'm stuck with. So you set the rules to answer your question. To set up the rules for the conversation, you have to have a lot of clarity on what you're trying to get out of that conversation.
And that might vary, right? Sometimes it's just final design, making sure that you're fine tuning it, you're doing the last refinements, you're making sure nothing is missing and so on. Sometimes you just need to choose between a set of solutions. Sometimes you just don't know how to progress past the point. And then you bring people at the same table and tell them, here's what I was able to get at. What do you feel should be my next exploration, my next step, stuff like that. So
It all ultimately ties into the idea of having a lot of clarity and doing a lot of introspection. If you're very aware of where you are in the design process and you're able to articulate where you're trying to get next, then that will kind of generate clarity.
the rules for the conversation because then your job will be to just keep the conversation focused as much as possible. So sometimes if conversations kind of diverge, sometimes it might be good. Sometimes you're going to reach interesting points, but mostly you will want to keep the conversation on track because otherwise you risk the meeting will end and you will have no clarity. You wouldn't have achieved your goal. So you want to steer people back onto the path that you're trying to explore. But yeah, some occasional slips are...
Sometimes they're interesting. So I would say the rules depend on your goal. And if you have clarity on your goal, you'll always be able to reinforce the boundaries of the conversation or the direction of the conversation, if that makes sense. I hope it answered your question. Definitely. I love the suggestion of the book. Yeah, I think there are another one which could be helpful and
in line with our topic today is called articulating your design decisions that's the book i also feel like is very great for people especially who struggle with the communication and understanding how do you present it how do you articulate what you're doing and why you're doing it and stuff like that like
adding the rationale behind your presentation. Because especially in the beginning of our careers, it's so easy to start just saying, here's my design. I mean, it speaks for itself. What should I add here, right? You don't exactly know how to tailor your message. So yeah, for that reason, definitely read that book. It's going to help you with articulating what are you doing and why you're doing it. And one very bottom line tip that I always recommend every designer, especially early stage designers, is to every time you're designing something,
Or even when you're planning the presentation and session, just speak out loud about every single why you did there. Literally every single icon, every single small thing. Navigation. Like, think about those parts of the design, right, you're focusing on right now. Like, you want to set up the rules, say the context, what's the goal, the parts of the design you want to focus on in that session. And really try to articulate why.
Like, why is it this navigation? Why is it not like linear navigation? Why is it hub and spoke navigation? Or why is it this concept? Why do we show this in cards and not in lists or something like this? You really question every single decision you did in that design that you're about to present and explain why.
And maybe also you can say like, I believe in those two directions because they both serve goal. This one in this way and this one in that way. Right. So again, adding rationale helps a lot your team to understand how you think and how it helps the whole business, I guess, to continue growing in whatever achieving your goals. Now, coming back to the question and the topic of the current question, I like that you started talking about the formats of feedback sessions.
That's also a very important part. I think like high level, we can think about the formats in two ways. There is like workshop and then there is like conversation kind of setup. And both could be also designed in multiple ways. For example, in the conversation type of setup,
we have today at my work every Friday design sessions. We have a team of around 30 designers today and we kind of meet every Friday and we have this randomizer of three people joining Friday feedback sessions every time you have new designers joining. And then in one hour every single designer presents what they're working on for 20 minutes and again they plan how they want to present it, which stage they are in, what they need to feedback on, and then the designer's
So basically you present for like 10 minutes and then 10 minutes for the discussion when the rest of the designers are trying to give you the feedback on why they believe one of the directions works or doesn't work. And why it is beautiful, why the live conversation is beautiful as for me, is because you actually have an opportunity to dive deeper into why's. Because sometimes when people say, let's go for this one, especially if you're talking in Figma, right?
I think we talked a little bit about it recently in one of the previous episodes, but especially in the Figma when people are saying like, "I don't like this approach. I don't like these icons. I don't like those, I don't know, radio buttons. Why we're doing this here?" It just doesn't explain the reason. Why do you like it? You got it. Somebody doesn't like it. There are so many opinions out there. So why? Right?
So the beauty of having the live conversation, live feedback session is you can always ask why. And for example, recently I was presenting like three directions for the tables that we need to do. And I was like looking for which direction do we need to go for and decide.
Two designers who were joining me for that session actually explained very clearly that, okay, actually, if we're showing the icon first, the example was that you have icons, the name of the row of the table, and then you have a toggle at the end of the list. And the second option was first toggle, then the name, and then some expand and collapse sort of interaction where you can see what's inside.
And people were very clear. And what I liked is like, again, hearing this outside perspective that, you know, icon gives me a first understanding. I can quickly scan through them. They're all vertical icons under each other. So you can clearly see and kind of focus on the right list. And then the toggles make sense in the end because I first need to understand what is this list? What is this kind of setting? And then I decide if I want to
turn it on and off. And if you have this, you know, toggle in the beginning, then it kind of messes up with my logic because I first see the toggle and then I read what is this list about. So again, like it's people explaining the rationale and before you showing it out there and kind of exposing it to other people, you're closing your...
head and sometimes you're too much into the explorations and you forget about the rationale and forget about the reason and how people scan things or how people understand things. And so you're kind of like in the bubble. So opening up and being able to show it to other people, other designers or other team members gives you the space to understand the outside perspective. And also because, again, different people with different roles, they give you like really rational feedback to their role or to that specific part of our work.
work, right? Sometimes technical, like we would say, this is impossible for us to achieve. It will require us to, I don't know, three more weeks of work. So it's really helpful to know that in advance so you don't waste time and money of the company. And designers will help you understand how people actually scan for things. It's just...
gives you much more information to operate with. So again, the format could be the conversational feedback. And again, the rules should be always the same, no matter in which context you're at, because you need to say what is the objective, what you're working on, what did you do or...
what this target audience needs to know about this project. And then you're opening up it for the space and again, asking to be constructive. That's very important. And the second type of format is workshop is when I would usually say you can have more people. It's when you, let's say, have a team of, I don't know, 10 people and everybody needs to be a part of that workshop session. So it's a little bit harder to navigate because you have
multiple opinions, people with very strong voices, some of them more voicey than others, and you have to navigate that kind of dynamic, right? People talking. So for that reason, I would recommend usually going for the workshop format.
So again, Miro or typically FigJam where you structure the whole workshop. So when you start that session, you maybe want to go for a quick icebreaker so people feel comfortable with each other, asking some questions around the project maybe or something fun
whatever people did in the weekend, whatever it is. Then again, presenting the context goal, then showing the design, maybe being very specific about what part you need people to focus on. And then either asking them to, it's called like in and out kind of feedback, when people calmly fill out the feedback on their own, on the sticky notes, and then sharing them vocally, or actually just asking one by one, all the participants to be vocal about it.
I prefer in and out because this way people can, first of all, write this down unbiasedly and explain their point of view or like, don't forget anything, like basically throw everything that comes to their mind on the sticky notes or paper and only then sharing it so that nobody's influencing each other and nobody's picking up on each other's opinions. Yeah, there is a second format, right? Using the workshops where you navigate a bigger group of people, more energy, more dynamic voices in a more structured way.
way where you literally see the structure in front of everyone. And you can even ask for like more rules to the feedback. For example, you can say, okay, when you're writing on the sticky notes that your feedback, you can please write pluses, minuses, what to improve, and maybe questions if there are.
So you can ask even specifically to structure your feedback. Good things, bad things, what should be improved, what we should prioritize, what are the questions you might still have. These are the things you're designing. This is the way for you to design the workshop in accordance to whatever your stage is, right? Whatever you're looking to get from the people. And that's why preparation is very, very important.
I can also recommend, by the way, here the course by Mariusz Posadowski. I hope I spelled his name correctly. He has a course called Communication Skills for UX and Product Designers. And it's really all about asking for feedback, planning your workshops. So if you need more details and even templates, definitely check it out. I'll leave the link also under the show notes. I hope you got the idea with the formats.
I think the last question we maybe want to tackle in this conversation is really all about being constructive, right? Because every feedback session, it's a two-way street. You need to set up the scene that everybody knows and has been empowered about what to focus on.
write what to give you feedback on but they also need to be constructive in how they give you the feedback again just to avoid that situation when people don't know what to say and they're saying i don't know i don't like the button make it bigger make the font bigger why do you add here the time or whatever like the divider or something like this like these are the things that
always make, you know, the feedback feel weird because they don't explain the reasons why you feel bad. You don't understand their thinking. Maybe if this person has an authority, you think that they know something that you don't know. What do you don't know? Again, all those questions that make you doubt yourself and the design and it just doesn't feel good. And also don't really contribute to the goals of the project. So I think
It's not just about them expecting to be constructive, but also I think starting from yourself and helping people who never gave feedback to be more constructive. So I think what we can discuss here in the last question for this conversation is really how to be constructive and starting from yourself. Because once you show a good example, you also show how to do it for other people and they could also become constructive rather than reactive. So Ioana, the floor is yours. What do you think are the rules?
about being constructive self-awareness keyword so if you are are able to build self-awareness of course you're always setting an example right so setting the rules of a conversation means also coming in that conversation in a
healthy way, right? In a constructive way. So the rules are like a common, let's say, agreement. If you're doing your job right, then probably you're going to generate the same type of vibe around you. So self-awareness is key here because it helps you articulate and own your vulnerable parts, like maybe own the fact that you're stuck and you don't know something and that's fine and you're not afraid to admit it because many designers have this kind of a
fragile ego where it's very hard for them to say, I don't understand this, or I don't know how to get out of this, or I'm not sure this is the best solution. So if you work on just being able to articulate these vulnerable moments and put them on the table, then people will most likely be more welcoming and they will accommodate this vulnerability of yours and the conversation will be healthier, less likely to become in any way arrogant, aggressive, or what other ways people might manifest their...
feedback. So self-awareness is the first thing that needs to be in there. And then I think that you really have to be good at not just setting boundaries, but being able to guide the conversation in a way that feels healthy for you. So most people, I hope that most people working in product and in design, they have enough empathy to be able to come in a conversation without having to offend, without having to push their view too much.
But sometimes it just happens that conversations become political. It becomes like this positioning kind of mission, like who gets to have the final say? Who is right about that thing? And what I like to think and remind everyone at the table, and maybe you listeners could still this mantra, is that it's not you versus me. It's us versus the problem. So what we're trying to build here is the best solution for our users. Let's just be reminded that even if we have...
different points, different positions. We are in an argument right now. We don't see things in the same way. Let's not make it about who's going to win this, but make it about how will the user win this debate, right? So remind people that we're at the same table, going in the same direction with the same goal to create the best experience possible. We're not enemies. It's not me versus you. Again, it's us versus a problem. So that's
Sometimes that happens, right? So not all conversations are handled ideally. Not all conversations go on the optimal path. Sometimes it goes in a really strange place because we're human, right? So when people start talking, sometimes it's not perfect.
And we've all been through those situations. And of course, we all bring our vulnerable self or we bring ourselves to work. You know that there's that famous second mantra I want to mention is that says you are not your work, right? You're definitely not your work. I mean, if someone says something about, oh, that button there is horrible, they're not saying that you're horrible or that you're thinking it's horrible, right? But it's really hard not to take it personally sometimes.
That's also very understandable. So even if we realize that we are not our work, we realize that it's our ego that's getting offended right there. It's really hard not to feel the feeling. You could even expose it, right? So, okay, the way you've expressed that felt a bit hurtful.
to me, but let's try to dig deeper into what you said and understand what made you say that. Why do you feel that something is horrible or what makes you have such a strong opinion? Let's try to understand what part of the design is eliciting such a strong response in you. So you can even be honest about when someone crosses your boundaries or when someone is hurtful in the way they express themselves. And that's one other way of guiding the conversation and setting up rules and telling, OK, I'm not
particularly happy with the way you've expressed that maybe we could be more careful when the next time you want to say something let's say it in a more constructive way this didn't feel very constructive it felt a bit too aggressive and just be honest about what you're feeling as long as it's not just a drama party right oh my god you've hurt my feelings why did you do that
So make sure you're not overly dramatic, but be assertive, right? Stay strong in a conversation and also honest about how you feel that conversation is not working. This is for when things get rough or tough, right? Because most times conversations don't have to be like that. They can really be constructive because people understand. Hopefully everyone understands how to be constructive. And then the last point is just very hygienic, right? So you want to keep the conversation constructive because you're keeping it on point.
So if you're telling people, let's debate this button here because we're trying to help the user see it better, like understand what happens if they click it, then the conversation is very on point. And so people probably won't be very emotional or like reactive or stuff like that. Intense, right? About it. So those are some thoughts I have. I would love to hear your perspective.
Yeah, I think what I also like to add here to this point is more about, again, types, I guess, types of feedback.
Typically, design feedback could be also three types. And the more mature the company and the people in your team, the more constructive it gets. Let's say not mature feedback that you sometimes, my experience, especially with like clients is reactive feedback, right? It's really when it's something very subconscious reactions and sort of, and it's very direct and doesn't really explain the reason the
the problem the example of it could be something like we were discussing was this make the button big it's not even make the button big it's like oh I don't like this button it's not even explaining you what to do better like it's really just telling you what you don't like or like somebody can do it better or I don't know I
I don't understand. My grandma would never understand it or something. So it's a reactive feedback, but it just shares the emotion. The second type of feedback is called directive, when usually, again, it gives you what to do, but doesn't explain you why, right? So it gives you like, I don't know, make
that button bigger or I would have this drop down instead of a radio button or something. But it doesn't explain the reasoning and how exactly it contributes to the goal, right? So when this happens, and again, that's something to me, direct feedback usually happens in the Figma. And if it doesn't happen and somebody explains it, then it turns into a huge conversation that you spend hours and hours going through. And it's also not super effective.
The directive feedback is when somebody gives you what to do, but doesn't explain you why and what's the reason and why is it better or worse decision. And then there is this constructive feedback we all try to achieve and aim for. And I always like in my head, every time I'm trying to give the feedback to someone, I'm kind of making sure I'm doing it is explaining why and what's the impact, right?
Right. Again, how I scan it, how I understand it, how I read it, why is it important and how I believe it should contribute to the goal. Like an example could be like if X, Y, Z is our objective, then maybe it makes sense to reuse our, I don't know, library components. So we keep it consistent or something like this.
So again, you're explaining here is the goal and here is why I think we should use this. And yeah, maybe also like explaining what you can use, not just telling you what to do, but explaining why and what's the impact of it to the goal. So this is like the, again, baseline with the types of feedback and what we always try to do every time we're given the feedback, right? It's obviously much easier said than done, but...
It's something that is very, very important. So there is no like personal opinions, no ego, no hard feelings, no feelings when somebody doesn't understand why and feels like they didn't do something right. It's just important, again, to align everyone and make sure we are talking about the goal, not your work, like you said.
And another thing what I can add here to this point is I remember that I read the book by Netflix. It's called No Rules to Rules. It's a doubtful book. There are controversial opinions around that, but that's not the point. Point is that they also shared how they ask for the feedback or they actually have like a framework in which they're asking for the feedback. And it's called the 4A. And it basically says that
Every feedback should assist, should be actionable, should appreciate and should accept. Definitely go ahead and read more about it. I'm not going to dive into it. But they actually have rules how to give the feedback and it's consistent across the whole company. So every single person who gives feedback...
Needs to follow those four rules. And that way they kind of try to sort of eliminate reactive and directive feedback from their work. So they also ask for like feedback timely. So right after the meeting or sometimes even during the meeting, if it needs to be said, not like in a private setting, but like really even on the group setting, it's very important to make it on time and make it again, trustworthy sort of like, not that you want to hurt someone, but really back to the goal.
So those are kind of the rules, I would say, that are important for feedback. And I think what we can do right now, it's been a long episode, I guess, but what we can do is start wrapping it up and maybe talk about either our three takeaways or just one general big point that you want to make as a part of this conversation. So go ahead, Ioana, you're first. My big conclusion for this conversation is that
You can't design in the absence of feedback. Even if you have like a fragility, a vulnerability, you're afraid that people will publicly expose your not knowing something or you're not sure if the design will elicit a response. You're very excited about something and that makes you vulnerable because you're afraid that people will not share your excitement about the solution you came up with. So even if you have all that fear, push through it. You have to ask for feedback. That's essential.
That sits at the core of what collaboration means. And collaboration is essential to any product development effort. So go ask for feedback. It's a gift. Set boundaries as much as possible. Try to guide the conversation, but be open. Just stay open and accept that, okay, asking for feedback and getting feedback sometimes might be hurtful. Sometimes it might feel vulnerable, but you have to do it.
And so, yeah, I guess that's my takeaway. That's my conclusion. Would love to hear yours and then we can wrap this up. Yeah, yeah. Actually, it's very similar. My biggest takeaway is also to not be afraid of asking for the feedback and communicating your design. The more you do it, the better you get. And to be very honest, I think best designers I've worked with were always open and very good with Speedwik. I think feedback is perfect.
part what makes us mature designers and not being afraid of it and being able to do it right or good, navigating that energy, navigating the information comes your way is a sign of a very good and mature designer. And so the faster, the more open you are to expose yourself to the feedback, the more you grow. And to me, even when I look into like CVs or resumes,
of designers, especially like early stage designers, like junior to middle designers. And I see that they worked in the big design teams. I mean, as human, they collaborated and asked for the feedback. I always think that's a huge, great sign. If you are a junior and working in a team with designers or...
I don't even know, like actually any big team, not just like two, three people. I always think you probably grew a lot in that setup. Again, it always comes back to the conversation you will have in the interview. But as for me, it's always a good sign that if you worked in the context with the feedback loops and other design teams, then most likely you were accelerating because you would not just
be able to navigate any teamwork, but you would also be able to rationalize it and learn how to articulate it and learn to tailor it to different stakeholders, meaning being effective communicator. So that's a very, very, very big, important part of our work. And yes, that's why feedback is very important for GROSS and all the designers. I do recommend to work in a team sometimes so you can learn from it.
And the other thing that wasn't still mentioned in our takeaways is always remembering who do you present and tailor your message to that audience because developers probably don't care about your explorations.
They care more about feasibility of that side of things, maybe consistency side of things, and et cetera, et cetera. And usually they would ask you about the timelines when the design will be ready and stuff like that, right? So it's really important to keep in mind who you're presenting to, what is important to them, and tailor your message specifically to that group of people. That would be my last takeaway. I guess with that, we can actually wrap this episode up.
Thank you so much for joining us today. If you enjoyed this episode, please rate us on any podcast platform of your choice. We're on Spotify, on Apple Podcast, on Google Podcast and whatnot, actually. Pretty much any podcast platform. We really appreciate your feedback. That keeps us going. So thank you so much again for listening. And if you have more questions or more topics that we should discuss in the next episodes, also make sure to submit it. You'll find anonymous link under the show notes.
and also stickies on the Spotify if you prefer it or you can just reach out to us on DMs, even emails. Anything works for us. Thank you so much and hope you have a great day. Bye-bye. Bye, everyone.