Interview with Shir Zalzberg: “Feedback is low on priority”

Shir Zalzbergis a Senior product designer in Salesforce and recently relocated to Amsterdam. Following a talk at the Master Digital Design, she sat down with student Noy Gvishi to discuss the benefits of feedback and how to design it right.

Noy: First things first: how did you become a designer at Salesforce?

Shir: Before I started at Salesforce, I worked at a small startup OverOps that made a product for developers that analyzes their code at runtime. I was head designer there, but after working for some years, I realized that if I wanted to mature as a designer I needed to work for a company with a mature design structure. I wanted to experience working in a big team, with UX researchers and copywriters. To achieve this, I looked at big enterprises like Salesforce, a product I used when working for OverOps. So, I joined as the first designer in Israel. I was lucky that I was capable of building a name for myself in Israel by founding, managing communities, and creating content, so when I went to the job interview, the manager already knew who I was and was a bit impressed, to begin with.

Noy: So, having an online presence and contributing to the communities is crucial for a designer’s growth in their career and as a person?

Shir: It is very important. Imagine you leave a job and no one knows what you did there. I studied statistics, so here are some statistics: we are a generation that changes jobs every 2.4 years and 70% of the change is due to active recruiting by headhunters so when you build a name for yourself you increase your chances of being approached.

Noy: Now to the core of this interview, how do you usually advocate for feedback features, and how do you prioritize it?

Shir: Prioritization is really hard. It is hard to show the benefits of feedback when there are core features missing in the product. In most cases, the feedback will be low on the priorities to invest. I believe that in small companies that are moving quickly from sprint to sprint it is easier adding feedback to the release cycle. In big companies, it is more difficult to convince management without advance planning. I will say that feedback might be expensive in terms of putting it above the red line [what goes into the sprint by priority] but it also saves us so much money and it is cheaper in the long run. It can prevent us from working on something that we should not be working on and lead our attention to deliver a better product. It is also acceptable to use external mechanisms that have built-in feedback like Intercom.

Noy: What do you recommend to motivate users to provide feedback?

Shir: We usually can think of two ways of incentives: they can be either be monetized or non-monetized. Monetized incentives can work wonderfully and they can really suck. Just because it's real payback it doesn't appeal in the same way as the emotional connection that the user might have. So, it can work in some cases, but in some others, it might not. On the other side, you will have unwanted ties to incentives, and those incentives can appeal to other things that might motivate your users, like the feeling of belonging and just frankly caring about the product and wanting to see the product succeed better. Those types of incentives in the long term can prove valuable. There is also the notion of trust. If you want users to give you information, it's usually helpful to be very candid and very open with them, so that they can make their own decisions and feel it's a logical thing to do and that it will provide value for them in the long run. For example, when you work on a feature and the feedback says “Hey, we know you're very busy but if you stop what you're doing and you help us, our product will become much better.” It's important to answer both what they have to gain (the product will serve you better) and being open about the level of commitment“It will take you four minutes and it’s only 10 questions.” So, providing clear information can be super helpful.

Noy: What metrics do you use to define if in-app feedback was useful?

Shir: I think it depends on the company. Smaller startups might put KPIs that are more quantitative. It can be time spent on the feedback: if it is very quick, if they didn't spend time on that it can mean that you might have interrupted them but they just wanted to be finished with it so they just clicked on things and didn't actually read it. Time to complete is one metric in here, and you want it to be a logical time: not too fast, not too slow. Another would be the amount of people. Obviously the success metrics within the scope, so if you are writing, or if you have a yes/no question. So, how many people selected the top options in writing, how many people selected the negative options... Or, sometimes, we have optional questions, especially with the open questions: so, seeing how many people took the extra investment in answering the open questions is another way. Another good metric is bounce rate - so, if you don't interact with the page at all. If you have a longer survey on a pop-up or a new tab, how many people stayed and how many bounced

Noy: What are the guidelines to have feedback match the tone of voice of a product?

Shir: Speaking in a cohesive tone of voice is something we sometimes neglect on surveys. The survey or feedback is part of your product, so it needs to be, feel that it’s the same brand or person communicating with the users. The homepage or product page must have the same tone of voice as the person asking you for feedback. If the tone of voice is super chill, funny, relaxed, you can't have very formal, buttoned-up language in your survey just because this is how you think questions are written. In most cases, you have to adapt. This also goes the other way around, like if you're a bank and you have a really clean and straightforward way to address users, you can’t write questions with a very child-like, or funny language.

Noy: What’s your advice to promote adding feedback features in a company?

Shir: My advice is that you should inquire about the possibility of getting access to data. Try to find a way to prove the value to the users by showcasing data. When faced with hard numbers, managers are more likely to support your adding the feature. Feedback is great; so is AB testing, heatmaps... all of these tools are great for designers to back their assumptions.

Noy: What is your approach to designing user-centered interactions?

Shir: I think it depends on who you work for and on your maturity, to be honest. A few years ago I would have said: visual inspiration. Now that I work for a big company, we have a design system so I feel that my job focuses more on the UX than on the UI. The questions I ask are less about the visualization and more about the wants, the way the product should act to give the users the best experience. I will scan our huge design system, remind myself what tools I have in my toolbox and look at different products - how they resolved things, what I like and dislike. I will make sure I look at comparable products from different industries because that is where innovations come from. The solutions of others can be good solutions for us as well. Then I set up documentation and define my goal, the challenges, the business professional, a description of the project, target audience, timeline, and what we want to achieve. There are different ways to do design strategy documentation but it is usually this one page, the compass to everything you are doing.

Noy: What do you see as the future of interactive design?

Shir: For me, the big interesting thing that is happening right now is the no-code revolution. The way we have been designing has changed drastically. Only a decade ago, designers used letter sets and worked by hand. Then digitalization occurred and we designed with pixels and digital fonts. Everything is changing. Figma, for example, they have this feature of auto layout that is like position in CSS. That mindset that comes from CSS and its box-model is entering the design field. We start to shift as well. One company that I am advocating for is Webflow, which is open completely. You are designing in code without writing the code and that is revolutionizing. It changes the way we work and if you think about what can happen in a few years from now, maybe it will be like that for products too - that you can change the navigation with a click of a button. The entire way we communicate with engineering will also change to make room for them to focus on other things. I am very excited about that.

Photos by Ruben Kok