Portfolios: Thoughts from an intern review

At Amazon, the first time UX teammates see our potential candidate pool is what’s called a “materials review.” A group of 3 people has 90 minutes to review 15 candidates, and judge if they’ll move on to a phone screen and the actual interview loop. This means you have 6 minutes to make an impression on the reviewers. If you’re a candidate, this probably seems horrifically unfair. You (hopefully) spent far more time pulling together your case studies, and you’d like the reviewers to invest a fair chunk of time when reviewing them.

That’s not going to happen.

You need to evaluate your portfolio and understand if, in a 5 minute review, a hiring manager can see the contributions, quality, and impact of your work. This review isn’t everything – it’s just there to understand if you’re worth pursuing further, or if you’re immediately going in the rejection pile.

Note: As of this writing, I haven’t significantly updated my website in years. It doesn’t follow my own advice.

My advice

Make sure I can view multiple projects at the same time. Most reviewers try to open every project in a new window or tab. Don’t use a provider or template that forces me to click through read a single case study, scroll back up to your navigation, and click through to another case study.

Lead with the results. Show me what you created, what you contributed, and what the impact was before diving deep into the process.

Share the entire process. Don’t just share your problem, the solution, and the outcome. Particularly for student, intern, and personal projects, the process is generally an idealized double-diamond (or whatever process you pick). Take advantage of that to share the different ideas you explored, how and why you chose one solution to move forward with, and how you iterated based on your discoveries.

Seriously, show me the other things you considered and why you chose your particular path forward.

Edit your case studies. You are not writing the next great novel in your UX portfolio, and if I start to get bored, I will move on.

Be clear about your personal contributions.

Make sure your problem and your solutions align. I’ve seen multiple case studies where research identifies a unique and interesting problem, only to be completely ignored in the rest of the case study. Two examples spring to mind.

  1. An intern candidate shared a personal project on social media design. They flagged endless scrolling and a lack of meaningful engagement as a problems impacting the mental health of heavy social media users. They ended up designing an endlessly-scrolling photo sharing app with quick-reaction “swipes” as the primary engagement. Based on their own problem statement, they’re repeating the same problems.
  2. A designer created an app focusing on childhood obesity. The UI design was beautiful, and I’m sure gathered a ton of engagement on Dribbble. They did not however, consider how they would speak to children, leaning heavily on medical terminology and “adult” langauge. At no point did they show any awareness of mental health impacts or the risk of eating disorders or other physical harm that could be triggered by this app – or even show any awareness of this.

Related to the above: don’t be afraid to go deep on a single topic. I look for interesting, complicated problems like the above. I admire the ambition to tackle them even if the solutions aren’t perfect – particularly for personal projects – when considering intern and junior candidates. I’d rather see candidates go deep on these problems, instead of ignoring them because they’re hard to solve, or because they feel compelled go wide and communicate an entire product vision.

Focus on your strengths. If you’re not a strong visual designer, focus on your research, user flows, wireframes and other non-UI deliverables. While UX work isn’t only UI, it’s possible to derail an otherwise good UX case study with an absolutely awful visual design.

If you can’t design a good UI yourself, you can at least demonstrate good taste in your use of design systems and UI libraries, as well as a basic understanding of design principles. Learn about gestalt theory, use heuristic evaluations, and design for accessibility.

Make sure your content is correct. We notice when images don’t load, or when you forget to remove placeholder content, and we absolutely hold that lack of attention to detail against you. We are, generally, far more forgiving of minor typos or minor sentence awkwardness, particularly if English is your second language.

This doesn’t guarantee you a job anywhere. But maybe you’ll have better luck.

Keep learning.

Despite working with AI-powered systems for years, I’d never really gotten hands-on with building one. I’ve been working on this Coursera IBM Applied AI course, and finally got past the “advertising for IBM” part. Enjoy this useless chatbot.

A designer’s job is not empathy (and other unpopular opinions about UX design).

Inspired by agreements and disagreements with: Stop telling designers to stop being designers

1. Be a designer.

This is a fair statement: If you are a designer, be a designer. If you’re not a designer, stop telling designers to be something else. This is also an unfair oversimplification.

