The best design work is done when it consists of many diverse opinions. But providing critical feedback to another designer can be tricky, particularly when the one receiving the feedback is less experienced. To ensure ad-hoc critique is well-received, consider:

1. Establish trust: Before diving into feedback, cultivate a relationship based on mutual respect. It's far easier to be receptive to feedback when you know the person giving it is a partner.
2. Be specific: Vague feedback can be confusing. Instead of saying, "I don't like this color," explain your rationale and concerns. "The blue shade feels a bit cold; perhaps a warmer tone might align better with our brand?"
3. Focus on why over what: Always accompany critiques with reasoning. By explaining why a change might be beneficial, you allow the designer to understand the broader context and goals.
4. Make it a conversation: Feedback is best when it's understood and actionable. Part of what makes this possible is enforcing a two-way conversation. After sharing feedback, ask for thoughts and be open to counterarguments or alternative solutions.
5. Stay objective: Aim to be as objective as possible, focusing on the design's objectives rather than personal preferences.

In conclusion, mastering the feedback process in design collaborations is crucial. With trust, specificity, and open dialogue, designers can elevate their work and strengthen their professional bonds.

‍

Every team is akin to a mechanical machine. And, like a machine, it's essential to make time for calibration.

"Calibrating" in the context of team dynamics means aligning a team's understanding, goals, and expectations. This alignment is vital to ensure everyone on the team works toward the most recent organizational goals. It helps teams enhance communication, manage performance, and mitigate conflict around prioritization and expectations. Regular calibration also means the team can adapt to change efficiently, as everyone will be familiar with the calibration process.

How often a team calibrates will depend on the type of work the team is doing and organizational and group dynamics. A perspective I like to take is making calibration cadence the same speed with which you want the team to perform. For example, fast-moving teams can calibrate monthly, when a shifting landscape of priorities and quick learning is pivotal. 

Typically this calibration process is the responsibility of a Product Manager, though Product Designers and Engineering Leads/Managers can contribute or be responsible too.

When it comes time to calibrate your team, here are the questions I think every person should be able to address:‍

1. Have we defined a clear and prioritized list of objectives for our product?

The first step is to determine your key objectives. Factors like market demand, business goals, or user needs can help you to define these. You could conduct market research, user interviews, or surveys and review your business's strategic plans to define your ongoing priorities.‍

2. Are these objectives tied to tangible and measurable key performance indicators (KPIs) within our control?

Once you have priorities, determine how you'll measure success. You can use almost any measure of success. Still, a proven way of measuring efforts in a team is Key Performance Indicators (KPIs): indicators of success that are tangible, measurable, and ideally under your control. Use tools like a team dashboard, regular share-outs of progress toward objectives, and balanced scorecards to help structure your performance measures.‍

3. Has the entire team been effectively communicated regarding these objectives and the reasons behind their importance?

Ensuring your entire team understands these priorities and why they're essential is paramount to performance success. You could communicate priorities and KPIs through a team meeting or something more informal and async (such as a regular Slack update to the team), depending on what's most effective for your team. Be open to questions and discussions to ensure everyone is on the same page and get total team commitment and momentum behind the priorities.

4. Are our stakeholders fully informed about our objectives, and do they understand why these are crucial for our product's success?

Like keeping the team updated on priorities and the reasoning behind your objectives, you'll also want to communicate priorities to stakeholders.

Stakeholders are anyone with a vested interest in the team's success: your manager and other functional managers (Director/VP of Engineering or Product Management, for example), organizational executives, and so on. Use shareouts with these audiences to fine-tune your strategy and priorities. Again, be prepared to explain why these priorities matter and be open to stakeholder questions and input.‍

5. Have we effectively communicated our objectives and their significance to our partners?

If you're working with internal/external partners or high-touch customers, they must also understand your priorities. Preparing a formal presentation and regular check-ins are great ways to inform and align with your partners.‍

