When AI Makes the First Draft, Your Portfolio Needs to Show Your Judgment
A question keeps coming up in portfolio and interview conversations: What should I show when AI helped make the work?
It is a fair question. The first pass is cheaper now. A designer can use AI to generate directions, summarize research, write placeholder copy, explore interface patterns, or pressure-test an idea before a meeting. That does not make the work less real. It does change what a portfolio needs to prove.
A collection of polished screens was never the whole story. It is even less of the story now.
The useful question is not, “Did you use AI?” It is, “What did you decide, and why?”
That is what a hiring manager, product partner, or engineer is trying to understand. Can you spot the real problem underneath a request? Can you tell a plausible direction from a useful one? Can you notice the constraint an output ignored? Can you explain what changed after you put something in front of a user or teammate?
AI can help make an artifact. It cannot make those decisions for you.
Do Not Hide the Tool. Do Not Make It the Case Study.
The two easy mistakes are hiding AI use because it feels like an admission, or making the tool the whole story: the prompts, the generated variations, the polished screens.
Neither gives the person reviewing your work what they need.
Use the tool honestly, as you would mention research software, a component library, or a prototype platform. Say where it helped and where it did not. Then move back to the work that required judgment.
For example:
> I used AI to explore a few content structures before the team had settled on the workflow. The early directions helped us see the range of possibilities, but they also assumed users understood terms that our research showed were unfamiliar. I narrowed the flow, rewrote the language with the content team, and tested the revised path with people new to the product.
That tells a much stronger story than “I used AI to redesign onboarding.” It makes the tool visible without giving it credit for the decision.
Start With the Decision, Not the Deliverable
Junior designers are often taught to build a case study around the process: discovery, research, wireframes, final UI, outcome. That structure is useful, especially when you are learning how to tell a complete story.
But it can become a hiding place. A reader gets a long tour of activities without ever learning what the team had to decide.
Try beginning with the tension instead.
Not: “I redesigned the account-setup experience.”
More like: “We needed to help first-time users finish setup without removing the controls that experienced users depended on.”
Now the project has a real question inside it. The screens become evidence of how you answered it.
When you do not have perfect access to metrics, do not invent an outcome. Show the decision, constraints, evidence, and what the team learned next. The work may be solid; the story still needs to make your contribution legible.
Show Where You Changed the Work
AI makes it easier to create a convincing first answer. It also makes it more important to show the moment you decided that answer was not enough.
Look for one of these moments in each case study:
- A research finding that changed the team’s assumption.
- A technical constraint that changed the interaction or scope.
- A content or accessibility issue that made a seemingly clean pattern fail.
- A stakeholder concern that revealed a missing part of the problem.
- A prototype or test that made the first direction less credible.
These are not detours from the design process. They are the process.
One reason I keep encouraging designers to name tradeoffs is that they make judgment visible. A final screen often looks inevitable after the fact. The tradeoff explains why it was not.
Maybe the team chose a simpler first release and deferred a more flexible path. Maybe the accessible interaction added implementation work but avoided a predictable failure mode. Maybe the most visually impressive direction created too much cognitive load for the people using it.
A portfolio reviewer can learn a lot from how you explain that choice. So can a product or engineering partner. It shows whether you see design as a sequence of outputs or as a way to help a team make better decisions.
I wrote about the signals that tell you design is working for a similar reason. Better decisions, less friction, and faster learning often appear before a clean dashboard metric does. They still count as evidence when you can describe them precisely.
Keep a Small Record of Your Reasoning
You do not need to document everything. You do need enough material to reconstruct the story later.
For each project, keep a lightweight record of four things:
- The question. What did the team need to decide?
- The evidence. What did you learn from users, partners, constraints, or experiments?
- The tradeoff. What did you prioritize, and what did you accept as a cost?
- The next signal. What happened after the work, or what would you test next?
If AI was part of the work, add one more line: what did it accelerate, and what still required human judgment?
That last line is not a disclaimer. It is a way to be clear about authorship. You do not own every input into a product decision. You own the way you worked with those inputs, challenged them, and helped the team move forward.
This is close to what I mean by framing work around the decision it enabled. A portfolio is not just a record of what you made. It is an argument about how you think.
Practice Explaining the Parts That Are Not on the Screen
A portfolio review is still a conversation, not a guided tour through a deck.
Someone may ask how engineering reacted to a direction. They may ask what you would do differently. They may ask why a promising option did not make it to launch. Those are not gotcha questions. They are opportunities to show the parts of the work that a polished screen cannot carry on its own.
AI can be useful in preparation here. Ask it to play a skeptical product leader, an engineering partner, or a hiring manager. Have it question your assumptions. Notice where your explanation becomes vague, overly polished, or dependent on the next slide. Then rewrite the story in your own words.
The point is not to generate a more persuasive script. It is to find the gaps in your reasoning before someone else does.
The Work Is Still Yours When the Judgment Is Yours
I do not think junior designers need to prove that they avoided AI. That would be a strange standard for a profession built on using tools well.
They do need to show that they can work beyond the tool.
Can you turn a loose request into a product question? Can you decide which evidence matters? Can you catch an answer that looks plausible but does not fit the user, the business, or the implementation? Can you explain the tradeoff without pretending there was a perfect option?
Those are durable skills. They matter whether the first draft came from a blank Figma file, a design system, a teammate, or an AI prompt.
Before you add your next case study, ask one simple question: If I removed the final screens, would a reader still understand the judgment I brought to the work?
If the answer is yes, the portfolio is doing more than displaying your output. It is showing how you can help a team move through uncertainty.
For more writing on design leadership, product collaboration, and the practical use of AI, visit iamkeeler.com or connect with me on LinkedIn.