What is design? In short, it’s synthesis. Whether you’re producing design systems, wireframes, storyboards, or high-fidelity mockups, your value as a designer lies in the ability to take in a dozen disparate, conflicting, ambiguous inputs and create something cohesive, whether you’re design web-based tools or a plate. You can only be good at synthesis if you are able to have other perspectives – not just that of your user, but of services, technology and business as well. To that end, learn about how to understand your users – finding their needs, how they learn, and how to teach them; but also explore web frameworks, business process, and customer service processes (or whatever needs you have).

2. Embrace design.

Your goal is to shape whatever it is that your customer will use. Use your entire design toolset to generate artifacts that shape this process – and design every single one. Every text file. Every wireframe. Every research report. Every mockup. At the end of the day, you’re not just shaping your end user’s experience – you’re shaping the experience of the product manager, who is trying to digest your user journey to understand if we’re doing the right thing (or not).

3. Designers are not researchers or strategists.

Part of embracing design is caring about craft and the end product. I don’t care how many sticky notes you use on a daily basis – our job is to craft a product or experience. If you can’t create that thing, then you’re not a designer.

You might, however, be a researcher or strategist. And while this might sound as if I’m putting them down, I’m not. In fact, I feel that the constant push to make designer also responsible for research and strategy devalues both roles.

4. Empathy is (hopefully) not your job.

Empathy is not the unique domain of a designer. Literally everyone involved with building a user facing product should have empathy for the user, or they’re doing a bad job. If you genuinely feel that empathy is your sole domain, you might need to develop some.

5. On Job Titles

User Experience Designer is a terrible title because User Experience is a deliberately vague phrase that obfuscates what designers do, and allows everyone else to abdicate their responsibility for the “experience.”

There’s a cliché example that to create a successful restaurant, you don’t just design the menu, you design the experience. This is true, but most of the time, the person who designed the menu is not the person who created the menu, cooks the food, picks out the plates, or designs the lighting and acoustic environments. I prefer the term product designer because those are the things I’m creating – products – just like I work with product managers and product developers (and yes, that’s a real title, meant to differentiate from developers working on infrastructure).

An experience is a nebulous, vague thing with no specificity designed to generate importance via obfuscation. People don’t use an experience. They use software via a UI. They touch physical devices. They play games. They eat at a restaurant. Our job titles should represent the work that we produce, not a sticky-note driven cliché.

Updates in Brief

  1. I’m now a Senior UX designer for Amazon, working to help 3rd party sellers succeed on Amazon. My goal isn’t to make them feel like selling on Amazon is something they must do. I want it to be something that the love doing.
  2. I’ll add updates for my Indeed work when I can. I recently rewrote a the code that creates my Work pages to use section-level templates, instead of tedious copy-pasting of code.
  3. I recently added a project where I redesigned the inventory management UX of Destiny 2, my current go-to video game.

Never stop learning, but stop learning the same things.

It’s a truism, but that doesn’t make the advice to never stop learning any less meaningful. It is probably the number one bit of advice I offer to anyone in regards to career growth.

For better or worse, I see designers largely reading and passing around UX and design-focused tutorials – they’re reductive, simplistic, and repetitive. There was a post on Twitter or LinkedIn (now lost to my memory) describing this with far greater wit than I could hope to manage:

  • Junior designers read Medium articles about design
  • Senior designers write Medium articles about design
  • Design leaders read articles about everything else

(Or something like this – bonus points if you can point me to the original post).

I’m not here to bury anyone who reads or writes a UX design article. I find value in them as much as anyone when they provide a new perspective on a problem and don’t just rehash arguments or present false expertise. It is far more critical, in my opinion, that we embrace the fact that UX roles are multi-disciplinary by nature, and expand our knowledge base outside of our core disciplines.

Learn new tools. I don’t mean learning Figma if you’re in Sketch, or Sketch if you still design in Photoshop. I mean: learn to use a tool that completely breaks the metaphors you’re used to. If you’ve never done it, try to learn a 3D modeling program like Blender (or Cinema 4D, Maya, etc) – and discover how difficult it is to throw out your habits and preconceptions and learn an entirely new toolset.

Learn about your company’s business. What is its language? How does your company make money? How does it make decisions? How does it plan to survive another year or decade (or century)?

