What I'm Actually Looking For When I Evaluate Your Work

A few weeks ago I sat in on a student critique at a community college here in Denver. Eight projects, seven minutes to present, four minutes for feedback. It moves fast.

I was there as an industry guest, which meant I was evaluating student work the same way I evaluate work at my job — looking for evidence of thinking, not just evidence of effort. That vantage point taught me something worth sharing, because most students don't get a window into what's actually going through a working designer's head during a critique.

This isn't a guide to preparing for a critique. There's a lot that goes into deciding what to show, what to say, and how to fit it into seven minutes, and that's a different conversation. This is about what I observed, and what those observations mean for how you think about your work.

What I’m Looking For When You Present

Critique is not a performance review. It's a rehearsal for a portfolio review, a design critique at work, a presentation to a stakeholder who doesn't share your assumptions. The feedback you get in a classroom is preparing you for a much higher-stakes version of that same conversation.

So here's what I'm actually watching for.

I start with something specific that genuinely stood out. Not "good job" — that doesn't tell you anything. "Your problem statement was really sharp" tells you what strong work looks like. Specificity is the whole point.

From there I limit myself to two pieces of feedback. Four minutes goes fast, and two clear actionable things will stay with you longer than a list of everything that could be improved.

I also try to vary my feedback across students. If I've already raised competitive research with one presenter, I'll look for something different to surface with the next. A critique isn't just for the person presenting — everyone in the room is learning. The feedback you hear directed at someone else is often just as applicable to your own work.

I try to ask questions rather than make declarations. "How did you validate that assumption with users?" opens a conversation. It's less deflating than a verdict, and sometimes you have context that changes my read entirely.

What I'm not looking at: spelling errors, visual polish, minor inconsistencies. That's not what this moment is for.

What I am looking at: process over polish. Evidence of research, ideation, and iteration. Whether real users were considered or whether you're solving for your own assumptions. Whether you can explain why you made the choices you did. And whether you show any self-awareness about what you'd do differently.

One thing I'm deliberate about is the difference between personal preference and principle. "I would have approached the navigation differently" is a stylistic opinion. "This navigation pattern may create confusion for first-time users because it doesn't follow established conventions" is grounded in UX practice. You need to know which kind of feedback you're getting. One is optional. The other carries weight.

What I Observed Across Eight Projects

These patterns aren't unique to that room. They're the same ones I encounter in the industry every day.

Start with why

The "why this problem" was often missing. I want to know why you chose this problem, why now, and why an app is the right solution. One data point showing there's a real need would have changed the framing of several presentations entirely. "I thought this would be useful" is a starting point, not a rationale.

Know who you're designing for — and what they need to do

Most students had personas, often built from people they'd actually interviewed, which was great to see. What I wanted to see more of was the bridge between the persona and the product. Jobs to be done asks a simple but essential question: what is this person trying to accomplish, and how does your product solve that in a way nothing else does? A persona tells me who your user is. Jobs to be done tells me why your product should exist.

Look at what already exists

Competitive research came up repeatedly as a gap. Not just looking at similar apps, but understanding how the field has already solved adjacent problems. One project touched on gamification, and there's a rich body of work across fitness apps, language learning, and finance tools on how to show progress and encourage commitment. You don't have to invent that from scratch. Sometimes the most useful research isn't even in your category.

Accessibility is a system, not a checkbox

Accessibility awareness was present but inconsistently applied. Color contrast kept coming up as a miss, often because testing had focused on one combination without running through all the iterations. Awareness is the first step. Systematic checking is the habit.

Design for where and how it will actually be used

Context of use went unexplored in several projects. One in particular prompted the question: is this app meant to be used in real time, or is it a planning tool? Those are completely different design problems. If it's real time, how does the phone communicate with other screens nearby? Designing without a mental model of where and how something lives in someone's day leaves a lot of decisions unmade.

Understand where your screen ends and the experience continues

Most of the screens I saw were designed to fit entirely within the phone viewport. For onboarding flows and step-by-step interactions, that's often right. But dashboards, forms, and content-heavy screens usually need to scroll. What I couldn't tell was whether students were adding more taps and screens to avoid scrolling, or whether they simply hadn't considered what lived below the fold.

This is one of the sharpest differences between print design and digital design. Print is a fixed frame. Digital is a system of connected states, and some of those states extend beyond what's immediately visible. That shift in thinking is a big part of what UX actually is.

Think beyond the form factor

Nearly every project was a mobile app. I don't know whether that was a constraint or a default. Either way the principle holds: always be looking for ways to demonstrate UX as a discipline, not a category of product.

A few years ago I saw a student project for a smart mirror. I've never seen another student do that. I still think about it, not because it was technically impressive, but because it showed someone who understood that UX lives everywhere people interact with technology. That's the signal hiring managers and senior designers are looking for.

You are in the best possible position to try something unexpected. The problems are smaller, the stakes are lower, and that window is shorter than you think.

Choose your depth intentionally

Breadth versus depth is a real tradeoff, and worth being intentional about. If you went wide on this project, go deep on the next one. Hiring managers aren't looking for one perfect piece. They're looking for range, and that's easier to show across your portfolio than within a single project.

On AI: A Tool, Not A Skill

AI was absent from every project I saw, at least as far as I could tell. My honest first reaction was that it was refreshing. But the industry asks about it in nearly every job interview right now, so it's worth being clear about what AI actually is at this stage of your career.

It's a tool. Not a skill.

Think of it the way you think about Figma. Figma doesn't replace design skills. It's the environment where you apply them. AI is the same. It can help you go wide, narrow in, and speed things up. It can assist with sketching, research synthesis, and ideation. But it can't replace the underlying thinking, and leaning on it before you've built that foundation will show.

Where AI does become a skill is when you're designing for it, building products and features that incorporate AI capabilities. That's a distinct discipline worth learning. But you don't need to use AI tools to do it, just like you don't need to use Figma to think about interface design.

Right now your job is to learn the fundamentals. AI is there to assist with that, not shortcut it. And if there is one place to experiment with AI without consequence, it is while you are still a student. Try it. See what it can and can't do for your process. You won't get that freedom back.

The Thing Worth Leaving With

There was a moment during one presentation that I called out in the room, because I wanted every student there to hear it.

A student walked us through how their research had shifted their design direction. Not just what they learned, but how it moved them somewhere different than where they started. They had made decisions, and they could explain why, and those decisions were grounded in something real.

That is exactly what a hiring manager is looking for when they ask you to walk them through your process. They're not admiring the final screen. They're testing whether you can defend your decisions, whether the work is reasoned, not just rendered.

One of the first questions I ask when a student or early career designer shares their work with me is what feedback they've received previously and how they incorporated it. It's the same question I'm asking when I want to know how your research shaped your decisions. The work should show that something moved. That you heard something, or learned something, and let it change the direction.

Feedback is subjective, and not all of it will be right for your work. But dismissing it is a habit that will follow you.