Authors:
Jon Kolko
I've recently spent a great deal of time speaking with design leaders at large companies who are responsible for hiring junior designers. I've heard over and over again that the candidates are largely unprepared and that the hiring process has become an arduous drudge through hundreds or thousands of portfolios that look the same. They contain the same content and, most importantly, don't provide evidence that the designers are able to do the work. I think aspiring designers new to the profession sense this too, as they often ask me and other educators for advice and a "good template" they can use to break through the sameness. There is no template I can offer, and the desire to use one may be part of the problem. But I can offer some advice, and I'll share it in this column.
This comes with several caveats. First, if you ask 10 designers for advice, you'll get 10 different recommendations. There are always exceptions to experiences, and every company is unique. Additionally, this advice is probably most immediately relevant to designers focused on getting their first user experience job, as compared to those focusing on visual design, service design, or user research, but I think the overarching principle still applies. Finally, this content probably won't age well, because it's inevitable that AI will replace the jobs that these junior designers are vying for. Right now, however, I feel confident that this will help steer designers closer to the actual wants and needs of hiring managers.
The broad, sweeping piece of advice I offer is to show that you can do the job, which is, primarily, designing software. It's common for user experience portfolios to show a set of things that aren't about designing software. A typical portfolio case study looks like this:
- I identified there was a really big problem in the world. Here are some really big numbers, showing that it's a Really Big Problem!
- I confirmed with two or three people that it is a Really Big Problem. Here's a photograph of me talking with those people.
- I created a persona, showing that a user drives a certain car or likes a certain type of music.
- I thought of crazy, blue-sky, off-the-wall ideas to solve the Really Big Problem and wrote them on small Post-it notes. It turns out that a new app will solve the problem.
- Here is a picture of a whiteboard, where I drew a small flow diagram, with four or five steps, that shows how this app would work.
- I drew two wireframes in a Moleskine in pencil; then, I made them again in Figma, but I used some colors.
- I made a small animation of a drop-down opening.
- Finally, I made a tear sheet of 10 shades of the colors I used, 10 different type sizes, and an example of what a button looks like.
If this is the way you structured your case study, at best, it shows that you know some things designers sort of do and that you can sort of do a little bit of each. But a hiring manager rarely needs someone who can do only a little of something. They are almost always hiring to fill a specific need, and in user experience or product design they need someone to design a small, simple software feature from end to end. Most of this task will consist of exploring how a user will encounter various screens in a flow and then working with other disciplines to review and refine that flow based on constraints and opinions from product owners, marketing, engineering, and other designers.
The hiring process has become an arduous drudge through hundreds or thousands of portfolios that look the same.
You won't need to identify a really big problem to solve, because a really small problem will be given to you (albeit in an incomplete and overly assumptive form.) You won't need to confirm that it's a real problem, because someone in the business already committed to addressing it. You will, however, need to track down the details that will help you better frame the problem by talking with a product manager and with other people in the company. You won't need to make a persona, because someone in marketing probably already made one. And you won't brainstorm lots of crazy ideas. Instead, you'll work through many different iterations of appropriate, predictable, simple, and detailed user interfaces—first in diagrams and then at a mid or high level of screen fidelity. Hand-drawn wireframes may be useful to you, but you'll show your work to others with real data and in high fidelity, and you'll spend a lot of time tracking down the data you want to use to find out if it's even available. You won't define anything related to visual design, because there's likely already a design system in place for you to use, but you'll make small click-throughs and prototypes so your team can see the flow in a more realistic context.
Here's an example design problem that you might be tasked with in a job at a typical large enterprise: Design the ability for a user to manage their marketing preferences. By that point, the marketing team has probably worked with the product team to draft a set of requirements, tasks, stories, or jobs that need be done to add a little more detail about the problem you are asked to solve.
You'll then speak with a marketing manager to better understand the nuances of their efforts, and you'll talk with some people in engineering to understand how system notifications work. You'll research the ways in which 10 other companies handle this type of preference management, and then you'll draw some screens—in Figma, using an existing component library—of how the flow might work and where it will go in the context of the existing user profile. You will probably sketch the flow in lots of different ways, focusing on the main permissions setting screen. How can you best organize the information? What are some conveniences you can provide to the user, such as select all? Can the data be autosaved? Can you add text that explains the various notifications to users? Can you show examples of the various marketing items, so users can understand what a newsletter or promotion might look like?
After making 10 or 15 materially different solutions for the problem, you'll get deeper into the details about data availability, marketing's goals and how they relate to usability best practices, and on-page vs. in-flow interactions. You'll sketch these in Figma, socialize them with other disciplines, and eventually narrow them down to one or two solutions for testing. If there's time, you may gather some feedback, perhaps in an automated A/B testing framework, or via a non-facilitated testing platform, and then iterate several more times, before working with engineering to bring the design to life in a test environment.
This is what should be in your portfolio, although not in the context of a way to manage marketing preferences. By showing a hiring manager that you work in the way a company you're applying to works, make the things they make, and solve problems thoughtfully and with a curiosity and passion, you are showing that you will be a good hire.
You may not have this type of detailed work in your portfolio, because it wasn't assigned to you in school or because you were busy learning (which is, of course, the point of school). That's fine. You don't have to show work in your portfolio that came out of a class. Assign yourself this problem, or find a nonprofit that needs any help they can get and do the work for them. It's not cheating to redo schoolwork or to assign new projects for yourself.
It's also likely that you don't have this type of work in your portfolio because you don't want to do this type of work at all. When I have this conversation with junior designers, they're often confused and somewhat disappointed. They've learned a process in school that was rooted in user-centeredness, that provided them with a rich tool kit of methods, that prompted them to think strategically, that embraced blue-sky ideas, and that always floated slightly in the world of idealism. When confronted with the idea that, for a new designer, user-experience design is mostly screen design, they feel their professors led them astray. They often second-guess if this is even a field they want to be in.
There are all sorts of reasons why the job does not match their expectations. Maybe their professors taught them the wrong things, perhaps their boot camp program was too short, or they saw influencer videos of designers on TikTok or at Nike working on awesome, sexy problems in creative environments. But most likely, what was missed in the magic of the educational experience was the realization that design is a job. Jobs are hard. They aren't always (or, for some people, ever) fun. A lot of software creation is now about production and assembly, instead of blue-sky thinking. And, by nature of their lack of experience, junior designers aren't going to set strategy; they're going to do the grunt work that, while important, is work no one else really wants to do.
I shared this article with 10 hiring managers to see if I was being overly pessimistic. I was told that it's not pessimistic: It's realistic, and it's not necessarily bad. Design, they noted, is still one of just a few professions where we get paid to draw and to think about complex problems, and where we have an opportunity to have a fairly direct impact on improving the world around us. But user experience design is largely becoming a process of assembly, and like other professions that have turned into production, the magic that was once in the job (either in reality or only in nostalgia) is disappearing.
If you are a student with hopes of entering an expressive, imaginative, and always exciting job, I hope you are able to temper your expectations. If you can still find passion and satisfaction in designing software at scale and for production, you can build a portfolio that represents the skills employers now need. And if this isn't the type of work you want to do, that's fine too. User-centered design lives in many contexts other than in digital software design. This may be a good time to start looking at design in government, in schools, in nonprofits and nongovernmental organizations, and in other parts of culture that need and respect creative thinking the most.
Author
Jon Kolko is a partner at Narrative and the founder of Modernist Studio, acquired in 2021, and the Austin Center for Design. He has written a number of books, including Well-Designed: How to Use Empathy to Create Products People Love (Harvard Business Review Press). [email protected]
Copyright 2025 held by owner/author
The Digital Library is published by the Association for Computing Machinery. Copyright © 2025 ACM, Inc.
Post Comment
No Comments Found