Learn about biology, sociology, psychology, and anthropology. How do people grow? How do our bodies change as we age and does this change how we interact with the world around us? How does this change, based on a person’s place in society?

Learn about education and pedagogy. How do people learn? There’s no single answer, as you hopefully know, but there are many theories about the best way to teach different subjects to different groups. On any design task, we can only reduce complexity so much before the task cannot be completed. At this point, how do we educate users on the complexity that remains?

Learn. But don’t worry so much about learning about UX.

Family Cooking, Part 2

Following up last night’s experiment, here is what I accomplished in one hour of wireframe. I focused on a single core flow – defining who is cooking the meal and how it could work. If you like this idea and can pull it off, you have my permission to steal this idea. Just do a good job and give me credit.

Wireframe: who is cooking?
Assuming the user has already found a recipe or built a meal and is ready to start cooking, we ask them to select who is cooking or add a new cook.
Wireframe: Add a new cook
A new user will need to upload/select an avatar, provide a voice sample (so the app can determine which spoken command refers to which set of instructions), and details about what this person can or cannot do.
Wireframe: Select the new cook
We return to the selection screen with our new cook ready to go.
Wireframe: Recipes
The app is now in ‘cooking’ mode. Each user gets their own timeline and their own single instruction. Terms that can can trigger additional interaction (such as whipping egg whites to “soft peaks”) are highlighted, and basic touch commands are available.
Wireframes: Speech controls
We want to support voice controls as much as possible – to save time, keep your device clean, and generally allow multiple users easier collaboration. This isn’t an exhaustive list, but here are a few theoretical commands for this step: Go forward or back a step, give me more information, re-read the current instructions, or stop until I can get help from someone else.

This is a bare shell of a small feature-set within the apps. But, I think it shows the potential of re-thinking how we consume recipes and cook with our families and I hope that something like this arrives in the future.

2 Hour UX: Family Cooking, Part 1

Timekeeping: My initial notes and sketch stayed within the one hour time limit, if you ignore the fact that my Wacom tablet and Photoshop had a disagreement that required troubleshooting and a reboot. I spent another 30 minutes or so typing this up.

The basics of a recipe app are pretty well defined at this point. Virtually every one contains a list of recipes, with the ability to search, sort, filter, and favorite. Each recipe contains an ingredients list and the steps needed to create the dish, and most include photos and secondary data such as tips, timing, and common substitutions. They’re literal digitizations of your parents’ or grandparents’ file of recipe cards. The better apps offer digital-native features, such as the ability to generate shopping lists and may have a video of someone following the recipe, but those are the exception.

Let’s think of some scenarios for a family cooking app that takes full advantage of a digital platform, specifically an iPad. Knowing how my family cooks, and others cook, there are a few common scenarios that occur:

First: the “rushed parent” scenario. I have little time, and only the ingredients on-hand to create a meal. This is largely solved by a large recipe database and good filters.

Second: I’m the primary cook, and I’m preparing a meal with multiple dishes. At the extreme end, this is someone preparing for a large family’s holiday meal. Multiple dishes need to be prepared in a sequence that allows me to make the best use of my time.

Third, I’m the primary cook, but I have a helper in the kitchen today who is less adept. I need help dividing the tasks appropriately so they can be a part of the meal without putting themselves (or the meal) at risk.

Persona Spectrums

Meal complexity

No, meals aren’t people, but let’s create some axes anyway:

  • Single dish vs multiple dishes
  • Single session vs a multi-day affair

Personal Comfort

How comfortable is the person in their ability to successfully cook this recipe?

  • I’ve never cooked before
  • I’ve never cooked this recipe before
  • I cook this recipe regularly


Is the cook capable of doing everything?

  • I have no limitations
  • I don’t know how to do something
  • I can’t do something…
    • …because my hands are full (or covered in something)
    • …because I have a physical limitation (such as someone with arthritis kneading dough by hand)
    • …because it’s not safe for me (a young child using a knife or stove)

Attention span

How much mental power can you devoting to cooking?

  • My full attention
  • I’ll have the occasional interruption
    • A knock at the door
    • A crying child
  • I will be constantly interrupted
    • I have ADHD, or am otherwise not ‘neurotypical’
    • There’s a lot going on around me


