Telling a Story Through Your Portfolio Presentation

Exposition and Inciting Incident

Now, I’ll describe how you can apply a common story arc to your presentation, beginning with your exposition and an inciting incident.

Defining the Character’s Role

A crucial aspect of telling an effective and accurate story is defining the character at the center of the story, which in a portfolio presentation is you. You must define your role on the project, including your responsibilities and expected deliverables, because reviewers want to learn what part you played—or didn’t play—as the story progresses. Too often, candidates use words such as we or us to ascribe vague ownership for project deliverables and outcomes, making it difficult for portfolio-review teams to discern their individual contributions. While it is noble to demonstrate a team-first mindset, do not overcorrect to the point that your role becomes ambiguous.

Conversely, never take credit for something you did not do—even if doing so seems benign. There are many ways for employers to detect falsities in our hyperconnected world. Plus, the UX community is still relatively small, so news gets around quickly if you earn a reputation for being dishonest. Reviewers need to clearly discern what you did—even if you worked on a highly collaborative team. They are not interviewing your former or current project team for a job, they are interviewing you. Commit to showcasing yourself—even if your deliverables depended on the actions of others. Nobody can be great at everything, so employers should not expect you to be a multidisciplinary phenomenon who does everything perfectly on her own. Unicorns are mythological.

Describing the Business Problem

A good story thrusts the reader, viewer, or listener into the action. In the case of a portfolio presentation, this happens when the problem, or inciting incident, occurs. What problem pulled you onto the project or perhaps compelled you to insert yourself into the team? It is important to ground the problem space in reality so reviewers can appreciate and relate to the challenge.

For example, rather than simply stating that your department director wanted a Web application that would allow consumers to choose and purchase shades of lipstick online, state the business problem in a way that piques interest or reveals conflict. You might say, “If we failed to give consumers the capability of choosing and purchasing different shades of lipstick online, our company would fall behind our key competitor, which already offers that feature. That gap would continue to grow unless, rather than just providing a similar capability, we outperformed that competitor by giving consumers a more efficient, effective experience.”

Defining Requirements and Scope

Next, describe the project’s requirements and scope. However, do not regurgitate them in a manner that sounds like you’ve lifted them from some bloated marketing requirements documentation. What is the story? Just as you’ve done when describing the problem itself, infuse narrative into the requirements and the timetable. For example, rather just stating the boring facts that your business sponsor wanted an improved onboarding experience for a software application and the final workflow design was due by August, communicate why. Were users frustrated by the existing product’s onboarding workflow? What ugly things did users say about it, and how did such feedback influence the requirements? Were customers threatening to switch to your competitor unless your company delivered a better solution by the end of the year? It’s even better if customers and users’ unflattering comments were actually humorous. Stories arise effortlessly from anecdotal user feedback and are more memorable than recitations of sterile facts.

Rising Action

Next, let’s consider how a story’s rising action propels a story forward.

Conducting User Research

If you conducted user research before designing your solution, think about the users’ own stories. What were their goals and painpoints? If your research served as the genesis of user personas or mindset documents, share those deliverables with the portfolio-review team. Who were the people at the center of your efforts? What were their names? What was important to them?  While you’re the main character of your presentation’s story in the eyes of the review-team members, users are the protagonists of the story in the design deliverables you’re showing. Ensure that the review team gets to meet them.

Proposing a Hypothesis for a Solution

As a story progresses, protagonists make decisions that propel them toward conflict or even a point of no return. Once they commit to their journey, they must accept the consequences and deal with the resulting obstacles that lie in wait. What did you decide after getting to know your users and their histories with your product—if such histories existed—and the business requirements that internal stakeholders handed down to you? What was your stance? Once you completed your up-front work, what hypothesis did you arrive at? What did you believe would solve the issues the characters in your story—the users—experienced? Describe the data and the rationale behind your hypothesis to reviewers—even if your initial hypothesis was flawed in some way.

Creating Your Deliverables

As the action rises, a memorable story shows the protagonist demonstrating savvy and the skills necessary to solve problems and navigate obstacles. Show reviewers the quality of your own skills and share your resulting hypothesis. Depending on your character—your role—this could entail presenting sketches, wireframes, high-fidelity design comps, research documents, or all of the above. If your deliverables evolved over the course of the project, beginning with sketches and becoming more polished over time, build a subplot from those deliverables. If, over the course of your deliverables’ evolution, you iterated them based on user feedback, that is even better.

Iterating Design Solutions

Speaking of iteration, the best stories show characters’ mindsets as they change throughout their journey. People change. They are not the same people they were when their story began, which makes their journey all the more compelling and realistic. Plus, your willingness to change your mindset demonstrates your ability to adapt, which reviewers want to see. How did your mindset shift as you went through several rounds of usability testing and subsequent design iterations? How did this shift in your mindset manifest itself in your design deliverables? When you compare your initial hypothesis to your deliverables, what sacrifices did you make along the way? Conversely, what sacrifices did you refuse to make—even when you met resistance from project stakeholders? What compelled you to take a firm stance?

The Climax

