Hi, a quick note: I love to hire recent grads, and was on the advisory board of a bootcamp a while back. So, this isn’t a knock on design programs, quite the opposite! I want to ensure you’re prepared to join the corporate world.
Okay, let’s talk about some key differences between the expectations of recent grads, and the reality of the hiring process. Every role and company is different, but the experiences aren’t that far off.
Yes, the process is important, but you’ll rarely follow the “full” design flow
And that’s okay. But that also indicates that your beautifully designed flow diagram isn’t a useful part of your portfolio. And it shouldn’t be the first thing a hiring manager encounters.
What that manager will want to determine is whether you understand howand when to apply specific components of the design process to your project. Let’s illustrate this with a realistic situation where timelines and resource constraints are working against you…
Sophia sits down at her desk after an afternoon break on Tuesday. It’s been a chill day, and she’s settled into her new role as an Associate Designer over the last several weeks.
ping Oh, hi Slack…
👩🏾💼 Zoë: Hey, did anyone tell you about the new alert configuration project? 👩🏽💻 Sophia: nooo..? 👩🏾💼 Zoë: So, yeah we need the config UI design by the end of week. Dev starts on it on Tuesday and we need sign-off before then, which I can get Monday. Here’s a link to Gabe’s oh so detailed brief 🙄 👩🏾💼 Zoë: I know you’re the only designer on this, but we can do this right? Otherwise the dev is just going to figure it out 👩🏽💻 Sophia: Yeah, I can definitely do it
Sophia has three days, not to mention some other commitments. She wants to show that she’s a part of the team. But there isn’t enough time to write solid research questions, much less run the interviews, or you know, all of the other steps in the process she learned.
She doesn’t want to fail right as she’s establishing herself, but where to start?
This sounds like a dire situation, but it isn’t. In fact, it’s all too common, even in teams that manage the Product creation process well. Important customers make critical requests, communication breaks down, the PM simply didn’t think about a key use case. It happens.
Your process is a set of component parts that you can use individually or in smaller flows
Sophia may not have time for user interviews, but she might be able to get a clear direction on what real users want as a foundation with a quick survey. She may be able to rely on some previous user research, or feedback from an implementation team to learn how end-users would likely configure the product. There may be established configuration screens in similar products within the company she can reuse and there are likely design patterns that she’s expected to use.
How to apply this
Where you can, highlight work that forced you to be agile and skip steps. Explain which parts of the process you used as well as which you didn’t, making sure to explain why you chose one over the other.
There’s always a tradeoff between cost, quality, and time
Great teams want to get everything right, but they need to be flexible to respond to the needs of the business. Communicating your awareness of this balance and willingness to adapt to the situation with clear examples is powerful.
Portfolio examples that aren’t rooted in reality
Most design projects, especially from bootcamps, fall into one of two categories: either they are purely theoretical (redesign X app or feature), or they pair you with a local business that needs design help.
Let’s break this down.
Joining a team working on a project in a design program isn’t the same as being in the actual team and company building a product to hit revenue expectations. That’s alright, but we should be clear on the limitations: specifically, you don’t know:
- You don’t know what the business goals are. They are rarely aimed at making a good user experience as the overarching goal, but rather acknowledge that a good experience helps achieve their goals.
- So, you don’t know the importance of the features and functionality in a particular flow.
- You don’t know how different flows interact with each other.
- You don’t know all of the different personas involved, and you definitely don’t have actual data.
- You don’t have to deal with technical constraints.
- Nor do you have to deal with the wide array of supported devices and contexts.
- And you definitely haven’t had to navigate the weird political waters when you as a designer Disagree with the Product Manager while Engineering is telling you that your beautiful new design will blow up scope.
So yeah, it’s fun to redesign Spotify, but as a portfolio piece, it’s more likely to highlight people who redesign it poorly, not those who do it well.
Be that as it may, if it’s what you have, we can work with it!
How to show this work
To start, clearly list your assumptions alongside the challenge brief. If you didn’t receive some business constraints, make some up at the outset of the project. For example:
For this project, it was clear that this feature is geared to new Spotify customers, but it couldn’t impact the experience of established Spotify customers, so:
• I couldn’t mess with move key elements like the Play and Skip buttons
• I couldn’t add a step between startup and hitting “Play”
• I couldn’t de-prioritize the “Shortcuts” nor the “Recently Played” lists
Also, be sure that the goals for this work are very clearly outlined. Are you trying to increase conversions? Great, state that and provide your hypothesis as to why you feel this work would be successful.
Pairing with a small business
The good news is that some of the issues above won’t apply as the request has some roots in reality. You have a real customer with actual business needs (yay!) But, odds are good that at least one of these issues apply:
- Your experience was time-boxed. So you only worked on one small part of a larger system or a very small system to start. Odds are that you didn’t need to tie into brand requirements or an established design system.
- You don’t have to live with the ramifications of your work. You designed it, you’re done! But someone else down the line will have to handle any decisions you made that maybe weren’t amazing in the grand scheme of things. So will the developers. And the business…
- You were told the challenges of the app, likely without any time or ability to research that yourself, much less push back with what you’ve learned.
- You likely didn’t have access to real users or prospects. If you’re lucky you found people who roughly matched your persona(s).
- You followed “The Process” in an accelerated timeframe, but without all of the benefits of the bullets above, so it likely felt like you were doing it right, but you have no way of knowing what you’ve missed. (It’s not your fault, but it is reality.)
Again, these projects may provide better portfolio pieces, but how you show them is key.
How to show this work
First, explain the business constraints you gathered at the start of the project, in addition to any discoveries along the way. That second group can be quite interesting as they often come when you’re already underway. Sharing a story of the surprise requirement halfway through a project can be powerful.
If you were given access to actual customers and were able to speak with them, then highlight it! It will go much further than talking to strangers in coffee shops or your friends and family who might use the app, maybe, one day.
Group projects are portfolio problems
It is not uncommon to see portfolios from more than one person who worked on the same group project.
The composition of these teams is often unrealistic, and role definition quite muddy
Depending on the program, a team of four may be made up entirely of Designers or split between Designers and Developers. But, as soon as two people from the same discipline are in the group, it’s hard to discern what role you played and what the other person(s) did.
When someone states that they were responsible for User Research, Competitive Research, User Flows, Initial Sketching and Ideation, Low-Fidelity Wireframing, High-Fidelity UI Design, and Prototyping, I immediately wonder what the other Designers were doing.
Seriously, this is not uncommon.
And on that note, I’ve seen your teammate’s portfolio too…
The tough reality is that you are all applying to a ton of jobs. These are often the same jobs because there are only so many entry-level roles open (which sucks, I wish there were more opportunities for y’all).
On multiple occasions, I’ve seen the portfolios of and even interviewed people who worked on the same group project. Let’s just say that there can be differing views on the project, their respective roles, and individual impact. 😉
Be straightforward. Help the reviewer understand the role you played and the role others played. How did you interact? When confronted with a challenge, what did the team do, and what was your part in it?
Point me to specific artifacts that you created and tell me how the impacted, interacted with and were influenced by the work of others.
Long-form case studies aren’t read
With hundreds of submissions for an entry-level role, there just isn’t time. And honestly, managers are not inclined to read yet another case study that walks through the same flow as every other one out there.
Crafting effective portfolios
Design your case studies to catch the eye as the hiring manager skims your work.
Callouts drive your point home
So do selected photos and graphics that show your work. Odds are you can skip the all-too-common photo of you next to a wall go sticky notes. A shot of a user flow quickly sketched is more likely to catch the viewer’s attention.
In line with this, think about the rhythm of the page. When the reviewer’s eye is jumping from image to headline to image, what is the story you want to tell? What are the one or two graphics or points that you want to highlight?
Rework the page until it illustrates the story you want it to tell.
I know this is a lot to take in, but the effort will help you land your early roles.
You’ve got this!