Because most recipe apps are little more than a collection of text files, they can’t handle these problems well. It’s assumed you’ll read and absorb the recipe ahead of time and make sure you’re planning things out in advance. Additionally, recipes themselves are often written to encourage you to do large amounts of prep work up front, regardless of if it’s a quick stir fry (where this is important) or a slow braise (less so).

They also lack common definitions. If you’re a new cook, you probably don’t know the difference between a simmer and a boil, and if it’s your first time baking bread, do you know how to knead dough?

It’s easy to get lost in the steps if you get distracted for any reason, largely due to the design to optimize for page count even if you’re not printing the recipe.

New requirements

As a part of the app, allow for the creation of users who may have different skill levels or specialties. Each recipe must be broken down into steps, with metadata for each step that denotes what is required for that step from prep, skill, and equipment perspectives. Allow for the combination of recipes into a meal.

Use those three pieces (distinct users, step metadata, meals) to create a step-by-step flow that focuses on appropriate division of labor and just-in-time prep. Thing about it as Lean Cooking or Agile Pastry.

Within the presentation layer, ensure the timelines are built so that no user can get too far ahead, and that the display is limited to only what is necessary for that step. Imagine a “presentation mode” for a recipe where each step is one slide.

Assume that the user cannot touch the device with their hands. Any action – whether it’s to go to the next step, get info, or start a time, will be voice-accessible in this mode, by any user.

Family cooking app: partial flow
I’m illustrating a partial user flow. The user can search for recipes and add them to a meal, or select an existing meal. After confirming who is cooking, tasks are divided into two parallel streams that allow each user to proceed independently until they reach a break point.

2 hour product: Introduction

I’m trying a new strategy for generating and exploring experiences, based on the idea of speed painting – a part of the warm up and exploration process of artists where they strictly time-box themselves and try to generate a larger quantity of work at lower fidelity, and not worry about specific executions later.

If we’re being honest, it’s glorified sketching.

If we’re still being honest, this is also pretty similar to the idea of a whiteboard challenge that designers are given in interviews. That’s ok, though.

My goal is to regularly explore product ideas that bounce around in my head, and experiment with different techniques, such as Persona Spectrums that I find interesting. I’ll take 1 hour to work through definition and discovery, and another hour to put that into wireframes. If I like the idea, I may continue my explorations into actual mockups or prototypes. My first idea? A family cooking app for the iPad. I’ll spend 1 hour on each of the next two days, and see where I get.

The interview process

The reality is no single interview format is perfect. Someone has a bad day. They’re too easily faked. They are problematic for people who aren’t neurotypical. They test the wrong things. They’re not respectful of time. Passion isn’t the same as skill.

Look. Interviews aren’t fun for anyone. The whole process from initial contact to final decision can easily take months, depending on timing, and if you have a bad day at the end? You’re toast. Make the wrong decision as the hiring manager? You’ve wasted your time, and now have to undo the damage.

The best you can do is have a clear process and clear expectations. Understanding what is important to your team and your organization is critical. This tells you what you are testing for, which tells you how to prepare your interviewers and set up the day fairly. There’s nothing worse as a candidate than spending your entire day taking questions from a random crew who clearly hasn’t talked about what is actually important.

What I was hiring for a Senior UX Designer role at eBay, I had a list of things I wanted:

  1. A true senior designer. This person needed to have the experience to work independently, present their work, and make the right decisions without constant escalation.
  2. A designer focused on connecting products and flows, and less about building a flashy UI. This was related to business tools and payment processing. We wanted someone who was into the complexity of interconnected systems, not someone who would complain that they didn’t have anything Dribbble-worthy.
  3. A designer who was willing to take and give a critique of work. This designer would be facing commentary from multiple teams who are likely to disagree with each other, possibly putting the designer in the position where they would be forced to get to the root problem and build consensus, or at least make it obvious where the true points of contention are. It was also important for us, as a team, to critique each other’s work directly and honestly, without causing or taking offense.
  4. A designer with good communication skills. They’ll be responsible for presenting and selling their work, as well as working with product partners across coasts and continents.

When evaluating candidates, we knew we were going to be turning down ‘great’ designers who didn’t otherwise match what we wanted. It might be unfair, but (for example) a candidate with severe anxiety or who refused confrontation would not work well in this particular role.

