Does Figma Have Feelings?

Josh Reid at UXDX Community: UX Research - Facts & Feelings. Video: https://youtu.be/j-tZS-3zLTc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Figma, feedback, feelings: the three Fs

[00:00:01] Thanks everybody. I'm from Racing and Wagering Western Australia. Our main app is the TABtouch app, which is a sports and racing app. Today I'm excited, feeling excited, which is a good thing because we're going to be talking about feelings today, and Figma, and how things work together. Maybe there's some AI in there, we'll have to wait and see, Rory. First off, thanks to Michelle for an awesome first presentation getting us kicked off. I think that was really insightful and really interesting to see all the mixed methodologies.

[00:00:33] What we're going to be talking about today in my talk is Figma, feedback, feelings, the three Fs. This is something that I'm pretty passionate about. Working in UX for a while now, a few years, the main thing that I encounter is that feedback loop and that feedback process. One thing that I've noticed working within different teams and with different designers is that there are obviously underlying feelings that need to be a consideration.

[00:01:07] So why do we mention Figma specifically? We all know Figma is that UX design tool, whether it's Figma, Sketch or Adobe XD, rest in peace. The main thing is it's a tool for getting your prototype out there, so it can seem sometimes a little impersonal. We develop up a prototype, maybe it's sent out in isolation, and then the feedback waves start flooding in. So that covers the Figma, the feedback, whatever methodology is used. Sometimes it could be just some comments sent through, so more on the impersonal side. There's direct feedback, the conversations you can have, and then you've got the other ones where maybe you're pitching to an internal group and trying to grab some internal feedback.

[00:01:54] And the last thing we're looking at is feelings. Pretty self-explanatory, that one. It's just about the consideration for the feelings of the people giving the feedback, of the people receiving the feedback, and that entire process.

The feedback loop and failing fast

[00:02:09] Next up, let's start with the feedback side of things. Working in the agile methodology, there's a lot of conversation around that feedback loop, multiple iterations, and that entire process. We know that's a circular process, and that's what the loop entails, that we keep on coming back. There's multiple revisions of the design, multiple levels of feedback, whether it's customer feedback or internal feedback.

[00:02:42] One thing I wanted to discuss is we talk about, in the agile methodology, failing fast and going through all those iterations, and then failing, but it's okay because we failed fast. Just a consideration of even how aggressive that language is: we failed, it was a failure. So that coming back to the designer, that can be a bit of a pill[?]. If you imagine, and you don't need to imagine if you're working on the design side or even on the product side, you know the amount of work that goes into a prototype. You're trying to validate the concept which you think will be successful, and then once it is unsuccessful there's that terminology of failing fast. We saved some time, we failed really quickly and we can move on.

[00:03:29] But before we move on, the consideration needs to be that we're labelling a design a failure. Is that appropriate? Do we need to look into that a little bit more, and how we deal with that, and maybe make it a little bit more personal, and I'll say in person, rather than just moving on quickly and disregarding the work that's been done. That's what I mean by the feedback loop.

[00:03:53] More feedback and more input and more research: that's the discussion around qualitative versus quantitative. Sometimes it can be beneficial to have a lot of feedback, but what we're talking about a bit further is the quality of that feedback. From a design point of view, the UX designer, how valuable is that feedback to them? And for anyone giving feedback in the product space or any other space in the UX development, how valuable is your feedback? So that's another consideration that we need to look at.

Internal feedback: maximum detail, constructive, actionable

[00:04:28] Internal feedback, I thought we'd jump on to looking at internal. What I mean by internal: obviously you've got people within your organization, maybe it's within your team, maybe it's wider, so subject matter experts, people within the wider team in the organization giving you feedback on the design. So how can we improve that? There can be improvements in the way that the feedback is delivered, and there can be improvements in the way we accept the feedback as well, sorry, we accept that sort of delivery.

[00:05:02] So maximum detail. What do I mean by that? This is actionable detail. We obviously don't want it to be too verbose, too detailed. It's more about how concise and actionable it is. Obviously the least amount of feedback you could get is somebody to look at something and then say this experience was bad, I used the prototype, it was not good. That's obviously the minimum and that's obviously zero benefit to anybody. So we want to know the detail of which parts didn't function correctly. Was it functionality? Was it design related? Did it not have the business objectives at the front of mind? These are some considerations we can make. So that's what I'm talking about when I say maximum detail.

