5 things to consider on your UX portfolio
By: Goncalo Andrade
Tags: Best Practices, Portfolio, Mentorship, Design, Advice

In my time as a mentor I’ve spoken to more than a few Junior UX Designers, or people looking to move into UX. We talk about their plans and experiences, I share some insights from my time on the job and give them some advice.

However, there are some questions that keep coming up, and I find myself giving very similar advice quite often. One of those recurring themes is a portfolio, what it should include, what it should look like and how to start putting one together. So here’s some advice I give when the questions come.

Use cases are stories, not just impressive UIs

Some portfolios look very nice, and display amazing high quality mockups of the apps or websites that were the result of a project. They do skip over a lot of steps though.

When I’m looking to hire someone, I want to understand their process and how they think. I need to make sure they have the skillset I need in my team before bringing them into an interview.

Show me what you did and why

I need to understand (briefly) what the problem was and why you decided to tackle it the way you did. These problems should always be from a user’s point of view. For instance, if you say the app looks ugly, that’s not a very good reason. But if you say you hypothesised the users were confused by the interface (which was ugly) and dropped off without spending money, then that’s a real problem.

Link your steps together

Show why you did each step, don’t just tick them off a to-do list

Each project is a unique beast, and will require different tools to address.

If I can’t understand why you did a survey instead of user interviews, I’ll assume you did it because it’s just how it’s done, or you were told to.

When in a job, working on real design problems, you’ll need to understand the issues and what would be the best way to solve them. Following the earlier example, you could test your hypothesis by designing a better experience and putting it in front of users in the lab.

Display your setbacks

No project is perfect, and processes like the Double Diamond are rarely as neat in real life as they appear on paper. Hypothesis are wrong, assumptions fail, designs get butchered to meet deadlines.

This is part of life as a designer, and people looking at your portfolio know this. They don’t expect everything you design to be right straight away when you’re their colleague.

So why not be a bit more honest? Talk about when you user tested something that didn’t go so well, and what you did about it.

It’s much more important to know you can deal with setbacks and learn from them.

If I see a use case in your portfolio where you took something to the lab, it disproved your hypothesis, but you learned from it, drew smart conclusions, and the design was made better as a result; that is much more impressive. It tells me you can think on your feet, and I can trust you to drive a project.

Make it public

Ok, this is the one that will have the most people disagreeing with me. I believe your portfolio should be made public. It should be available to anyone, any time. Recruiters will be prowling LinkedIn and look at loads of candidates a day, so if one is a little more difficult to learn about, they are likely to move on to the next whose work they can see more easily.

You should do a little SEO, such as make sure it’s all text accessible to Google bots and screen readers.

There is one issue with this approach however, which is NDAs. Some companies do not take kindly to you displaying the work you did for then so publicly. Always make sure you ask the company for whom you worked if you can post the use case. Send it over to them if you can. If they say no, ask if it’s ok if you white label it, that is, take any mention of the company name, logo, branding, etc out of any text or images. Most companies will be ok with this approach, and you can tell your story anyway, which is what matters.

Worst case, if you can’t use a project, just don’t. You don’t need a lot of them, just good ones.

Make sure it’s accessible to anyone

You should always consider your audience. Odds are not everyone reading your use cases is a designer themselves. You’re likely to get recruiters, IT managers, PMs, and many others. These people might not understand industry jargon, so it’s best to simplify your language if you can.

For instance, if you say that you conducted a Design workshop to create hypothesis which were then taken into user research, and the aggregated results informed your next iteration, you probably lost some of your audience along the way. You can instead say you worked with your team in workshops to create a new design, which you then tested with the users and used their feedback to improve the next version.

Don’t worry too much about it

I know how tempting it can be to want to make your portfolio really stand out, to design and even code it yourself.

The problem is, we are each our own worst critics. It will never be done, there’ll always be a little more to fiddle with, it’s not quite perfect yet etc…

Use a medium which restrains you and forces you to focus on the context rather than the stuff around it

Write your use cases in Notion 1st, for example. You can even make it into a full website using Fruition. Once you have something out there, then you can spend as long as you like working on your perfect website. In the meantime, you can apply for jobs and people can find you.

That’s it

This is the advice I give out the most to my mentees. I hope you find this helpful. That being said, I’m only 1 person, so you should always welcome more tips from others, not just designers but recruiters, PMs, and others too.

Bear in mind this is my take on it, and what is be looking for. Other designers will have different opinions, and this won’t be the best approach for every market. I live and work in London, UK, and this is the market I know. If you have any questions you can always ask me