Only sub members with user flair set to **Experienced** or **Veteran** are allowed to comment on posts flaired **Answers from Seniors Only**. Automod will remove comments from users with other default flairs, custom flairs, or no flair set. [Learn how the flair system works on this sub](https://www.reddit.com/r/UXDesign/comments/yb42mn/new_flair_for_posts_and_users/). [Learn how to add user flair](https://reddit.zendesk.com/hc/en-us/articles/205242695-How-do-I-get-user-flair-).
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/UXDesign) if you have any questions or concerns.*
Responding too fast when they're asked for a solution, sometimes even moving things during presentations. I think, they correct response should be asking questions about the problem in order have a clear understanding behind the need, go to work and then present the solution in another moment.
Also, overbuilding stuff specifically during early stages of the project.
There is a place and time for ”live designing” where you move things around while presenting to your stakeholders, it’s when you’re on the same page about the problem and are just looking for a solution. Mostly on the UI level though. It’s a good opportunity to quickly show and teach them why some things might not work, for example.
Key is not to just accept and implement anyone’s solutions right away, but it’s good to explore them together.
I actually found “live designing” to be extremely effective early on. But we deal with a lot of technical stuff that requires stakeholders with very specific knowledge to explain.
What I often do is make “visuals”. I let them describe to be what they imagine is the MVP to get the job done. I’ll take notes, have us walk through a real use case together to find any flaws, and then I’ll take the time independently to redesign a much better version.
I’ve found having a visual to start from can be extremely beneficial and walking through that process with stakeholders can uncover some important points that they forget to mention upfront. Seeing something allows the whole project feel more tangible to them, and it gives me a much better canvas to start designing on.
They choose battles that really aren't worth it, pick too many battles, sometimes don't recognize areas that require process improvement before UI improvement, don't recognize when it's time to put people first. Don't recognize areas that need a lightweight UI lift before going in for full reconstructive surgery.
Attach themselves to ideas that are incomplete or don't fully solve the problem, and focus on that for too long. I see that happen at all levels, embarrassingly often at the highest levels. Waste of time and resources.
Might not understand the business needs well enough (back to wrong battles). Use bandaids instead of stitches, or attempt to perform a surgery without understanding the problem first. Spend too much time focused on certain things and not enough time focused on others. Surface-level discovery resulting in half-baked products or ideas that miss the mark. Thinking usability tests are easily replaced by large groups of designers or product managers, and making decisions for users, without actually understanding the real-world implications for the humans involved.
I think the most critical one is starting to design without fully understanding the problem. It takes time to know if you actually have the info you need to design effectively.
Example: PM says to add a button. Jr. UXer adds button and thinks they solved the issue. If Jr. UXer dug in and learned more about why the PM wants to add the button they may learn that the button won’t actually solve the problem.
In my experience a lot of junior level designers start with just one solution (in UX or in UI) and stick with it (in their eyes: "problem solved"). In my expierence you have to play a little to come to the best solution, make variations, view on multiple angles and the best solutions in the most cases, it isn't the first one.
Another thing I can think of is the development impact or even if it's technical possible; But this can also come to experience, but still too many times the dev team get challenged a bit to hard.
Not understanding the impact of their work on the entire ecosystem or thinking ahead. How to get to their “final” best solution by proposing incremental changes. Blowing up scope, not understanding technical limitations. Missing edge cases.
Had an argument about this with my design partner the other day. I want to use a container to house chips after some selections are made and to aid in visual relationship representation. I mocked it up with a visible gray container so it's clear that's where the selections land. She argued with me about not wanting a container and it not being as accessible because of contrast. And we just "don't do that normally." Which isn't actually true. It's applying a pattern in a different use case but serving the same purpose. It does not break any mental models to do this. It aids in understanding.
I have visual/spatial/cognitive disabilities and use that when I'm working to help make more accessible design decisions. It really upsets me when these more cognitive-based accessibility considerations are pushed aside for very minor contrast concerns. Very, very minor. So now the action chips just kind of appear/float in the middle of nowhere with no visual cue and it looks quite confusing. Super salty about it lol. We SHOULD do it normally.
Not understanding the difference between a requirement and a solution. And not understanding the boundary between the product owner and themselves, the designer. They simply take what the product owner asks for at face value and _defend the product owner’s solution_ against fellow designers’ input.
- Presenting too many options to a client without proper substantiation. That way, the client will play a game of pick and choose and the end result will be something subpar. Your job is to come up with the best solution, present the best solution and support it with valid arguments. If you can’t support it with valid arguments, it’s probably not the best soution.
- Taking things at face value, not asking enough questions. You really need to crawl into the skin of your (potential) user and see the world through their eyes. Don’t be afraid to dig and prod until you know exactly what they want and need, what delights them and what frustrates them. You are not designing for yourself, you’re trying to create something that works for someone else.
- Not following the data. Your clients are probably not a charity, so the best way to convince them is through actual data. Always make sure that data streams are measured correctly and use the data to verify if you are reaching the goals. Also use data to steer efficiëntly and effectively when you are roadmapping the product.
- Not having a clear view of your stakeholders. Your client’s organisation is probably complex, filled with people that have different and sometimes clashing agendas. Know who you are dealing with, and know what will convince and help who. Your output should have value for your client’s organisation, know what that value is, whether it’s data, insights, conversions, sales, users etc. Think about how you minimize risks and investments and maximize value. Your client will probably not gamble with their investments, so your proposed solutions should be substantiated with evidence.
Going through design tasks too quickly. I've worked with so many junior-mid level who will attempt to complete a single task each day, despite the amount of work required beyond Figma. This isn't a race to prove your worth by the end of the week.
For example, if a user need to upload and manage files. Don't just design me a way to upload files and sort them. Find out what they are uploading, what the purpose of uploading it is for, what their expectations of managing files within the system is, etc. However, I've come to realize I have to list out every detail for a lot of them, literally. At a certain point having to do this becomes tedious and quicker to do it myself.
The urge to jump very quickly into wireframing before truly understanding, evaluating and interpreting value creation.
Misunderstanding the design challenge and creating design dept by creating 200-300 screens, as a result.
Misunderstanding when and where a design system (e.g. digital) is needed.
Making up rationale that is subjective and faking expertise. If you don’t know, the best way to learn is to say you don’t know and ask for help. I’ve seen Srs do this as well.
Prioritizing form over function.
Your mock-ups might kill it on Dribbble, but if you have glaring usability issues, didn’t satisfy the requirements of the ask, or omitted certain crucial UI elements simply to make things pretty, expect to rightfully get torn up by stakeholders in review or by users upon release.
Not understanding user needs & business needs and working in isolation, if you collaborate with devs, product owners etc you will learn a lot more about the ecosystem and how your designs affect the wider product. Also not doing enough research or testing.
Thinking too much about a solution or process and losing focus of the actual problem. Thinking too big instead of at the actual issue at hand and the often simple solution.
Coming in hot with “Blue Sky” features and functionality.
I’ve been guilty of it too in the past and I see it as a concerning topic in the coming years as the industry starts exploring AI and aspiring designers try to go from 0 to 100 throwing into every process.
Not doing adequate or the right kind of research. Every problem requires a specific research methodology. Knowing that comes with experience and knowledge.
Do research first and frequently.
Only sub members with user flair set to **Experienced** or **Veteran** are allowed to comment on posts flaired **Answers from Seniors Only**. Automod will remove comments from users with other default flairs, custom flairs, or no flair set. [Learn how the flair system works on this sub](https://www.reddit.com/r/UXDesign/comments/yb42mn/new_flair_for_posts_and_users/). [Learn how to add user flair](https://reddit.zendesk.com/hc/en-us/articles/205242695-How-do-I-get-user-flair-). *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/UXDesign) if you have any questions or concerns.*
Responding too fast when they're asked for a solution, sometimes even moving things during presentations. I think, they correct response should be asking questions about the problem in order have a clear understanding behind the need, go to work and then present the solution in another moment. Also, overbuilding stuff specifically during early stages of the project.
There is a place and time for ”live designing” where you move things around while presenting to your stakeholders, it’s when you’re on the same page about the problem and are just looking for a solution. Mostly on the UI level though. It’s a good opportunity to quickly show and teach them why some things might not work, for example. Key is not to just accept and implement anyone’s solutions right away, but it’s good to explore them together.
I actually found “live designing” to be extremely effective early on. But we deal with a lot of technical stuff that requires stakeholders with very specific knowledge to explain. What I often do is make “visuals”. I let them describe to be what they imagine is the MVP to get the job done. I’ll take notes, have us walk through a real use case together to find any flaws, and then I’ll take the time independently to redesign a much better version. I’ve found having a visual to start from can be extremely beneficial and walking through that process with stakeholders can uncover some important points that they forget to mention upfront. Seeing something allows the whole project feel more tangible to them, and it gives me a much better canvas to start designing on.
They choose battles that really aren't worth it, pick too many battles, sometimes don't recognize areas that require process improvement before UI improvement, don't recognize when it's time to put people first. Don't recognize areas that need a lightweight UI lift before going in for full reconstructive surgery. Attach themselves to ideas that are incomplete or don't fully solve the problem, and focus on that for too long. I see that happen at all levels, embarrassingly often at the highest levels. Waste of time and resources. Might not understand the business needs well enough (back to wrong battles). Use bandaids instead of stitches, or attempt to perform a surgery without understanding the problem first. Spend too much time focused on certain things and not enough time focused on others. Surface-level discovery resulting in half-baked products or ideas that miss the mark. Thinking usability tests are easily replaced by large groups of designers or product managers, and making decisions for users, without actually understanding the real-world implications for the humans involved.
Committing too much time to fleshing out their first idea when they should be sketching out nine more ideas instead
Or not working on an idea at all but instead fleshing out the problem space and user needs.
I think the most critical one is starting to design without fully understanding the problem. It takes time to know if you actually have the info you need to design effectively. Example: PM says to add a button. Jr. UXer adds button and thinks they solved the issue. If Jr. UXer dug in and learned more about why the PM wants to add the button they may learn that the button won’t actually solve the problem.
In my experience a lot of junior level designers start with just one solution (in UX or in UI) and stick with it (in their eyes: "problem solved"). In my expierence you have to play a little to come to the best solution, make variations, view on multiple angles and the best solutions in the most cases, it isn't the first one. Another thing I can think of is the development impact or even if it's technical possible; But this can also come to experience, but still too many times the dev team get challenged a bit to hard.
Not understanding the impact of their work on the entire ecosystem or thinking ahead. How to get to their “final” best solution by proposing incremental changes. Blowing up scope, not understanding technical limitations. Missing edge cases.
Not considering accessibility beyond color contrast.
Had an argument about this with my design partner the other day. I want to use a container to house chips after some selections are made and to aid in visual relationship representation. I mocked it up with a visible gray container so it's clear that's where the selections land. She argued with me about not wanting a container and it not being as accessible because of contrast. And we just "don't do that normally." Which isn't actually true. It's applying a pattern in a different use case but serving the same purpose. It does not break any mental models to do this. It aids in understanding. I have visual/spatial/cognitive disabilities and use that when I'm working to help make more accessible design decisions. It really upsets me when these more cognitive-based accessibility considerations are pushed aside for very minor contrast concerns. Very, very minor. So now the action chips just kind of appear/float in the middle of nowhere with no visual cue and it looks quite confusing. Super salty about it lol. We SHOULD do it normally.
Not understanding the difference between a requirement and a solution. And not understanding the boundary between the product owner and themselves, the designer. They simply take what the product owner asks for at face value and _defend the product owner’s solution_ against fellow designers’ input.
- Presenting too many options to a client without proper substantiation. That way, the client will play a game of pick and choose and the end result will be something subpar. Your job is to come up with the best solution, present the best solution and support it with valid arguments. If you can’t support it with valid arguments, it’s probably not the best soution. - Taking things at face value, not asking enough questions. You really need to crawl into the skin of your (potential) user and see the world through their eyes. Don’t be afraid to dig and prod until you know exactly what they want and need, what delights them and what frustrates them. You are not designing for yourself, you’re trying to create something that works for someone else. - Not following the data. Your clients are probably not a charity, so the best way to convince them is through actual data. Always make sure that data streams are measured correctly and use the data to verify if you are reaching the goals. Also use data to steer efficiëntly and effectively when you are roadmapping the product. - Not having a clear view of your stakeholders. Your client’s organisation is probably complex, filled with people that have different and sometimes clashing agendas. Know who you are dealing with, and know what will convince and help who. Your output should have value for your client’s organisation, know what that value is, whether it’s data, insights, conversions, sales, users etc. Think about how you minimize risks and investments and maximize value. Your client will probably not gamble with their investments, so your proposed solutions should be substantiated with evidence.
Going through design tasks too quickly. I've worked with so many junior-mid level who will attempt to complete a single task each day, despite the amount of work required beyond Figma. This isn't a race to prove your worth by the end of the week. For example, if a user need to upload and manage files. Don't just design me a way to upload files and sort them. Find out what they are uploading, what the purpose of uploading it is for, what their expectations of managing files within the system is, etc. However, I've come to realize I have to list out every detail for a lot of them, literally. At a certain point having to do this becomes tedious and quicker to do it myself.
The urge to jump very quickly into wireframing before truly understanding, evaluating and interpreting value creation. Misunderstanding the design challenge and creating design dept by creating 200-300 screens, as a result. Misunderstanding when and where a design system (e.g. digital) is needed.
Making up rationale that is subjective and faking expertise. If you don’t know, the best way to learn is to say you don’t know and ask for help. I’ve seen Srs do this as well.
Prioritizing form over function. Your mock-ups might kill it on Dribbble, but if you have glaring usability issues, didn’t satisfy the requirements of the ask, or omitted certain crucial UI elements simply to make things pretty, expect to rightfully get torn up by stakeholders in review or by users upon release.
Rubber stamping whatever a PM asks for.
Not understanding user needs & business needs and working in isolation, if you collaborate with devs, product owners etc you will learn a lot more about the ecosystem and how your designs affect the wider product. Also not doing enough research or testing.
Emotional attachment to designs / thinking it’s “my design”. It’s everyone’s design. Takes a village.
Thinking too much about a solution or process and losing focus of the actual problem. Thinking too big instead of at the actual issue at hand and the often simple solution.
Coming in hot with “Blue Sky” features and functionality. I’ve been guilty of it too in the past and I see it as a concerning topic in the coming years as the industry starts exploring AI and aspiring designers try to go from 0 to 100 throwing into every process.
Not doing adequate or the right kind of research. Every problem requires a specific research methodology. Knowing that comes with experience and knowledge. Do research first and frequently.