6. When was the last time we revisited these objectives, and do we still agree that they align with our current strategy and market needs?

The final question is about reassessment. The business environment changes rapidly, and so too, might your priorities. Set a regular schedule (e.g., quarterly or monthly) to revisit these priorities as a leadership team, assess whether they're still valid, and adjust as necessary.

--------

None of these questions or processes will surprise you if you've been part of a well-maintained team. Yet, many teams need to address and regularly reassess one or more (or all) of these vital questions.

Whether you're a product manager or a product designer (or in a completely different role), you can take each of these questions to your team to identify where there are opportunities for calibration. In fact: that's what I'm doing with my team now.

In the end, team calibration is a process that helps align your team's understanding, goals, and expectations.

The questions I've outlined here aim to ensure clear and consistent communication of priorities across the team, stakeholders, and partners and establish measurable metrics to track progress. The ultimate goal is to drive better alignment, enhance performance, and ensure a shared understanding of objectives. And that's everyone's job on a team.

BONUS: Here are 15 additional questions to ask during calibration exercises with your team:

1. Do we have a shared understanding of our target audience and their needs?
2. Are we continuously gathering and incorporating user feedback into our product development process?
3. Do we have a clear, shared vision of our product's value proposition?
4. Are our current resources (time, people, budget) sufficient to achieve our objectives?
5. How well does our product align with the overall business strategy?
6. What competitive advantage does our product have in the market, and how can we enhance it?
7. Are we tracking the right metrics to measure the success of our product?
8. How are we managing risks and what is our plan for unforeseen challenges?
9. Are we fostering a culture of open communication, collaboration, and continuous learning within our team?
10. How are we fostering innovation and encouraging new ideas within our team?
11. Are we maintaining a sustainable pace of work, to avoid burnout and maintain team morale?
12. What is our strategy for maintaining and improving product quality?
13. How are we keeping up with technological advancements and market trends that could impact our product?
14. Do we have a clear roadmap for the future development of the product?
15. How are we ensuring that all team members feel valued, heard, and motivated?
    

I began a work journal for my Netflix projects one day after starting the job. I update the journal semi-regularly, documenting everything from daily activities, achievements, feedback, and ideas, to priorities, challenges, and visuals such as prototypes or design critiques.

The journal has been valuable for documenting my work and reflecting on my experiences and growth.

But the integration of Notion AI has taken my work journal to new heights, magnifying its value tenfold.

Before I get into details, I'll briefly address the critics and naysayers: Is a work journal in Notion, paired with Notion AI, really all that valuable? Yes. It has exceeded what I imagined possible and helped me summarize my work, generate insights into my behaviors, identify trends, create a strong outline for a future case study, and much more.

I use Notion AI in my journal to analyze sentiment across projects, extract themes, highlight frequently mentioned projects, and compile blog posts and case studies.

Notion AI has been beneficial in generating insights for self-assessment. Asking the app to "Highlight what strengths the author seems to have, then highlight the areas for improvement" offers an interesting perspective on my work.

The natural language processing capabilities of Notion AI enable time-boxed queries and interpretations, making it easier to assess and identify valuable insights. For example, running a prompt like "Summarize the most impactful things I did this year" provides fantastic results.

Setting goals for upcoming quarters has become more effective, and summarizing specific work periods, like "the last quarter," saves time while providing a unique way to reflect on past work. At the end of each month, I now ask Notion AI to "Summarize the past month of work entries" for a quick and easy overview of the month's work.

Additionally, the AI-generated design case studies based on my journal entries are incredibly accurate and can be enhanced by adding a personal perspective. Asking the AI to "Generate a design focused case study of the most recent project in this journal" returns incredible results. However, asking the AI to then "Make the case study more personal and reflective" amplifies the case study to an exceptional level.

While I can't share specific examples due to confidentiality, I wholeheartedly recommend starting a work journal in Notion. After a few months of logging your experiences, thoughts, concerns, ideas, etc., take advantage of the built-in AI.