Designing the process

Usually, I’m a firm believe at starting with the end: know where you want to end up and design your flow to get you there. This is no different. In short, you’re going to have a candidate who you’re pretty sure you could hire come in and share themselves with the group. Once they pass the “recruiter sanity check” – they’ve verified the candidate is who they say they are, and they have at least some interest in the position, it’s time for a phone call or two.

As the initial non-recruiter contact, it’s your job to make a solid connection and impression. This is (probably) YOUR team, and (probably) YOUR hire. Give the details the recruiter didn’t. Make sure there are no illusions. And above all, make sure the candidate passes the sniff test. If you get a feeling that they’re glossing over something, push them on it. If there’s a gap, or something strange, dig into it. This doesn’t mean they’re a bad designer or a bad person, but that everyone has a blindspot. You’re trying to answer two questions with a moderate degree of confidence: Would I want to work with this person? Could they do the job? You’re screening for the needs that you’ve hopefully listed out, using an abbreviated form of your interview loop – end to end walkthrough of a project; they articulate a design process and perspective, the ability to participate in critique, and a general culture fit. 

While I disagree with some of his examples of good and bad questions (and answers), generally, speaking I find Richard Carillo’s perspective agreeable: we need to give questions that provide room for thought and exploration, while still encouraging a candidate to provide an answer – even if it’s wrong. Take this question about reducing Rock, Paper, Scissors to two options: No special knowledge is required. You don’t have to create something from whole cloth. The candidate has a specific goal but will have to talk through how they get there. 


At this stage, I have never asked a user to spend more than an hour preparing anything. When reviewing work, I will happily review a project on a website, or a super-basic presentation as long as I can understand how you work, where you had an impact on the process, and how the final product succeeded (or failed) and how you might evolve it. Chances are, a designer preparing for interviews already has this ready, or can get it ready shortly. I repeat: I stress that I am not grading someone’s presentation design skills. I just want to walk through one project in detail, and ask questions. Beyond that, I’m going to ask pointed questions – talk through designing a new feature, with critique and iteration as we go. 

I’ve also seen suggestions to ask candidates to “teach something they’re passionate about.” It’s an interesting request, though I struggle with it on principle. First, we’re interviewing a senior designer, not a manager or principal/lead designer. We’re testing the ability to do, not the ability to teach. Second, it’s incredibly hard to define success here even if they are a good teacher. What if they’re passionate about dance? Or astrophysics? I’m clumsy, and math isn’t my strong suit.

Your candidate passes the round of phone screens. You think they’re a promising candidate. But maybe they can’t show a lot of recent work due to NDAs. Maybe they don’t have a huge body of work. Maybe you’ve just been burned in the past. So you’re thinking, it’s time for a design exercise.

Design Exercises

Design exercises are a touchy subject. I did a few earlier in my career. I interviewed with design agencies when I didn’t have much of a portfolio, or at least had a rather scattered one, and I understand why. I spent days on them. One was given pre-interview and was the topic of much of our critique. There was no direction around expectations for deliverables or format – just “do this in 2-3 days”). If this sounds like a setup for failure, it was. To this day, I’m still not sure why they brought me in for an interview other than to spend hours tearing my work apart. I’ll leave them nameless because it sounds like they took the feedback to heart. Another was given after an interview. It was legitimately the kindest, best interview I’ve ever had, and the agency heads said they liked some of my work, but that it was inconsistent. They gave me an old brief, their final set of wireframes, and we chatted for a few minutes. A few days later, I sent my work to them… and they broke my heart. This was Huge, Inc. (in their independent days). To this day, I have nothing bad to say about this. I had a third, which gave me 24 hours to complete a full presentation, from scratch) – even though I had a full-time job at the time. 

I recently completed an exercise before being hired at Indeed, and I have to say that I feel it was a pretty good example. It was made clear that this work as NOT meant to be used in their daily work. I was given a clear brief, and clear expectations as far as deliverables and scope. I was told how much time was expected of me, and asked when I could start and complete it. I was then allowed to present and discuss the work remotely – all of which minimized the actual disruption to my normal life. Also: I was paid (well) for my time. Do you need to do design exercises like this? No. Good candidates have been hired without them. But, if this is a part of your process, do it like this.


