How to Build Your Product Design Portfolio

If you’d like to build a product design portfolio with some side projects of your own, so you can start applying for jobs as a UX or Product Designer in tech startups, I’d like to share a process with you that will also help you become a talented asset on any startup team.

This process will get you to a strong place pretty quickly even if you don’t have a ton of UX design experience. It will also teach you techniques valuable to most early-stage startups — techniques like rapid prototyping, user testing, and iterating quickly based on user reactions.

“For most early-stage startups today, a process built for speed and iteration based on real user interactions is extremely valuable.”

I’ve trained early-stage and corporate teams in this process as a trainer for the Prototype Thinking Academy, and I’ve used it with clients in my consulting business with The Determined.

Now I’m piloting this process for UX design students in a class with Whitespace, called Ace the Design Challenge: Take an Idea to Prototype in 6 Weeks.

As soon as our pilot students help us test out the material through our pilot program, we will likely offer it again to a wider audience so you can walk through it with mentorship, feedback, and a community of peers to cheer you along.

In the meantime, take a stab at it on your own, and let me know how it goes!

12 Steps to a Product Design Portfolio Project

1. Pick a problem to solve or a product to create that solves a problem you observe people around you having.
2. Look at products in an industry related to the product you want to create. What do they do well? What are their weaknesses? Who is their target market?
3. Articulate who you’re solving this problem for, specifically. Do an empathy mapping exercise to get specific. Fill in your empathy map with real observations from the real world or through interviewing real people in your target market.
4. Create a quick, cocktail-napkin quality storyboard illustrating the key frames of a scene in which your target user would use your product. Include concerns, hopes, or real quotes from the people you’ve observed or interviewed to make the scenario realistic and call out important points.
5. Select the most important frames of your storyboard and sketch the screens as low-fidelity mockups for each step in the scenario. Use 3x5 index cards for a mobile app, or 8.5x11 pieces of paper for a desktop or tablet app. Draw one screen per card or sheet of paper. Draw these quickly, as you’re likely to discard them as you make changes.
6. Find some test participants and ask them to imagine your sketches are beautifully designed screens. Ask them to roleplay the scenario from your storyboard, thinking out loud and reacting as honestly as they can, as if they were really in that situation.
7. Present one screen at a time, asking them to tap, type, and interact with your paper as if they were using a device.
8. If they’re confused, change something on your prototype in the moment. Create a new label with a sticky note and stick it over a confusing label, or draw a new “screen” if the user expects to see something different than what you’ve drawn. Collect actual reactions by presenting new screens rather than having the user describe hypothetical expectations.
9. Once users are able to get through your prototypes without getting confused, and especially if they react positively, like “OMG this would be amazing!” THEN you should start committing your sketches to a digital mockup using Sketch or Photoshop. Add colors and UI elements to start bringing your product to life.
10. Create a clickable prototype with Marvel or InVision or your favorite prototyping tool, and test again with at least 3 different people in your product’s ideal target market. Make any needed changes to your prototype, and document any behind-the-scenes design decisions in high-level flow diagrams or wireframes.
11. Collect artifacts from this entire process for your portfolio case study:
    • Screenshots of the competitor products
    • Snapshots of your empathy mapping and user research
    • Pictures of your storyboards and sketches, and images of your test participants interacting with your paper prototypes
    • Screenshots of your design process, any mood boards or alternate versions you created before settling on a final option
    • Notes from user research that informed your final decisions
    • Screenshots of your supporting diagrams
12. Publish the story of your process with minimal words, using mostly the visuals to highlight what you did and how you made the decisions you made.

Flip your design process upside down

I sometimes think of this process as an “upside down” product design process. It starts out the traditional way, with persona development and competitive analysis.

But instead of going right into wireframes and mockups like a more traditional process would, I go straight into testing my rough cocktail-napkin sketches on real people.

A couple years ago, Jake Knapp from Google Ventures wrote “Those paper sketches should never leave your war room,” arguing that you’ll never learn anything useful by using paper prototypes in user research. Despite the certainty of his tone in the article, unfortunately, he’s dead wrong about the usefulness of testing your paper prototypes.

If you set up the scenario well, ask the right questions, and look for your test participants’ authentic reactions, you can save yourself a massive amount of time and uncover major issues early, before you’ve committed sweat and tears to coding or mocking them up.

By asking test participants to roleplay a scenario and react honestly, I can gauge their reactions to my decisions about functionality, flow (i.e. the order of operations), and even content.

By keeping my prototypes low-fidelity, I can make changes to them in the moment, continuing to gather reactions, not feedback, and make product decisions from a more authentic, user-centered perspective.

And by waiting until the flow and content is validated before I go into high-fidelity design, I save myself a ton of time-consuming work. There are so many times that I’ve caught a glaring issue in the flow early through this process that I wouldn’t have otherwise noticed, and once I’ve committed my designs to high-fidelity mockups, I’m loathe to make big structural changes.

What about wireframes?

Since most modern dev teams no longer need or want detailed spec documents, preferring a clickable prototype any day, I save my documentation for the end, documenting only the screens I’ve chosen not to mock up in my clickable prototype, or creating diagrams that show behind-the-scenes design decisions that are harder to show in prototype form.

Today’s early-stage startups need quick iteration based on real user feedback

There are times when a more traditional process still works, like in a larger organization that can afford to move more slowly, or where teams aren’t physically co-located and need more careful documentation, for example, but for most early-stage startups today, a process built for speed and iteration based on real user interactions is extremely valuable.

Try it and see!

Try it out for your side projects to build your portfolio, or teach it to your teams to increase your rate of innovation. It’s fun, collaborative, and smart.

Sarah Harrison is a design strategist with The Determined and an instructor with Whitespace. She also teaches yoga & meditation.

She writes a weekly email newsletter with insights on career, creativity, and personal growth. Sign up at sarahharrison.co.