[00:05:50] Tied in with that is how constructive it is. Obviously you can frame feedback in a critical way but also a positive way. So rather than just separating the two, we can focus on parts that are working and perhaps parts that aren't quite working yet. Remember, initially we talked about failing, and perhaps one of the prototypes may fail and there may be issues, and maybe they're not reconcilable, maybe they're not fixable. But what we really want to do is make sure that any feedback that comes in can be actioned. So actionable feedback, even if we don't know the answers, specific enough that the UX team can go away and revise that sort of input.

[00:06:39] Within my experience, some feedback can come through as a bit of anonymous feedback. So when I talk about anonymity and visibility, I'm referring to maybe you'll send some messages, maybe there's a Slack channel, maybe it's an email, maybe it's just comments on the Figma design, or wherever it's shared, and InVision. It's more about leaving a little note and someone else to capture that later. Is there going to be anything lost in translation? So when we talk about interpreting that feedback, making sure it's clear, concise, actionable, and not overwhelmingly negative.

[00:07:24] Negativity as an overall undertone is obviously not what you're trying to convey to the designer. You're trying to value their input, but you also want to make sure that the feedback you're giving is tailored enough to get an understanding from the designer.

[00:07:41] One example of that is, I know in a lot of my work, when working for a big organization, obviously the branding is paramount for that organization. One thing that can't be changed is the tone of voice and that brand identity. So working with perhaps a detailed colour palette that may feature the brand colours, previously I've had examples where the feedback on some prototypes has been, we don't like this because we don't like the purple, I'm not a fan of purple, there's too much purple on this. Maybe that would be some feedback that would be given.

[00:08:17] As a designer, how actionable is that? Of course we can adjust the ratios and the blending and the visibility of the brand colours, but we can't change the brand colours. So is it unreasonable for someone to implement, from an internal point of view, their preferences, their favourite colours, things like that? As designers we know that obviously it's for the customer, and we're trying to appease them, and you have those brand considerations to make. So that's probably an example of feedback of knowledge of the domain, and the person giving that feedback is trying to be helpful, but they're really saying I don't like this because of these reasons. It's on both parts, to both communicate that effectively, to understand branding and the marketing behind that, but also from a UX point of view a bit of education and explaining that our hands are tied in some things we're doing and there are business outcomes to be considered. So that's one thing.

Accountability, and never making it personal

[00:09:17] The next thing is just the accountability. Knowing that as someone giving the feedback, you're accountable for how you're portraying that feedback and how much of an impact you're going to have on that UX design and research process. So it's about effectively communicating business outcomes and things like that, we're talking internals still here, so it's about owning that. And then from a designer point of view, owning that that communication is clear, and those conversations are not only documented but actionable.

[00:09:52] And never personal. So "I don't like what you have done", things like that bring a personal element to it. Obviously you would never direct it at you as a person. The design is in isolation, the design is a product, a combination of all that work within the product or UX space. It can have multiple inputs, multiple people working on the project generating a prototype. It's not a reflection on a single person. So being demonstrative or communicating with someone in such a way that maybe that culture could be damaged by the way that you're approaching that.

[00:10:30] So just making some considerations of the way in which we converse with the designers, and understand that they put a lot of work in, there's a lot of moving parts and there's a lot of consideration, and that what we're looking at is an end product. The more detailed that feedback can be, the more we can build on that, rather than making it about someone's personal skill levels or style or ways of working.

External feedback: the user

[00:10:56] That's one thing, and then I guess the opposite of internal feedback is external, and the main one I think we look at is user feedback. The U in UX is the user, or the customer, but the user of the product is who we're talking about next, and this is where it's quite different, because as we were saying previously, we don't have a lot of control, we don't really have any control over the users. We're valuing what feedback they're coming back with. Obviously the customer's always first: customer-centric design, what we're looking at is putting the customer at the forefront. The customer is the user, so trying to appease them and give them exactly what they want. So really listening.

