Learning how to say "No"
Happy New Year !! ( It’s only been 4 days into 2020. I can still say that, right?)
This is the beginning of a fresh start for many of us, not only in our personal lives but also in our careers. It’s a time where you’re ready to explore new trends, experience tackling new projects and learning new things about yourself. This of course means learning how to say “No”. As juniors, you’re trying to learn as much as you can, make as little mistakes as possible ( it’s from being nervous about the outcome. Mistakes happen to all of us. Don’t stress it too much, just try to fix it.) and not “shake the table”. However, there will come a time when a team member or a client will request a task from you that should not be done, is not a good idea or you have no authority to do. You will need to say no.
Based on the experiences I’ve had, here’s a few ways to do it professionally, set boundaries and feel confident that you will remain employed:
Explain why the request may not be the best course of action to take and give an alternative.
Ex. You are requested by an account lead that you ask leading questions during user interviews to influence the responses that the users’ give. Explain to the account lead that asking users questions in that manner is not best practice. It will skew the data and feedback you receive which can lead to design decisions being made that will result in user decline. User decline will impact the business goals that are trying to be met. The long term impact of this will be the company spending more money in order to fix the initial problems and the newly gained ones. Therefore, it is in your professional opinion that it would be better to frame open ended questions that test the account leads hypothesis on user behavior and can allow for genuine feedback.
Escalate the request to your manager or lead. Forward the request to them or CC them in the email.
Unfortunately, there will be times when you may be asked to do something because they know if they ask your manager, it will be declined without a second guess. If you’re unsure or you know you shouldn’t do something, reach out to your manager, director, or lead. They have more “rank” and are more likely to be listened to. They will prefer that you kept them in the know and allowed for their guidance than the problems that can be caused if you had acted. This is not only good practice but a good way to CYA.
Ex. You are requested to send out final designs by the PM. The designs have not been reviewed by your manager but the PM has insisted on you sending the designs to the client in 10 minutes. Forward the email, CC your manager and explain to them that while you are sure the final designs have been signed off, you want to make you get your manager’s sign off to do so. Your manager will either take over from there or tell you it’s ok to send the file.
State that what is being asked is not a good idea and have some data to support it, in case you need it.
There will be times where a client or even another designer wants something that you know, without a doubt in your mind should not be done. Usually, when this happens they will want to know why it shouldn’t be. This is when you will need to have data and information to support your decision.
Ex. A client wants their app to be hot pink and implement gamification throughout it. Their app is a medical data platform that is used by an elderly demographic. They believe it will allow them to be seen as fun and modern. Implementing this would be a terrible idea. Hot pink is not associated with medical data and it may be harder for the users to see the content. Gamification is not needed for every application and for a medically focused application, it’s distracting. Find data on color theory, gamification guidelines, and best practices for medical platforms to share with them.
Hope this helps.
Until next time, happy wireframing.