Then, comes the big show: the onsite interview panel. Assuming your candidate has gotten this far, you should be pretty confident that they’re a good match because you’re about to wreck your team’s day.

I feel like UX and product design interviews have an almost standard flow and while I think that does lead to a bit of a cookie-cutter feel, it’s not a bad process.  They’ll introduce themselves, and their background, and walk through 2-3 projects. The panel (who are all of your breakout session interviewers, as well as other interested parties) is going to watch politely and ask clarifying questions or ask for more information, but avoids outright critique. This is setup for the rest of the day and ensures everyone has the same background, besides testing the candidate’s ability to hold it together and tell a coherent story in front of a dozen people.

From there, you’ll break out into as many sessions as you have time and people for. Having been on both sides of the process, I feel that paired breakout sessions are the best. They allow you to expose more of the team without overloading the candidate, help eliminate dead spots in interviews and helps ensure that no single person can break the process. Also, the day’s schedule should, in general, be shared ahead of time. The panelists should all know exactly what they’re doing. The candidate should have a general idea of what to expect. Other than generally asking the panelists responsible for the candidate deep-dive to followup the presentation immediately, there’s no set order to the operation, and time should be left to allow the candidate to breathe – try ending sessions 5 or 10 minutes early, instead of on the hour (or half-hour).

Deep dive

Immediately following the presentation, go deep on the presentation. Ask critique the work, critique the decision-making, and make sure the candidate’s contributions are clear. Leave no stone unturned.

Whiteboard design sessions

Give the designer a brief, and ask them to solve a problem. This is almost cliche, and there are dozens of guides that teach the test. Yet, I can’t think of a better way to understand the ability of a designer to solve a problem. Whether you’re designing an app for a theme park, an autonomous vehicle product, or a video game scoring system, you want to understand if a candidate can break down the task in a way that works for your team, and produce a concept for a viable product or system at the end and with points for further iteration and AB . The guidance I can give here is that you must – MUST – push for both process and an actual solution. Too many UX designers can’t actually design experiences – they’re lacking the ability to synthesis knowledge, assumptions, and hypotheses into testable flows.

I don’t know if whiteboard sessions must always relate to your core product. What I do know is that they should stretch the designer’s apparent skill set and get them outside of their comfort zone – even if you have to do two whiteboard sessions.


I am a firm believer in the power of group critique among peers. With the right framework, this transforms designers and their work, improves decision making, and eliminates the need for putting designers in front of a firing squad of directors. I will always fight for this in any flow I design. Given an experience that’s fairly common and no personal stake in the matter, ask the candidate to provide critique. Try to understand the user and business needs behind a feature as designed, and discuss where it meets or fails those needs. We’re not looking to endlessly praise the subtle interactions of Google Maps, or destroy the endless consumption of Netflix. We’re trying to take on the perspectives of others, and provide honest, kind, and useful critique. If you’re short on time? Combine this with a whiteboard session,

Culture fit

I’ve already had my say here. Team fit is valuable, but you don’t want to create a monoculture. Test for cultural fit, but don’t be a jerk. If you’re short on time, you can do this separately.


Allow for 5-10 minutes between sessions. And if you’ve got a full day scheduled, plan to take the candidate for lunch (or let them explore solo depending on your environment).


Don’t just let the candidate walk. Ask how it went. Not everything will go perfectly, and some people will just have an off day and their brain will fall out for a few moments. A candidate who gets 95% of the way there and shows self-awareness about where they failed or could have improved might actually be the right candidate.

Be honest with the candidate about your timelines. If you’re in the final round of candidates and want to finish them all before deciding, say so. But be fast. I lost multiple candidates at eBay because our process took so long, and we can’t ask everyone to wait forever. In the meantime, get feedback within 24 hours. It doesn’t need to be immediate – allow time for parsing and reflection, but don’t wait so long the details fade. Look for areas of agreement and disagreement as much as the individual hire/no-hire ratings. And last, follow whatever HR-approved decision-making process you’ve got in place.

Admin note:

A recent WordPress update appears to have duplicated sections of some blog entries and mangled more than a few others. If you see weirdness, I discovered this while writing at 11PM on a Monday evening. I will fix it when I am less likely to make things worse.