You’ve finished the Figma course. Your components are clean, your auto-layout actually works, and your mockups look genuinely polished. You’ve sent out thirty applications. You’ve heard back from almost none of them.<\/p>\n\n\n\n
Here’s what’s happening. The portfolio reviewer isn’t checking whether you can use Figma. Everyone applying already can. They’re checking for something your screens don’t show: how you think. This article names the six skill areas that actually separate a hired junior designer from a tutorial graduate, and for each one, exactly what a reviewer needs to see in your case study as proof. Along the way, you’ll also get the real red flags and green flags reviewers look for, and a case study structure you can build against directly.<\/p>\n\n\n\n
Here’s the thing nobody tells beginners clearly enough. Figma is a tool. Tools are table stakes. Nobody gets hired for knowing how to use a hammer, and nobody gets hired purely for knowing how to use Figma either.<\/p>\n\n\n\n
What actually gets a portfolio disqualified, again and again, is the same pattern: screens with no visible thinking behind them. No research. No explanation of why one layout won over another. No sign that any real user ever looked at the design before it got called “final.” A reviewer scanning a stack of portfolios in a single afternoon learns to spot this instantly, and it’s the single fastest way to get passed over.<\/p>\n\n\n\n
The fix isn’t more polish. It’s evidence. Every skill in this article gets tied to one question: what does this look like when a reviewer opens your case study? If you can’t point to something concrete, the skill doesn’t exist yet, no matter how confidently you can talk about it in an interview.<\/p>\n\n\n\n
A portfolio reviewer forms an opinion fast, often within the first minute of opening a case study. Here’s roughly what tips that opinion in each direction.<\/p>\n\n\n\n
Red flags:<\/strong><\/p>\n\n\n\n Green flags:<\/strong><\/p>\n\n\n\n This isn’t a formal scoring rubric. It’s closer to a gut check that experienced reviewers develop after looking at hundreds of portfolios. But it’s consistent enough that you can audit your own work against it honestly, right now, before you send out another application.<\/p>\n\n\n\n Research is the skill most junior portfolios claim and least actually demonstrate. A single line reading “conducted user research” with no detail attached is worse than saying nothing, because it signals you know the word matters without showing you did the work.<\/p>\n\n\n\n Real research skill covers a few concrete methods:<\/p>\n\n\n\n The evidence bar a reviewer is looking for is specific. Real participants, even a small number. Notes or a synthesis document, not just a polished insight slide. And critically, a decision that changed because of what you learned. If your research findings and your final design would look identical whether or not you’d done the research, that’s the tell that it was decorative rather than real. The Nielsen Norman Group is the standard reference if you want to study research methods properly rather than picking them up secondhand from a bootcamp summary.<\/p>\n\n\n\n Watch out for these, since they’re extremely common and reviewers spot them immediately.<\/p>\n\n\n\n What this looks like in a case study:<\/strong> a short research plan, three to five real interview or usability-test summaries, one synthesised insight stated plainly, and one specific design decision you can point to and say “this changed because of what I found.”<\/p>\n\n\n\n This is the invisible skill, and it’s exactly why it gets skipped. Nobody notices good information architecture. Everybody notices bad information architecture, because it’s the reason a product feels confusing to use even when every individual screen looks fine.<\/p>\n\n\n\n Information architecture covers how content and features get organised and labelled so people can actually find what they need. Flows cover the paths a user takes to complete a task, including every decision point and every place they could get stuck or drop off.<\/p>\n\n\n\n This is the skill that separates a portfolio full of pretty screens from a portfolio that shows an actual product. A collection of beautiful mockups with no visible logic connecting them reads as a design exercise. A sitemap and a user flow diagram, with reasoning attached to the structure, reads as a product decision.<\/p>\n\n\n\n A concrete example worth practising on: take any checkout flow or onboarding flow from an app you use regularly, and map every screen and decision point on paper. Note where a user could get confused, where they could abandon the flow, and what you’d change. This single exercise, done honestly, builds IA thinking faster than any tutorial ever will.<\/p>\n\n\n\n What this looks like in a case study:<\/strong> a sitemap or flow diagram showing how a user moves through the product, plus a sentence or two explaining why you grouped or ordered things the way you did, not just what the final structure is.<\/p>\n\n\n\n This is the fastest differentiator available to a junior designer, mainly because almost nobody does it. Most tutorial-trained portfolios skip accessibility entirely, which means even a basic, honest attempt puts you ahead of most of the stack a reviewer is looking at.<\/p>\n\n\n\n WCAG 2.2 is the current, stable standard to work from. A newer version, WCAG 3.0, is still in early draft status at the W3C and isn’t expected to become a finalised standard for a few more years, so 2.2 is what you should actually be designing against right now.<\/p>\n\n\n\n You don’t need to be a screen-reader expert to cover most of this. You need to actually check each item once per project instead of skipping the section entirely, which is what most junior portfolios do.<\/p>\n\n\n\n What this looks like in a case study:<\/strong> a short, explicit note on the accessibility decisions you made, contrast ratios you checked, how you handled labelling, or how a flow works with keyboard-only navigation. Even three or four sentences here signal real awareness, since so few junior portfolios include this at all.<\/p>\n\n\n\n Visual craft is real and it matters, but it’s not the same thing as picking an attractive template and swapping in your own text. Reviewers can tell the difference immediately, because template-based work tends to look polished but generic, with no sense of intentional decision-making behind spacing, type, or hierarchy.<\/p>\n\n\n\n Real visual craft comes from a few trainable habits:<\/p>\n\n\n\n Pick five real products you genuinely enjoy using. Screenshot one key screen from each. Annotate every screenshot with what you notice: why the spacing works, what the type hierarchy is doing, how colour is used to draw attention. Do this weekly. It trains your eye far faster than following template tutorials, because you’re studying decisions made by people solving real constraints, not decorative choices made for a course.<\/p>\n\n\n\n The strongest evidence of visual craft isn’t a polished final screen. It’s showing your iterations. A single perfect-looking mockup could be luck, a template, or a hundred hours of unseen struggle. A visible sequence of rough, then better, then final, with a sentence on what changed and why, proves the craft is actually yours.<\/p>\n\n\n\n What this looks like in a case study:<\/strong> two or three iteration snapshots of a key screen, shown side by side, with a short note on what you changed and why the later version is stronger.<\/p>\n\n\n\n This is arguably the single most important skill on this list, because it’s the skill your entire case study is actually built from. Every other skill above only counts if you can communicate it clearly.<\/p>\n\n\n\n A strong case study follows a narrative, not a screen gallery: what was the problem, what did you explore, what decisions did you make and why, and what actually happened as a result. Reviewers read dozens of these. The ones that stick are the ones where you can follow the designer’s thinking from start to finish, including the parts that didn’t work.<\/p>\n\n\n\n This skill also extends beyond the page itself. It’s how you present your work out loud, how you respond to a stakeholder who pushes back on a decision, and how you take critique without either caving immediately or getting defensive. A useful habit in critique: resist the urge to explain or justify right away. Listen fully first, ask a clarifying question if the feedback is vague, and only then respond. Designers rarely work alone, and in most real jobs you’ll be explaining and defending decisions to product managers and engineers constantly. If you want a sense of how product managers think about collaboration and trade-offs, the product manager roadmap is a useful adjacent read, since a meaningful part of a designer’s job is communicating effectively with exactly that role.<\/p>\n\n\n\n What this looks like in a case study:<\/strong> a clear structure of problem, exploration, decision, and outcome, written so someone unfamiliar with the project can follow your reasoning without you standing next to them explaining it.<\/p>\n\n\n\n Design doesn’t happen in a vacuum, and reviewers notice quickly when a portfolio reads as it does. Two things separate designers who understand this from designers who don’t.<\/p>\n\n\n\n Metrics awareness.<\/strong> <\/p>\n\n\n\n What did your design actually move? Even on a self-initiated project, you can frame outcomes in terms of what you were trying to improve: task completion time, drop-off at a specific step, clarity in usability testing, the number of taps needed to complete a core action. Designers who can talk about outcomes, not just deliverables, read as more senior than their experience level suggests. If you don’t have real usage data, say so honestly, and state the metric you’d track if the project shipped. That’s still a meaningfully stronger signal than no metric at all.<\/p>\n\n\n\n Implementation literacy.<\/strong> <\/p>\n\n\n\n You don’t need to code professionally. But a working sense of how HTML and CSS actually structure a page changes how you design. It makes your handoffs to engineers smoother, and it stops you from designing things that look great in Figma but are needlessly painful to actually build, like spacing values that don’t map to any real system, or interactions that sound simple in a prototype but are genuinely difficult to implement. If this is unfamiliar territory, spending time with real HTML\/CSS projects is worth it purely for the intuition it builds, even if you never write production code yourself.<\/p>\n\n\n\n What this looks like in a case study:<\/strong> a sentence or two connecting your design decisions to a business or user outcome you were targeting, and, where relevant, a note on how you considered implementation constraints during the design process rather than after handoff.<\/p>\n\n\n\n Here’s the whole framework in one place. Use this as a literal checklist against your own case studies.<\/p>\n\n\n\n The practical standard to aim for: three strong case studies that each hit most of these six areas beat ten shallow ones that hit none of them. A reviewer spends minutes, not hours, on a first pass through your portfolio. Depth on a few projects reads as competence. Breadth with no depth reads as volume for its own sake.<\/p>\n\n\n\n A workable pattern: one flagship case study that goes genuinely deep and hits all six skills, shown first. Two supporting case studies that each show range, a different product type, a different constraint, a shorter timeline, so the reviewer sees you’re not a one-trick portfolio. Anything beyond three or four projects usually starts diluting attention rather than adding to it, unless each additional project is genuinely distinct and equally strong.<\/p>\n\n\n\n Go back through your existing case studies with the table above open. For each skill row, ask honestly whether a stranger could find the evidence in under thirty seconds. Wherever the answer is no, that’s your next edit, not a whole new project.<\/p>\n\n\n\n If you’re mapping out the full learning sequence rather than auditing an existing portfolio, the UI\/UX Designer Roadmap walks through that path in order, from fundamentals through to a job-ready portfolio.<\/p>\n\n\n\n Is Figma enough to become a UI\/UX designer?<\/strong> <\/p>\n\n\n\n No. Figma is the table-stakes tool that almost every applicant already knows. Hiring actually runs on research skills, information architecture, accessibility awareness, and the ability to explain your design decisions clearly in a case study.<\/p>\n\n\n\n What skills do UI\/UX designers need besides tools?<\/strong> <\/p>\n\n\n\n User research, information architecture, accessibility grounded in WCAG, visual craft that goes beyond templates, design communication, and business and implementation framing. Each one needs to be provable through your portfolio’s case studies, not just claimed in a bullet point.<\/p>\n\n\n\n How do I show UX research skills without a job?<\/strong> <\/p>\n\n\n\n Run real research, even at a small scale, on a self-initiated project. Five usability tests with real participants, honestly documented, plus one decision your findings actually changed, is worth more to a reviewer than a vague claim of research on a bigger, unproven project. Authenticity beats scale here.<\/p>\n\n\n\n Do UI\/UX designers need to know HTML and CSS?<\/strong> <\/p>\n\n\n\n Not to code professionally. But a working sense of how a page is actually structured and styled makes your engineering handoffs smoother, and many teams genuinely value that fluency in a junior designer even though it isn’t a strict requirement.<\/p>\n\n\n\n What makes a UX case study strong?<\/strong> <\/p>\n\n\n\n The decision narrative. How the problem emerged, what your research actually showed, which directions you considered, why you chose the one you did, and what changed as a result. A reviewer should be able to follow your thinking from start to finish without you standing next to them explaining it.<\/p>\n\n\n\n Why do UI\/UX portfolios get rejected?<\/strong><\/p>\n\n\n\n Most commonly, screens with no visible process behind them. No research documentation, no iterations, no rationale for the decisions shown. Evidence of clear thinking consistently beats visual polish alone.<\/p>\n\n\n\n How many projects should be in a UX portfolio?<\/strong> <\/p>\n\n\n\n Three to four strong, distinct case studies beat ten shallow ones every time. Lead with one flagship project that goes deep on all six skills, then support it with projects that show range across different product types or constraints.<\/p>\n\n\n\n Should I include a purely visual project with no research process?<\/strong><\/p>\n\n\n\n It’s fine as a supporting piece if it’s clearly framed as a visual or UI exercise rather than a full UX case study. Just don’t let it be your flagship project, and don’t present it as though it went through a research process it didn’t.<\/p>\n\n\n\n Figma got you in the room to learn the craft. It won’t get you the interview on its own, because everyone else applying already knows it too. What actually gets you hired is proof that you can research a real problem, structure a real product, design with real people in mind, and explain your thinking clearly enough that a stranger can follow it.<\/p>\n\n\n\n Pick one existing case study, run it against the six-skill checklist above, and fix the weakest row first. That single edit will do more for your callback rate than another week spent polishing pixels in Figma.<\/p>\n","protected":false},"excerpt":{"rendered":" You’ve finished the Figma course. Your components are clean, your auto-layout actually works, and your mockups look genuinely polished. You’ve sent out thirty applications. You’ve heard back from almost none of them. Here’s what’s happening. The portfolio reviewer isn’t checking whether you can use Figma. Everyone applying already can. They’re checking for something your screens […]<\/p>\n","protected":false},"author":241,"featured_media":14266,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35],"tags":[565],"class_list":["post-14265","post","type-post","status-publish","format-standard","has-post-thumbnail","category-software-development","tag-ui-ux-designer-skills"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts\/14265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/users\/241"}],"replies":[{"embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/comments?post=14265"}],"version-history":[{"count":1,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts\/14265\/revisions"}],"predecessor-version":[{"id":14267,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/posts\/14265\/revisions\/14267"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/media\/14266"}],"wp:attachment":[{"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/media?parent=14265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/categories?post=14265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.scaler.com\/blog\/wp-json\/wp\/v2\/tags?post=14265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
<\/span>Skill 1: User Research (Documented, Not Decorative)<\/strong><\/span><\/h2>\n\n\n\n
\n
The most common research mistakes junior designers make<\/strong><\/h3>\n\n\n\n
\n
<\/span>Skill 2: Information Architecture and Flows<\/strong><\/span><\/h2>\n\n\n\n
Two methods worth learning by name<\/strong><\/h3>\n\n\n\n
\n
<\/span>Skill 3: Accessibility (WCAG as the Baseline)<\/strong><\/span><\/h2>\n\n\n\n
A practical accessibility checklist for designers<\/strong><\/h3>\n\n\n\n
\n
<\/span>Skill 4: Visual Craft Beyond Templates<\/strong><\/span><\/h2>\n\n\n\n
\n
Teardown practice, a concrete exercise<\/strong><\/h3>\n\n\n\n
<\/span>Skill 5: Design Communication (The Decision Narrative)<\/strong><\/span><\/h2>\n\n\n\n
The anatomy of a case study that actually works<\/strong><\/h3>\n\n\n\n
\n
<\/span>Skill 6: Business and Implementation Fluency<\/strong><\/span><\/h2>\n\n\n\n
<\/span>The Portfolio Evidence Checklist: Putting It Together<\/strong><\/span><\/h2>\n\n\n\n
Skill<\/strong><\/td> What a reviewer is checking for<\/strong><\/td> What proves it in your case study<\/strong><\/td><\/tr> User research<\/td> Real research, not a decorative mention<\/td> Interview or usability-test summaries, a stated insight, a decision that changed because of it<\/td><\/tr> Information architecture<\/td> Logical structure behind the screens<\/td> A sitemap or flow diagram with reasoning attached<\/td><\/tr> Accessibility<\/td> Awareness of WCAG basics<\/td> Explicit notes on contrast, semantics, or keyboard navigation<\/td><\/tr> Visual craft<\/td> Intentional decisions, not template defaults<\/td> Visible iterations, not just a polished final screen<\/td><\/tr> Design communication<\/td> A followable decision narrative<\/td> Problem, exploration, decision, outcome, structured clearly<\/td><\/tr> Business and implementation fluency<\/td> Awareness of outcomes and constraints<\/td> A stated goal metric and any implementation considerations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n How to structure the portfolio itself<\/strong><\/h3>\n\n\n\n
<\/span>Frequently Asked Questions<\/strong><\/span><\/h2>\n\n\n\n
<\/span>Where This Leaves You<\/strong><\/span><\/h2>\n\n\n\n