Of course, every great story has a climax—the scene in which the rising action finally culminates in some big reveal or showdown. What was your climactic big reveal? This is your opportunity to show your highlights-reel material. Show the team how far you came. Better yet, contrast your final deliverable with your initial hypothesis, whether it was a rough sketch or a written statement. The review team wants to see your evolution. What better way to demonstrate this than comparing your hypothesis at the beginning of your journey to its climactic deliverable? This reveals your own character arc—your growth and ability to change.

Falling Action and Denouement

Following the story’s climax, the action winds down until you reach its denouement.

Communicating the Outcome

Usually, the climax is not the end of the story. To ensure a clear, satisfying story arc, the storyteller must balance the rising action that led to the climax with the falling action that reveals the outcomes that resulted after the climax. How did your final design solution fare with users once your team released the product? What was the outcome? Did the solution improve the user experience? Did it help generate revenue or save the company money? How do you know this?

Giving reviewers a tangible sense of your solution’s impact results in a more satisfying, memorable story. Chances are that review-team members struggle in concretely capturing their own success stories and communicating them to senior management. By showing your story’s outcome, you demonstrate that you can help them achieve similar goals of their own. Remember, they are trying to gauge how you will help them.

Providing a Retrospective

Many effective stories conclude with a denouement that features the protagonist reflecting on the events that led to the story’s final outcome, as well as that person’s evolution. How did the project help you to grow as a UX professional? What might you have done differently and why? Everyone can think of things they would like to revisit or redo. You can portray yourself as more relatable by acknowledging the things you didn’t get right.

Provide reasonable logic or evidence for the reasons another solution—or perhaps certain aspects of another solution—might have worked better. People want to work with others who acknowledge their knowledge gaps and embrace life-long learning. Being a UX professional is a journey.

Building Your Story into Your Presentation

You might be wondering how you can fit your story into your presentation—especially if you hope to touch on a variety of highlights from other projects. While it would be unrealistic to try to tell a story for every project in your portfolio within the short timeframe of an on-site portfolio presentation, you can structure the time for a story by embracing the T-shaped portfolio presentation, shown in Figure 2.

Does T-shaped mean you should go deep and tell your story literally at the midpoint of your presentation? Not at all. Perhaps it might make sense to tell your story right away. Beginning with a story not only grabs your audience’s attention but could give you a better chance of maintaining their interest throughout the duration of the presentation. According to Jennifer Aaker, stories are tools of power and force people to slow down and listen.

Alternatively, it might make sense to save your story for a time later in your presentation—after you’ve had a chance to demonstrate some versatility of domain knowledge, which could be a sought-after trait for the role for which you’re interviewing. The point is: you can convey breadth of experience by touching on highlights from a variety of projects, while still allotting time and space for probing deeply into a single project.

If you’ve already shared a digital version of your portfolio in advance of your on-site visit—as most candidates do—the odds are that the review team has already seen those highlights. So, by focusing on a story in your presentation, you can show them a side of you they haven’t yet seen and make yourself more memorable.

Telling Your Story Effectively

Be aware that the quality and structure of your story won’t matter if you continually focus your eyes on a conference-room monitor or projector screen rather than on the portfolio-review team members. When telling your story, be sure to face your audience and shift your gaze among the reviewers, meeting each person’s eyes to ensure they’re engaged.

Your presentation slides should not show every detail of every deliverable for every requirement. Less is more. Provide just enough information—the more visual the better—on each slide, so you can speak to it confidently and naturally. Reading a slide verbatim is a sure-fire way to lose your audience. You certainly don’t want reviewers spending their time reading either—you want them to listen to you. To ensure that they’re listening, you must engage them effectively, so invite questions. If some reviewers seem disengaged, pause and ask them whether they have questions or would like you to slow down.

Public speaking makes most people squirm. I can relate. But remember, nobody is expecting you to deliver a rousing product showcase that is reminiscent of Steve Jobs. People expect you to be nervous—just like they would be. This actually makes you more relatable. You’re all human beings, and they want to hire a person, not a machine.

Conclusion

The quality of your thinking and the way you handle adversity are traits reviewers want to see. They’re not interested only in seeing your final deliverables. They’re interested in the journey you took to achieve them. Reviewers want to be able to envision themselves joining you on such a journey. Telling them a story is an effective way of helping them form that mental picture. Telling a story is a much more effective means of communication than simply reciting facts.

Choose your story by identifying a project that featured some unexpected challenges. These help to reveal your character and your ability to evolve your mindset. Structure your story by using a common story arc—which people find relatable regardless of whether they’re consciously aware of it. Structure the time for your story by embracing a T-shaped portfolio presentation. This lets you reveal both the depth and breadth of your experience. Tell your story effectively by focusing on the reviewers in attendance, not on your slideware. Show just enough information on your slides to reinforce your story and pique your audience’s interest—without forcing them to read.

If you can tell a review team a good story about a successful project, chances are that you can achieve the same positive outcome again. Reviewers want to know whether you can present a vision or a concept to stakeholders, executives, and product teams. They wonder whether you can consider a complex problem and express a solution using simple, memorable, relatable terms.

Story matters. Your ability to tell a memorable story can help you to demonstrate those sought-after qualities that teams desire most.