Treat your portfolio like a design project because it is

After building at least eight versions of my portfolio over the years, I have now realized that there is no one solution fits all scenario here. Just like every company is different in its way of working and finding the optimal solution, so are the recruiters and hiring managers at those companies. The same applies to the designers. Each designer is different from the others, regardless of their accomplishment, every designer has a different way of working and judging designs based on their past experiences and insights. Hence, saying that one particular portfolio system works for everyone probably would be incorrect and short-sighted.

Also, it is fact that whenever designers jump into the hiring process, they are bound to get bored because more and more designers are following the same BootCamp advice for designing portfolios using a template system. It is quite natural to get bored looking at the same structure over and over again. The last time I looked at 35 BootCamp student portfolios, within the first few portfolio reviews I came up with a set of statements that could be applied and cherry-picked for all the portfolios that followed ahead.

I have found that rather than obsessing over a set-in-stone portfolio structure, it is best to focus on this four pillars framework for approaching a design portfolio as a project —

1. Problem framing
2. Solution defining
3. Thought process highlighting
4. Results sharing

Any framework like this one is optimal to solve a challenging problem because following it would give different results. If we are following a pre-defined structure then the end solution will start looking the same for all. Let’s dig deeper into what we can cover under each of the four pillars that I mentioned above.

#1 Problem framing

• Use words and visuals to describe the pain point that the product is facing. Try to paint a picture explaining why it is a pain point for the company to prioritize solving, how will it benefit the user, how will it benefit the business, and what goals will the company achieve.
• Try to look at the problem from the user, the business, and the team’s perspective. There are always more people involved than just the users. You have to address questions like but not limited to — Time a user wastes to come up with a hacky solution, money that the business might be losing because of the problem, and other problems that could be solved because of it.
• Don’t be blind to the development issues. How can the tech help in reducing the pain point, or be there constraints that the dev team is unable to build thru’ that are causing the pain points in the first place? When working on a digital solution, always consider the tech’s contribution in reducing or aggravating the pain point.

#2 Solution defining

After we have attacked the problem statement from all angles, it is time to alleviate the problem with a sound solution.

• Access your solution based on time, resources, and money that was saved. Also, try to address why this solution could solve all the problems that we have mentioned before.
• Explain how the solution was built by the tech teams, and what the challenges and edge cases involved in creating the solution in the shortest time possible.
• If your solution is big then try to break it down into chunks and versions. Define a reason for how different versions are broken down and what informed the decision.

#3 Thought process highlighting

• What else did you learn while solving the problem that you originally set out for? These might be things you learned on dev constraints, new situations, hiring cases, or legal issues. In your solution journey, describe when did you find out about them and from which teams or team members?
• When we solve one or more problems in the product, we are always bound to create new problems. These problems could either be looked at as positive or negative. But they are problems nevertheless. These problems could emerge while developing the solution midway. Make sure to describe what these new challenges were and how did you work your way through them.
• Further, describe the various facilitation sessions that you were part of and had to set up while coming up with the final solution. If you are not conducting and monitoring research sessions or discussions, this is your cue to get started.

#4 Results sharing

• In the results sharing, we are not going to be adding the impact that your solutions made. Forget what the BootCamps told you to do. Don’t write what you learned during the solutioning of the project.
• Share about the impact the solution made. How did you calculate that impact and over how long? Impact, confirmation screenshots, and people/domains you collaborated with to get the impact numbers. Additionally, you can describe how the impact increased as the feature went through alpha, beta, and full product releases.
• Further, describe how you plan to scale the solution as the impact and the user base increase.
• Describe how you would create automated and manual methods to capture feedback on the launched solution and create cycles for brainstorming and iterations.

That’s the end of this short yet hopefully insightful read. Thanks for making it to the end. I hope you gained something from it.

👨🏻‍💻 Join my content verse or slide into my DMs on LinkedIn, Twitter,Figma, Dribbble, and Substack. 💭 Comment your thoughts and feedback, or start a conversation!