Storytelling is a key skill for designers, and it can be also used to understand what we learned and to create better portfolios - by telling stories about our own experiences.
☕ Writing experience stories for better portfolios
The first step in hiring is usually reviewing what the candidate shares about themselves, their CV, and their portfolio. These should help the hiring manager to decide if it’s worth scheduling the first interview. When reviewing portfolios, I look for a few things. Most importantly if the person is capable of learning and has the skills the role needs - beyond being able to produce pretty artifacts. This is often not obvious or even plain not visible by just looking at most portfolio items.
Another issue I frequently encounter while checking portfolios and even mentoring designers is the lack of progress in their careers. They do a webshop, and afterward another webshop, and so on. 10 years of career, and it’s the same 1 year’s worth of projects 10 times. This often results in designers being stuck with mid-level tasks, unable to increase their scope and impact, and level up in their careers.
I found an approach for both of these problems:
- Systematic reflections to understand learning over time.
- Creating stories to be told that crystallizes learning over time.
I call these stories “experience stories” to distinguish them from other types of stories we have in product development. Experience stories are not necessarily the portfolio elements themselves. Rather, they are more summaries of experience obtained and learning - that can be formed into a good portfolio item.
When designers start out their careers, a single project results in a lot of learning. A junior learns how projects are done, how to collaborate with peers, and how they should apply their design skills. As they get more senior, their skills improve, and learning will be less about execution, and more about the process, self-management, and communication. Both breadth and depth grow. Learning happens in strides, sometimes connected to impactful projects, but often as the result of small improvement steps over months or years.
Learning starts with reflection, understanding how things went, describing what was learned, and deciding on what to try differently in future projects. This reflection is often delayed or missed. Since it takes time with a potential payoff far in the future, people are usually more focused on shorter-term concerns (like finishing the next project). For example, one outcome of reflection is portfolio items. Hence when designers don’t reflect, they end up creating portfolios when they are looking for a new job, and this results in fairly shallow portfolios with relatively little information on learning.
This is where the second step helps. Thinking in stories adds structure and provides a way for reflecting. This makes reflection less open-ended and more purposeful. Stories are not designed in a single run, rather get better over time as they get told, presented, and written down again and again. The essence of the story doesn’t show itself immediately, it needs shaping. Sometimes the learning doesn’t even happen immediately, but over longer periods. We realize in hindsight how approaches at past projects failed or can be improved upon. Just like in product design, where the essence of a product is discovered over multiple iterations.
Compared to just writing portfolio items, stories are more flexible and can be customized to different contexts. Stories don’t stand on their own, but are shaped by the storyteller and received by the audience - the final form depends on both sides. As such elements of the story can change, but the key message, so the core of the earning will remain the same. Creating a portfolio item is an experience story taking a particular shape.
Reflection should be a recurring activity, done every month or at least a few times per year. It should start with a short review of what happened (having a brag doc helps), and what would be worth reflecting on. To think in stories, reflection can follow from the start of a narrative scaffolding, such as the STAR framework (Situation, Task, Action Result). Add plenty of artifacts (images, text experts) by simply copy-pasting into your tool of choice - this helps when making a concrete artifact, such as a portfolio item or presentation.
What should be the story about? The point is not just to get as many stories as possible (that’s breadth). As designers progress with their careers, the stories’ scope should deepen. As a rough rule of thumb, depending on one’s level the story’s main narrative can focus on the:
- Interns: The first adventures as a designer or researcher.
- Juniors: Perfecting methods and tools, adopting new ones, focusing on the tactical part. Impact on a personal level. Results are outputs.
- Mids: Adopting your methods, tools, and processes to new contexts, innovating by adopting methods to new contexts. Impact on a team level. Results are user outcomes.
- Seniors: Creating new tools, methods, and processes depending on the context, and innovative use of principles and approaches. Impact on the broader org. Results are business outcomes.
As you learn, your tasks and execution skills should grow deeper and also wider. Experience stories should reflect this progress - otherwise, it’s just repeating routine work. Once you start articulating what you did while reflecting, it also becomes clearer what can be iterated upon in the future. This is how stories also support future development.
For design leaders, encouraging team members to create stories and share them has some additional benefits. Stories are great artifacts to work from when creating promotion cases or figuring out growth plans. Knowledge shared in a story format is a good incentive to create it, it helps the designer share to iterate on lessons learned, and raises what the team overall knows. A small added advantage is that most teams are not great at celebrating their successes - and hearing about lessons learned is a great way to get the drinks and cake out for the team.
This is a post from my newsletter, 9am26, subscribe here:
🍪 Things to snack on
Writing experience stories is a practice based on Double Loop Learning, as described by Farnam Street. Single-loop learning happens while we do things like working on projects. Within the established structure, practice gets better over time, but there is no route to dramatically improve. That’s where reflection comes in, kicking off double-loop learning. Since successful professionals rarely fail, the reflection is limited by both the perceived cost and being defensive on failures, seeking justification outside of established practice. Instead of getting defensive, experience and data can be examined through reflection and new experiments run to test structures - in mindset and approaches. This leads to novel and new approaches.
The power of using stories has a simple reason: Great Stories Release Brain Chemicals, as Susan Weinschenk writes. There are common plot points that resonate with people and form archetypal stories (Overcoming a monster, Rags to riches, The quest, Voyage and return, Comedy, Tragedy, Rebirth). Some of these stories (like The quest) fit well portfolio descriptions and give a recognizable narrative framework. The stories made of common plot points are easy to understand to people. Listening to such stories release brain chemicals, which results in a direct physical change, that makes it easier to connect to. This explains why stories are so powerful if we want to transmit information.
Telling your stories is just as important for growth as the story itself, writes Simon Pan in Great Design Portfolios Are Great Stories. He also has some advice how to prepare portfolio pieces that tells a story and craft a narrative around the work done.
Your experiences should be shaped into stories as something that will be read or listened to. The easiest form for this is presentations, and Jonathan Walter has a lot of useful tips about these in Telling a Story Through Your Portfolio Presentation. The article details how most projects can be applied the common story structure of Exposition - Rising Action - Climax - Falling action - Denouement. This needs to be shaped into a presentation too - probably a longer project story can go together with multiple shorter project highlights. The article also remarks that the best stories are told effectively, this is where storytelling skills can shine.
Budi Tanrim gives a simple framework for writing about projects, as he argues it helps make sense of things in Making sense of your design project by writing . Just like more generally in design, once things are on paper, it’s easier to spot unclear things that need further follow-up. This also shows how thinking in stories also helps much earlier in design work, not only when creating a portfolio piece. The starter questions he shares are also good to think about when creating a portfolio piece:
- Why did your team start it in the first place?
- Who is the target audience?
- What is the customer problem we’re trying to solve?
- What data do we have to back up this argument?
- Why is this worth solving?
- How is this useful for the company?
Comments