Forty Applications, Nine Projects, No Replies
By Yemi Ogundairo on
A tech portfolio that gets replies shows two or three projects, not nine. Each one opens with a single sentence saying what problem you worked on and what you did about it, then shows the decisions you made along the way, including the ones that did not work. The person reading it is skimming on a phone between meetings. If they cannot tell what you are good at within the first screen, they close the tab, and no amount of polish further down will be seen.
That is the whole answer. The rest of this post is why it holds, told through two people who did nearly everything the same way. Both are composites, but anyone who has hired a junior designer will recognise them.
Same course, same month, different inboxes
Tolu and Kemi finished the same design course in the same month. Both sent about forty applications over the following six weeks. Both had a portfolio link at the top of every CV.
Tolu's portfolio had nine projects. A food delivery app, a banking app, a fitness tracker, a travel booking site, a music player, and four more. Every one had beautiful screens. Gradients, mockups on floating phones, the lot. He had spent most of his evenings for a month making them look right.
Kemi's had three. One was a redesign of how a bus park near her house sold tickets, which she had worked on after spending two Saturday mornings watching people queue and asking five of them what annoyed them. The screens were plainer than Tolu's. One of the three projects was openly unfinished, with a note saying what she would do next.
Tolu heard nothing. Kemi got four replies and two interviews.
What the person reading it is actually doing
The mistake Tolu made was imagining his portfolio would be studied. It was not. It was opened on a phone, on mobile data, by someone with sixty other links in a spreadsheet and a meeting in ten minutes.
That reader is not asking "is this person talented". They are asking something narrower and more practical: can this person do the job I am hiring for, and can they explain their thinking to my team. Nine projects with no explanation answer neither. They show that you can use the tool, which every other applicant can also do.
Three projects with reasoning answer both questions at once.
Three projects, and why three
Three is enough to show range and few enough that each one gets read. Pick them on purpose.
One that starts from a real problem you observed. Not "a banking app" but "why people at my local POS stand keep asking the agent to repeat the balance". Specific beats impressive.
One that shows you can work inside constraints. A brief from a real person, a tight deadline, an old phone your users actually carry, a budget. Constraints are where design decisions come from.
One that shows depth or a second skill. A project you took further than the others: tested, rebuilt, shipped, or coded. If you can build, show that it runs.
Everything else goes. Not into a "more work" section either, because a reader who sees twelve thumbnails assumes the best ones are hidden among them and stops looking.
The first screen of each project
This is the part that decides whether the rest gets read. The top of every case study should say, in one or two plain sentences:
What the problem was, who had it, what you did, and what changed.
"Ticket buyers at Oshodi were queuing twice because the agent could not see which seats were sold. I designed a seat view for the agent's phone and tested it with three agents over a week." That is enough to earn the scroll. "A seamless, user-centric ticketing experience" is not, because it says nothing a reader can check.
Below that, show the work in the order it happened. What you found, what you tried first, why you changed your mind, what you would do with another month.
Show the mess on purpose
Tolu's projects looked finished, which sounds like a strength and is not. A finished-looking project with no story implies that the first idea was the right one, and experienced readers know that is never true.
Kemi's unfinished project worked in her favour. Her note said she had tested the first version with three people, two of them could not find the button to confirm, and she had redesigned it but had not yet tested the second version. That one paragraph showed more design ability than any of Tolu's mockups, because it showed her noticing she was wrong and doing something about it.
Hiring managers are not hiring someone who gets things right first time. They are hiring someone who finds out quickly when they have not.
The link itself is part of the portfolio
Small things that lose replies before anyone sees your work:
A link that opens a 40MB PDF on mobile data. Many people will not wait for it.
A Figma file with view access switched off. You will never know how many people hit that wall.
A portfolio site that takes ages to load because every image is full resolution.
A password with no password in the application.
Open your own link on your phone, on data, with Wi-Fi switched off. Whatever you experience in the first ten seconds is what the reader experiences.
What to do tonight
Pick your three. Be ruthless. Keep the one with the most real reasoning, not the prettiest screens.
Rewrite the first two sentences of each to say problem, person, what you did, what changed.
Add one paragraph to each about something that did not work.
Open the link on your phone, on data, and fix whatever annoys you.
None of that needs a new project. Most portfolios that get no replies have enough work in them already. It is just buried.
Where real projects come from
The hardest part for most people is the first item on that list, a project that starts from a real problem rather than an imagined app. If you are still at the stage of choosing a direction, our guide to choosing a tech track is the place to start.
If you want a project you actually ship, with a real user and real decisions to write up, that is what DSGN Launchpad is built around: six weeks, a working product at the end, and a case study you can put first in your portfolio.