Notion AI can seriously help make sense of your work journal, identify themes, summarize your experience, generate case study outlines, set goals for future projects, and much more.

Ask any designer if they're happy with their design portfolio, and you'll get the same answer: "It could be better."

Part of what makes having a portfolio website be in a never-ending state of construction is the ever-present feeling that it needs to be up-to-date. Not merely updated with the latest work, but with a fresh design too—something that can better represent the designer and the level they're at in their career.

However, updating a portfolio often comes begrudgingly. Why update something that isn't serving a timely purpose? Unless you're actively looking for a job, it's not clear why an updated website matters. Many of us don't have the time to update—let alone maintain—a portfolio website.

Personally, I think of my portfolio as an experiment of sorts. It's a playground I can use to share my ideas and work in interesting ways. I've been managing a personal website for more than 21 years now. And while my original website was on a different URL than my current one (tannerchristensen.com), I've always viewed my website as this experimental playground, my own little private slice of the Internet. I think of my portfolio as a place where I can explore not only how I show my work but how I present it as well—how I talk about the things I've done and how I think about my work.

I recently looked back at the experiments I've put into this website and the emerging patterns that I've used to represent my career identity online. Here's a look at the past 15 years of my design portfolio website.

My website before 2008 has been lost to time, but it's probably for the best. Even this snapshot of my homepage in 2008 makes me uncomfortable. "You need my help" is a bold statement to make, particularly for someone who was only just beginning to solidify my ideas around what it means to be a product designer and digital creator. Note the lack of visuals on this version of the homepage—not something very design-forward.

A year later, I removed the ego-based plea for design clients and instead emphasized my projects and full-time job as an online manager for a news company. Moving to a more welcoming homepage meant I could try and drive people into learning more about me and my work, such as my very first iPhone app Pokeseo.

In 2010 I decided to begin "showing" more of my design work rather than merely "writing" about it on my website. I transformed my homepage into a place where visitors could get a quick feel for the type of projects I worked on and then click-into them to see more details of each project.

Most notably in 2010 I really began to highlight my overarching creative work, not just traditional graphic design work. Also used a large blockquote to "set the stage" for my work. A little ego can be impactful, helping prime visitors to the website with expectations.

Figuring the visual previews of my work was a good way of capturing visitor attention while also enabling people to see the types of work I was doing meant making a bigger grid of images. Here I wanted the work to be the primary thing visitors to my portfolio see, so I bumped up the images considerably and made the grid 90% of the homepage.

