It’s okay to use shortcuts like placeholder imagery and text in your design to get to the point, but be mindful that it could trip people up if they think they could be final assets. Make sure that you point out what parts of your design are still to be finalised so that they don’t waste time thinking about it when giving their feedback. 

Design has to be easy for users, it has solve a problem, and it should be supported by everyone.  

When someone gives you feedback, you don’t necessarily have to do the exact thing they suggested if you don’t think it’s right for the design. Take it on board, get to the root of the problem that caused them to suggest this change, and make your edits accordingly. When you’re presenting the final work, make sure you let them know that you took it on board, and what you changed as a result (or, why you didn’t change anything!).  

Train your team on how to give you useful feedback. Ask them leading questions, give them context before the design and what state it’s in, explain things like what a wireframe is and why this image is only placeholder. Perhaps you could even share it with them in advance and give them time to mull it over. 

Make sure you’re talking to the stakeholders directly. You always need to be able to understand why someone is suggesting a change, and if you’re communicating through middlemen that won’t be possible and your design will suffer.

‍00:00 - Intro and catch up

05:00 - The CEO button

08:00 - How ‘finished’ should your work be before you share?

14:45 - What the role of design and the designer is

17:00 - Responding to feedback that suggests alternatives

22:45 - Reading between the lines

25:00 - Bringing in metrics to back up your design

27:30 - Changing the way you present based on who you’re presenting to

32:00 - The chain of approval

36:15 - Having confidence in articulating your decisions

41:50 - Last words of advice