[00:11:41] Some feedback that I've had previously when doing in-person interviews, or maybe in-person testing, so you're physically there with a person, that makes it a lot more personal. One thing that I've found is that without good structured objectives and questions there can be a level of ambiguity and people sort of going through the motions. If you imagine you're having a conversation, it feels one-on-one, you're showing them a prototype and you really want to soak up any information they can give you. If you're asking general questions like what do you think of this prototype, how do you think it works, things like that, I've found a lot of the feedback is usually, it's nice, oh that's great, yeah it's fine. So it's fine, it's great, overwhelmingly positive.

[00:12:35] The consideration from a personal point of view is that that's a person, you're a person, they're trying to be nice. There's that level of being polite and saying oh that's good, there's no problem. But what we really want from them is not only to outline problems or even successes, but to really detail that. So that's about asking those more detailed, nuanced questions.

[00:13:02] The other issue you run into, not only is it personal, but sometimes the person will have that being a little bit too nice, because they're coming in to help. They're being paid for a service, either directly or indirectly, and they're doing some tests for you, and so that's where the politeness comes in. It's sort of like, oh well, I'm getting paid for this, so to do a great job I'll just say that everything's great. So from the user's point of view they think they're doing you a favour, when in reality, as working in UX, we know that none of that is valuable.

[00:13:42] So it's all about how we really take a deep dive and get value for money from that customer input. We know how difficult it is to get that detailed customer feedback, and when we are working one-on-one we really need to ensure that what we're getting is value. So if the feedback you're getting back isn't very actionable, isn't very valuable, then maybe it's the designer asking not the right question, or the UX research not triggering the right responses because we're not asking the right questions. So bad answer or bad question, that's where that comes in.

[00:14:18] And it is ultimately the most valuable thing, so customer is key. It's mentioned twice obviously, because it is so important. When we're talking to those users, that is the most valuable stage, and getting that direct feedback is critical. So the better the process, the better the outcomes from that. That's the most important thing.

Everyone responds to feedback differently

[00:14:40] I've spoken previously a little bit about whether you take things personally. One thing that I've noticed, and these are all just from my own experiences and I'm sure everyone's varies, but everyone's very different, and some people I've worked with respond really well with direct feedback. So it can be very short, very concise: you've done this design, I think these four things aren't working because of this, and that can work quite well. Personally I'm a little bit like that, I don't mind the direct feedback.

[00:15:14] But then I've worked with a lot of people who don't like that. Maybe they've built it up in such a way in which they think they've made all the considerations, and then if the feedback's very direct and it's shutting down all that work, and they can't articulate why those decisions were made or how they ended up at that point, it can feel personal to them. So the main thing is everybody is different and we need to make considerations for that: how we converse with other designers, and how other people within the business converse with the designers throughout that UX process.

[00:15:50] Sometimes what I've found is it can actually be easier if you're presenting or you're pitching or you're testing a design that's not yours. There's a slight disconnect. Obviously as a team there may be you've had some input, but maybe the design was from someone else in the team, and they weren't comfortable doing the presenting or running through with customers. Because it's not yours you can make that disconnect a little easier, so sometimes that can help.

[00:16:16] But basically it's just about the value of what we're getting. The feedback is on what someone's using. It's not personal. They don't know how many people have worked on it, they don't know how it ended up at this point. The customer is just looking at it, and even internally they're looking at it and they're giving feedback on that. The moral is: you are not the prototype, you are separate to that.

[00:16:42] People taking things personally is something everybody needs to work at. It's not a matter of changing the way you receive feedback, it's trying to empathize with that person, and more on the person giving the feedback, a bit of education and how well they know the person they're giving feedback to. Internally there's really no excuse for that sort of thing, because obviously you have an opportunity to get to know the people who you work with, and that's all about workplace culture and things like that.

[00:17:12] I think the more you know someone, the better you can converse with them, and I think that's apparent in almost everything. One analogy would be that people who know each other very well can usually communicate in a very nuanced way. If you imagine sporting teams, they know exactly what everyone on the team is going to do, maybe just by a split signal, maybe it's a look, maybe it's something very simple. And then you've got people who don't work with each other all the time, they need a lot more. So getting to know people on your team so you can really communicate a lot better, it makes those iterations faster and it makes getting feedback on those prototypes a lot quicker. So when we talk about being on the prototype and not on the person, it's about knowing that person first.