In hindsight, I'm not sure why I chose to use small, cropped previews of the work rather than more helpful previews. Here visitors are essentially playing a guessing game of what they'll get by clicking into any of the grid items. (The grid items appear to be faded due to a lowered opacity, upon hover the opacity would animate to 100%. I would never do this again because the default state looks like the images simply haven't loaded properly.)

Seemingly having learned my lesson in 2011 with the cropped images, in 2012 I moved to a more colorful approach with my grid. Here I show not only full-context images, but I highlight mentions of my work in news and blogs rather than explicitly showing the work itself.

I figured: why write a case study about my work when other people have done it more or less for me? The ability to link to places like Design Taxi, Lifehacker, Adweek, Gizmodo, etc. felt nice and probably helped visitors understand the seriousness of my work. But at the same time, news articles don't help anyone understand exactly what into my work. So I lost part of the control for telling the story of my career and work with this approach. Fun experiment, but I quickly pivoted away from the approach the following year.

Back to a much more "mature" design portfolio in 2013. I knew I wanted to have more control of the narrative of my work, so rather than linking out to other websites I began to put together case studies of my own. I also began spotlighting more focused work: rather than talking about my blogs, strategic work, and creative experiments, I began to spotlight only my digital work. Web-based and mobile apps became my passion and so that's the work I began to highlight in a clean, albeit "hard to see the details" kind of way.

Side note: I feel like almost every designer goes through this phase of wanting to show their work in product mockups. It's fun and can look pleasing, but it also diminishes the design work itself.

Also note: this is the portfolio I used when I landed a job at Facebook, all those years ago.

Moving back to a regular, text-free grid in 2014 meant being able to spotlight more of the visual information I want to in thumbnails. I also introduced "featured" grid items that were 2x the size of others, as a means of drawing more attention to those specific projects or case studies. Adding my avatar to the mix was intended to make it easier to associate my online presence with the portfolio.

It was clear at this point in my career that the optimal way to present work was with a grid of images. I expanded my work into new areas (like my first published book). I removed padding from grid items to try and create a more "singular" representation of my work, and even included my latest Instagram post in the image grid as a way of humanizing the page, I guess.

Updates between 2015 and 2017 were minor. I was focused on my work at Facebook and only updated my portfolio to include the most recent work I was proud of (like having my work featured at Facebook's annual F8 developers conference in San Francisco).

It's here, in 2017, that I think I began to solidify what I wanted to show on my website portfolio and how I wanted the website to be the "heart" of my online presence. Including links out to other places like Twitter, LinkedIn, Medium, and my writing on Inc or Adobe's (now defunct) 99u Blog.

From 2017 onward I really didn't change much in my portfolio. I made sure to include any recent case studies I could, and occasionally updated the "bio" or summary statement at the top of the homepage. But I felt confident in the layout I had landed on over the years: a colorful grid of images that links to specific case studies (which include larger, more detailed images, and a written narrative of the work experience).

I started to view my portfolio website as a "museum" of all I've done—not just in product design, but app development, writing, and consulting. I wanted the website to serve as a way for me, and others, to better understand the various skills I've utilized throughout my career. The blog helped as well, as I could write about things like company culture and design career pathways.

Near the tail end of 2022 I had worked at many companies, acted in varying roles, seen projects triumph while others floundered, and began to define who I wanted to be in my career. I landed on going back to my deep passion of product design work, and was fortunate to land a job at Netflix doing exactly that.

It was evident my website needed a refresh to better represent my newfound love for the work I do. Moving away from the image grid idea that had served me for many years, I decided to use my website homepage as a more succinct representation of my work. I wanted to show visitors a "snapshot" of my work experience, and opted to use a vertical, miniature grid approach to serve that purpose. If you're curious, I did two livestreams about the portfolio design, explaining my thinking and how I went about building the structure. Watch part 1 here, and part 2 here.

I'm looking forward to doing a similar post like this one in another 15 years. Who knows what I'll hope my portfolio expresses about me then!

Keeping a work journal is one of the best things you can do for personal development. A diary of work is also an excellent way for designers to build a case study for their portfolio.

In design, case studies are powerful storytelling devices that help others understand how you work and what you can do as a design partner or contributor. If you're interviewing for a job, there's no better way to discuss your skills than through a case study format: a real-world example of an experience and what you did throughout.

But how do you know what information to include in a case study? How do you know which collaborations to call attention to and which you're better off not mentioning?

Enter the work journal.

A work journal is exactly what it sounds like: a journal specifically for your "work life."

Anything from setting and evaluating common goals for yourself or capturing a message about a challenging interaction with a co-worker are great uses of a work journal. It's a private and safe place for you to catch daily or weekly notes about the things going on in your work, the good and the bad. There's no right or wrong way to keep a work journal, but a few things I have learned through experience can make yours even more valuable as a guide for building case studies.

Tools for work journals

There is an abundance of tools to pick from when it comes to journaling, and what works for someone else may not work for you. The criteria I recommend evaluating when comparing tools for a work journal are simple enough:

• Is the tool something you can reliably access daily?
• Does the tool allow you to embed photos, gifs, and videos?
• Can you use markdown or another formatting approach to create a visual hierarchy in the tool?
• Does the tool enforce a linear format for journaling?

I use Notion for my work journal because it's accessible from anywhere, on any device—I can jot down a thought on my phone while running between meetings or sit down at my desktop computer and write at length. Notion also makes creating re-usable document templates easy, you can embed tons of media types directly into it, and you can nest things like work projects inside your work journal.

Other tools you might consider for your work journal:

• Day One
• Evernote
• Bear App
• Google Docs
• Dropbox Paper
• Apple Notes

Formatting a project journal

Once you've picked a tool, it's time to think about the format of your work journal (and the project journals contained within it).

I have a primary work journal project in Notion that houses anything related to the company I am working at during that time. So, as a personal example, I have a collection of project folders or pages in Notion for each company I've worked at since I started journaling: Lyft, Atlassian, and Gem.

The project journal is a valuable part of any work journal because it captures project-specific reflections and notes. Within each work journal, I have multiple project journals: dedicated pages for every defined project at the company. Some projects are short journals—no more than two weeks of entries—while others span months or years. I format each project journal with the following information:

Metadata:

• Project name
• Project start date
• Last updated date
• Completed: yes/no
• Project version (is this a 1.0 project or something like 1.1 or even 2.0?)
• Project status (Draft, In progress, Scrapped, Completed)
• Contributors
• Informed

Outline:

• Project summary, in my own words
• Project goals and key results, again, in my own words
• Daily notes
• Learnings and outcomes

What information you include in your project journals may be different. Over time you will likely learn that more (or less) information is helpful for you and your needs.

Most of the information in the project metadata section won't change. What will change often is everything under the daily notes portion.

Keeping daily notes

I have 15 minutes on my calendar for heads-down time to reflect on the day and journal what got done. I don't restrict myself from journaling during those times, but I have found that having that set time on the calendar helps me remain consistent.

During scheduled journaling time, I'll capture what I remember from meetings, points that came up during my one-on-one conversations, or any specific design artifacts or elements I'm exploring at the time.

My work journal's daily notes section of a project becomes a linear timeline of events.

You don't need to capture everything that happened for a project; you only should note what you think matters most for you, your personal development, and your learning. Including photos (like of you and your team collaborating on a whiteboard) and videos (like a few seconds of an early design prototype) can add to the story you're telling and remind you of what you were up to that day. Those artifacts also become invaluable when transforming your project journal into a presentable case study.

Turning a journal into a case study

Once you start contributing to a work journal, you will have begun creating a powerful narrative for a case study through the sheer nature of personal reflection and journaling.

The linear and personal format of a journal works well for translating into a case study because it focuses on your personal experience of the work. Your journal won't follow a stereotypical template of some romantic design process; it will follow the actual process you took through the work. It will be faithful to what you experienced as you worked on the project, making for a compelling case study.

A great case study format to extract from a journal looks something like this:

• Where did the project start, and how were its goals defined? Did your manager tell you about the project, or did you kick it off with a team? Was the project hand-delivered to you as an assignment, or was it something you figured out?
• What was your first interaction with the project, and how did you feel going into it? Were you intimated or excited? Eager or annoyed? Why?
• What was the first thing you did? Not the first thing the team did, but what did you do once you learned about the project? Did you schedule meetings with stakeholders, look through past research, write down everything you knew about the work to come, or something else?
• What was the first (or second) challenge you encountered? How did you feel? What did you do to work through the challenge with others?
• How did the project typically progress? Did you need to rally the team together regularly, were regular meetings booked by a product manager for you, or did you set up consistent design critiques for the team to give you feedback? Did you do research, and if so, who scheduled it? How did all of that work feel for you?
• Were there any notable challenges you faced during the project? Call these out! Was there a disagreement between you and someone else? Was there a time you dropped something or failed to meet expectations? How did you recover from those things?
• Where did the project end up? What, if anything, would you have done differently?

That last question—it's worth noting—is a section all on it's own in my project journal format. Because there's typically a moment in a project where you wrap up your work to move onto a different project, and that's a great time to reflect on the experience.

In the learnings and outcomes section of a project journal, you should find more time than usual to go through the daily notes and reflect. Did the project end up where you and the team set out for it to go? Why or why not, do you think?

Did you learn anything about yourself, your process, or your skills from the project? What were they?

Wrap up both your project journal and any case studies that result from it by answering the question of previous questions, and you'll have created something that exemplifies why the project is worth sharing in the first place.

The work we do as designers matter a lot for those who use or experience what it is we build alongside others. But the work we do also matters for ourselves: our ability to be thoughtful and aware individuals who are constantly evolving, much like our work.

It's easy to get wrapped up in the metrics and postmortems we have for projects and forget that we are also growing. A project or work journal can help remind you of the ways you are growing and give you a great set of fieldnotes to pull from when it comes time to talk about that work in the future.

I used to believe that what made great designers so great was their craft; their ability to add polish and style to whatever they touched. Now I see that what makes exceptional designers so incredible is not only their attention to detail, but their ability to think holistically about their work.

Long ago, I would spend time browsing Dribbble or Behance and admiring the beautiful aesthetics and animations I saw there. I'd look at portfolios of the most stylish, trendy work for everything from logos and websites to app designs and character illustrations. Whenever I encountered something that seemed highly polished, I'd think: "This is great design!"

It's easy to view design as making things pretty, as though the presentation of the work is all that matters because that's the thing we can see. For those outside the design world, this is a similar perspective to that of art. We tend to celebrate art for its appearance. Apple famously makes beautiful objects and proudly shows them off as such under the veil of "great design."

At some level, this notion that good design is polished craft is true—craft (a delicate process of detail) and visual polish matter significantly in design. But what I've learned over time is that the best designers can think holistic about the work, not just its presentation. They have a keen ability to think and imagine beyond just the design on the screen or canvas.

Inexperienced designers tend to think only within the boundaries of what they're making. They've heard that building a deep understanding of what they're making will strengthen it but often narrow their focus, so they fail to understand how putting their work out into the world might break it apart. The design these inexperienced designers create fails to stand up when it encounters someone with a disability or is taken out of context or distorted by size or time.

Poor design meets one need while creating a dozen others. Good design resolves problems without negatively affecting anything else in its ecosystem.

We call this lens of thinking "systems thinking." It tends to separate the genuinely great designers from the pretty-great ones.

The designers who do tremendous work know that what they're creating does not exist within a bubble. They understand that the context of what they're making plays a vital role in how the team should build it. They know how what they create affects everything it touches, particularly the people. The design is intentional. Trade-offs are known, weighted, and decided on. Not only in the immediate problem space but in the surrounding spaces too.

If you want to be an average designer: focus on a narrow perspective around whatever you're making. Don't worry about how what you make will affect the industry or the people who use or encounter it in different capacities. Don't worry about those who will have to evolve the design or those who might come after you to tweak it.

On the other hand, if you want to be a designer whose impact is beyond a narrow scope: constantly hone your process to consider the range of what—and who—your design work will impact. You can do this in many ways, some of which have been documented in-depth across the Internet.

Build out extremes of your work, the most straightforward and complex versions. Not to say you've done it, but to get a feel for what those extremes look or feel like in context.

Build always with the intent of sharing your work (even if that's not going to happen). Sharing work early and often might mean leaving ample notes or comments in your working documents if you're on a team. If you're working independently, leave the comments anyway. You never know when you'll have to return to some old work and how quickly statements and well-structured documents can help you reconnect and understand the work.

Invite others to provide feedback as often as possible and engage them with questions and curiosities about how their work shapes their perspective of your work.

Look at the larger ecosystem your designs need to exist in, and you'll build things that look better (due to consistency and familiarity) and function better. And that's what makes someone a phenomenal designer.

‍