How to Revise a Portfolio Project Description in English

Many portfolio descriptions sound polished and still leave the reader empty-handed. The draft says innovative, user-centered, data-driven, collaborative. It lists Figma, Python, SQL, Tableau, Notion, maybe three more tools. By the end, you know the writer has software, but not what they actually did. A project description should help the reader picture your work, not your adjective collection.

A useful structure follows four parts: problem, role, action, result. What was broken, unclear, slow, risky, or worth redesigning? What part did you own inside the team? What did you actually do: interviews, prototyping, cleaning data, shaping hypotheses, testing flows, rewriting copy, coordinating a handoff? Then what changed? Even a modest result can work if it is real: clearer workflow, fewer revisions, faster onboarding, stronger user feedback, better team alignment.

International students often turn the middle of the paragraph into a tool parade. Tools matter, but only after the action is clear. Saying you used SQL is less informative than saying you cleaned support-ticket exports in SQL to identify recurring onboarding failures. The second sentence has a job. The first one has a badge. Readers usually care more about judgment than software inventory.