Feelings: empathy and team culture

[00:18:01] Feelings, the last F. As I've spoken about, empathy is key, so try and put yourself in their shoes. It's a tough one being a UX designer. You're presenting a lot of work all the time, usually your own work. You imagine you're crafting a process, you're trying to put it out into the world, into the business, testing it, getting feedback and then redoing that. So that loop, you need to really be good at that process and get better and better. It's about evolving as designers and it's about evolving as developers and product teams, and how we communicate. So is it constructive? Is there a solution somewhere in there? And how can we better communicate as a team?

[00:18:48] I really think it's more about a team culture: knowing who you're talking to, knowing how they work, sitting with them, understanding that end-to-end process can help the way in which you give more targeted feedback, and can help in the way that you deal with those people. Everyone's unique. Just trying to put yourself in their shoes and see how you can better that process.

[00:19:13] So, improvements. We want everyone to get better, we want the whole process to get better, we want good communication to get better. This is just a little bit of a summary of what we've been talking about, and this is all from my own experience, basically. Empathy, like we were saying, giving feedback and receiving feedback: there are ways to improve both, and I think the more we do it and the more different people we work with can improve that. Knowing others' ways of working. Improving the culture of your teams and the way in which you work, that's important. Being accountable, following that feedback through to action: how did it go, what was the user feedback, did we make any inroads there?

[00:19:56] I think that's where a lot of it comes in, the consideration of other people's feelings, and as a designer managing your feelings and conversing with that audience as well. If you're receiving some internal feedback or even customer feedback that you think might be over the top, try and put yourself in their shoes, try and understand where they're coming from, but also communicate to them that maybe you don't respond to feedback in that sort of way and you'd like more of a dialogue. Maybe you could sit with them, maybe you could go through the designs in a more personal way, more one-on-one, rather than meeting room pitch style.

[00:20:34] And just knowing what works well with each person. I think everyone's different, and it's just important to empathize with everyone and acknowledge that, and really change the way in which we work to improve the culture around UX and around user feedback and internal feedback. So the talk is about does Figma have feelings, and the main takeaway I wanted to have is that Figma doesn't have feelings, but people have feelings. So that's it for me, thanks very much.

Q&A

[00:21:13] Rory: Great, thank you very much, Josh. It was a nice way, so my AI thing wasn't right at all, but no, thanks for sharing.

[00:21:23] Josh: A bit of clickbait.

[00:21:26] Rory: Great. If anybody has any questions for Josh, please do feel free to just type them in whichever platform you're watching on. But one thing I wanted to start with, because you made a good point about trying to be constructive with your feedback. Often, particularly clients, they might not have the background or the experience to know exactly where they should be pointing to and to give that kind of constructive feedback. So how do you, or do you try to coach clients on, okay, how about these kind of five or six, or however many topics: what do you think about the layout, what do you think about the structure, the colour, type, those kinds of things, to try to pull out that constructive feedback?

[00:22:17] Josh: Yeah, that's a great point, Rory, and I think that sometimes that's probably unavoidable, but a lot of it is just almost about education. If you imagine, people within organizations, they might not ever deal with the UX design process, or almost at all. So I think it's about educating them on why something is the way it is. They don't see all that level of research that goes into it and why decisions are made. So if there's a way in which you can give them a snapshot and say this was done for these reasons, and based on feedback this is why we ended up in this position, then sometimes it can switch their thinking, rather than looking at a ready-made prototype. As we know, a prototype is almost like a jigsaw cobbled together of all the insights that you found. So I think by communicating that process and getting them on board with that, it can sometimes help them be educated, and then the next time they're giving feedback some of that might pop into their mind.

[00:23:10] Rory: Great, that's a great idea. And do you have, even internally, because I know the kind of feedback is "oh I wanted it to pop more", or those kinds of things that just don't really help anybody. Do you have any, because I think you mentioned, does it achieve the business goals, is it usable? Because even explaining the background of how we got there, there's a million ways of designing something. So do you have, even internally with experienced people, a framework for trying to distill the information or the feedback?

