Presenting stories

There's a delicate balance between crafting what recruiters expect to find in a case study and you showing what makes you unique. Same as when you're designing a product, you have to define the target demographic for your portfolio. And on top of that, you have to distill an overwhelming topic into something approachable.

The most overrated skill when you're working on a product is internal communication.

With the proliferation of asynchronous work, most of what you make must be self-explanatory. And for that reason, you need to master communication skills. The most important is writing.

Julian Shapiro has a free guide that in a way it shows you how to fall in love with slowing down your thinking and drawing connections between ideas:

Think of what do you want your case study to be and generate. People will want to meet the person behind the voice. Make them curious by bringing novelty and resonance to your story.

  • Counter-intuitive — "Oh, I never realized the world worked that way."
  • Counter-narrative — "Wow, that's not how I was told the world worked!"
  • Shock and awe — "That's crazy. I would have never believed it."
  • Elegant articulations — "Beautiful. I couldn't have said it better myself."
  • Make someone feel seen — "Yes! That's exactly how I feel!"

Stories reach the emotional part of us.

When we are learning something, the brain utilizes 20% of its capacity incorporating the new knowledge. The rest is making associations and connections to past experiences. This is for the sake of creating shortcuts and saving energy. But it also means that the same story can resonate differently depending on who is listening to it. Regardless, you have to aim to impact the emotionality of your listener.

What if Design Thinking is another flavor of the narrative arc?
What if Design Thinking is another flavor of the narrative arc?

Presenting design work is about storytelling, not the design process.

A common mistake in design portfolio presentations is assuming interviewers want to hear a profound narrative about the product problem. We don't. We want to hear about your challenges while working on the product problem. The difference between one and the other comes down to storytelling.

Move from listing the sections to embarking the reader on a journey.
Move from listing the sections to embarking the reader on a journey.

A good presentation tells a unique story, and odds are the story you describe as a designer will not follow a linear, foolproof design process.

The design process outline is typical: We discovered a problem or business need, I did some research, brainstormed a few solutions, prototyped and tested those solutions, and learned some things and shipped.

When you present work using the design process, the interviewers will have learned nothing about you as an individual or as a designer. Interviewers will only realize that you know the design process, which anyone can readily understand and recite from a quick Google search.

Think of this example following a storytelling arc

The (Background) Business was booming until we realized there was a vital need from our customers. As a designer, (Conflict) I had never worked on a challenge like this before. I was anxious and worried. Would I be able to learn what I need to for this project? (Rising action) I spent time experimenting and failing. I learned the importance of collaborating with product management and involving engineers in research. (Climax) Do you think I succeeded? I did! (Falling action) I learned about a new development process and created a solution in record time. (Resolution) I later shared the process I learned in a company all hands, and the solution we built has been growing in usage ever since.

I should be able to understand your story only by reading your headings.

A great way of overcoming writer's block is by outlining the content of what you're going to write. Tools like Google Docs or Notion let you create a table of contents automatically.

Tables of content: Useful for the writer to outline information. Valid for the reader to skim through the story.
Tables of content: Useful for the writer to outline information. Valid for the reader to skim through the story.

Content outlines help you plan how your unique angle on a topic will stand out, provide the context for why anyone should actually read it, and build enough depth into each section so that the final product is compelling (as opposed to generic).

Be unexpected and predictable: tease and leave them wanting for more.

Make open-ended questions at the beginning. Make people think, don't give them all at once. Create stories that resonate in them. Avoid jargon and acronyms. Think of tools you can use to trigger that:

  • Questions — Pose an intriguing question, but don’t give the full answer.
  • Narratives — Share the start of a narrative, but withhold the conclusion.
  • Research — Highlight research findings, but only a small portion.
  • Arguments — Make an unexpected claim, but don't explain how it's true.

You're not there to teach people how design works. It's more about your personal journey and the challenges you encountered. Tell me what are the lessons you learned from solving problems, and how can you take those learnings with you into your next endeavors.