UX Portfolio Mistake You Must Avoid | Pro Tip #uxdesign #ux

UX designers should avoid random website redesigns in portfolios. Recruiters want to see you find real user problems, validate them with actual users, and test solutions with data. Start with friction you notice, write a problem statement, talk to your target users, then run small A/B tests and show the results.
Chapters
Please stop redesigning random website for your case study or UX portfolio. Try to understand that when recruiters are actually hiring you or the product managers look into your case studies or portfolio, they are looking forward for a real-time problem statement that somebody is facing and you identified it, and then the approach that you took to solve that problem statement in the very first place. Redesigning a random website do not talk about anything because you don't know any context about the performance of that website or performance of that app, because every website or a product that is live into the market has its own own analytical tools to track multiple success metrics. For example, the average time spent, bounce rate, conversion ratio, or the average active users on monthly and yearly basis. So that is why redesigning something is not going to actually help you get a job or improve UX design skills. To solve a problem statement for your UX case study or portfolio that will actually make sense, all you need to do is make sure to identify a problem statement that you are facing in your day-to-day activity. For example, any app that you use in your day-to-day life where you think this is not doing right, this is taking a lot of my efforts or it's taking a lot of my time to find something that I want to do in that app. And once you find that, make sure you redefine that problem statement in a very detailed manner, document that problem statement, and at the same time now validate that problem statement with people like you, like people like your persona or target audience that belongs to your same age group. Now once you talk to the people, make sure that try to understand their entire journey, how do they actually behave or use that app. And if you think a lot of people, for example, 5, 10, or 15 group of people are actually facing the same issue in that same specific app, what you can do is actually document the entire finding and then put forward your assumptions or hypothesis saying that, you know what, X percentage of these people are facing this issue. So my assumption or hypothesis is that XYZ percentage of users across India might be facing the same issue. That is why I decided to solve this problem statement. Well, do not randomly pick up any problem statement and start solving because you want to do it. Make sure that every time you pick up a problem statement, you have to validate the problem statement with a lot of other people in the same age group or same criteria. And once you validate the problem statement, then start solving the problem statement. And while you solve the entire problem statement by whatever method that you follow, make sure that you also validate the solution that is come up and do a small A/B testing with multiple people in a group of 5, 10, or 15. And only then make sure that value, give up the entire presentation, put up the metrics as the success metric that was before and after the solving problem statement that you did.
More from Anirudh

Which is the best UX Portfolio Platform: Website, Notion, Behance, or Dribbble?