[00:23:50] Josh: Yeah, I guess that's probably a critical one, an age-old design feedback one that we do get. It's sort of like everyone feels like they're a designer a little bit, and sometimes they try and impart that, and it's talking about things like colour or balance, the things that probably are hard to articulate, the way in which they work only by experience you would learn them. You've sort of got to draw it back to: is the thing they're giving feedback on a business goal or a customer goal? And if it's in between and none of those, that's when you can almost double down and say from a design point of view we're aligning with either our previous products or the style guide or this rule set.

[00:24:34] Josh: I guess that comes down to education as well, because you can have people internally that don't understand that bigger picture, don't understand the framework in which we're working. So if we explain to them there's all these different segments and different rules that we're trying to align to to get the best output for the customer, then perhaps it'll be a little clearer. But yeah, you're right, sometimes those conversations are the hardest to have, because people do want their input. But if it doesn't align directly to those things, it's sometimes a little bit easier for them to see that.

[00:25:03] Rory: Great, now that's some good feedback. I'm going to just shift to the feeling side of things now, and Radical Candor. I don't know if you've read that book, but it's kind of saying things like the compliment sandwich, the good news, bad news, good news, is just, it gets in the way and it distracts, so just lay out your real position up front. But it can be quite jarring for some people to get that level of criticism up front. So is there more responsibility on the person to become a bit thicker skinned, or is the responsibility on the person giving the feedback?

[00:25:46] Josh: It's probably a little bit of both, that's a good call out. Obviously you don't want to make it more verbose and more complex just for the sake of padding these out and trying to mix positive with the negative. But I think it truly just comes down to the person. Like you were saying, in those sorts of regards where we try and make that compliment sandwich, people understand those methodologies now and how they can be delivered, but it still probably doesn't address the fact that some people don't like dealing with that. So it's acknowledging that with the people where that's going to work, you can do it, and direct feedback for others, and that maybe there's a different hierarchy in how you communicate with different people to achieve the same end result.

[00:26:31] Josh: But I'm not sure if there can be any shortcut or alignment on everyone giving and receiving feedback in the same way. I feel like people are so different. I've seen a lot with designers who are very passionate about their design and they're all in, and then whenever any of this critical feedback comes back and it's too direct, it can knock them back a bit and it can make them more apprehensive and less outgoing and take less risks with future designs. I think you've really got to nurture younger designers, but also more mature designers, that don't respond well to that feedback, just so you're not taking three steps back.

[00:27:11] Rory: Yeah, no, it's a good point, that people are becoming aware of things, because I deal with a lot of sales people and I know their tactics are to compliment you to try to build rapport. But it works, it works every time. Everybody loves a compliment, even though I know exactly what they're doing.

[00:27:31] Josh: Yeah, it is very common. And I guess as designers, I think because we're always showing work and getting feedback, you probably do get really good at filtering that out, especially internally. You know the people, how they give their feedback. But initially, when you're just getting to know those people and you come off a little too direct, sometimes that can be detrimental to the relationship, I think.

[00:27:54] Rory: Yeah, so I'll ask the fun question I have, is around something that I think everybody is probably familiar with, and that's, you've gotten feedback but you fundamentally disagree with it. They've articulated themselves well, and maybe they're a senior person. How do you deal with those situations where they're quite adamant on their feedback but you don't really agree with it?

[00:28:20] Josh: Oh, I guess that's a broad one. There's multiple ways. What I was speaking about previously about aligning to goals: if you can almost justify why you think it should be your way, perhaps you can win in those regards. But I guess with people higher up it's a little bit about picking your battles. If we imagine as a designer the control that we have over the way in which something works, if the feedback is to change two percent of that, is it worth pushing back on that and doing a mountain of other research just to say, oh, here's the presentation on why that feedback won't be implemented and why it's perhaps incorrect?

[00:29:03] Josh: It's what's the impact on the customer. If they're going to change things because they're passionate about a certain thing, and you think it could be detrimental to the customer's experience, that's when you would push back. But I think sometimes you have to let some of those go through. There's no easy way around it. If all else fails and we can't communicate correctly and that feedback's coming down and, like you're saying, it's a top-down sort of system, sometimes some of those we do have to let through, I feel like.

[00:29:31] Rory: Great, well that's a great way to finish up: be pragmatic, because everything is a balance. Excellent, so that brings us to time. So thank you very much, Josh.

[00:29:43] Josh: Thank you.