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.

‍

Update: As of February 2022 Gem’s design interview process no longer includes a design exercise or design critique. We believe expedited and superficial test environments are no longer the best ways to get signal on how someone thinks through problems or collaborates. We instead rely on a values conversation and past collaborations.

What does a modern interview process look like for digital designers? Design leaders building their design team, and individual designers looking to join one, can get incredible value from knowing what a typical interview process looks like today.

Knowing what to avoid (like bias in the process or toxic culture signals) and what to invest a lot into (like interviewing for thinking rather than solely outputs), can help make the interview process more rewarding and effective.

There aren't many readily-available resources out there to help new design leaders and designers get a peek into the hiring process. When I first built the design team at Gem back in 2020, I had to connect with other design leaders and hiring managers at companies like Dropbox, Airbnb, Slack, Outreach, Stripe, and more to understand their hiring process.

Today our design interview process takes shape over six stages, spanning anywhere from two to six weeks depending on candidate availability.

1. Application review
2. Recruiter phone interview
3. Optional coffee chat with the hiring manager
4. Hiring manager phone screen
5. Past work review
6. Onsite product demo, past work presentation, design exercise, design critique, and often a lunch break with some of the team

1. Application review

The hiring manager and recruiter will evaluate applications for the job once it's open. Up until this point, the job has existed as a series of conversations and documents internally with the finance team, product and engineering leaders, and more.

Collectively the team will have created a set of needs in the business and mapped them to the job requisition. These needs are hopefully apparent in the job post where candidates submit their applications and resume.

The hiring manager and recruiter will look through resumes and portfolios to see if signals indicate the candidate may match the needs of the business. If there seems to be a good fit, the recruiter or hiring manager will reach out to the candidate to set up a phone call.

2. Recruiter phone interview

Once the recruiter identifies a potential candidate, they will initiate a phone call to chat with that candidate.

The initial recruiter interview is casual in nature, creating space for everyone involved to get any critical questions out of the way. This 30-minute video or phone call with the recruiter ensures the candidate aligns with the role as needed. It's also a great chance to build relationships and start the process of getting on each other's radar.

The candidate and recruiter will typically discuss location (remote or location-dependent roles), career ambitions, and interviewing timelines.

3. Optional coffee chat with the hiring manager

In some cases, the hiring manager will initiate the first call with a candidate. A hiring manager will initiate contact with a candidate when the role is senior or a level of connection exists between the team and the candidate.

This optional, 30-minute "coffee" chat is an informal part of the interview process and is not considered an interview in the strict sense. Instead, the coffee chat is a chance for the hiring manager and candidate to connect more casually with each other on a personal level.

What we look for during a coffee chat:

• Company experience: does the candidate have relevant experience in similar companies of our size and shape? Do they have a known, established design process? Have they worked on a cross-functional team? Are they interested in doing so?
• Types of product experience: has the candidate worked on business tools or complex platforms like ours? Are they familiar with products of similar shapes and sizes as to what we're building? Do they want to?
• Candidate ambitions: how does the candidate want to learn and grow in their career? Will this opportunity give them a chance to do that or not? If not, it might not be worth continuing the process.
• Visible design skills related to craft and impact. Does the candidate demonstrate clear articulation of design abilities? Do they have a clear portfolio of work?

4. Hiring manager phone screen

If the hiring manager's coffee chat goes well, the candidate enters the first part of the formal interview process: the phone screen.

In this 45-minute conversation, candidates will discuss experience, projects, and processes with the hiring manager or another design team member (depending on scheduling). This interview requires no screens, as the candidate should focus entirely on higher-level reflection and process. The conversation can be casual but must still be "on the books." The interviewer will ask four or five questions related to what the team is looking for in the role.

What we look for in the phone screen:

• Motivations: what is the candidate looking for in their next job? Do their incentives align with our company and design team?
• Overall design experience and level: does the candidate show vital skill in one or more areas of our design interviewing rubric? How do they work with other designers? Do their skills meet our quality bar?
• Passion for types of work: does the candidate demonstrate an ability to work independently? Can they tackle small tasks as well as complete goal-driven projects? Will they thrive in a startup environment where they will wear multiple hats on the design team?
• Prioritization: How does the candidate weigh trade-offs when it comes to their work? How do they ensure their work is essential for the business but also customers? Do they have a knack for work that will scale design's impact in the industry? Are they able to create momentum through their work?

5. Past work review

If the candidate has made it this far, it's time to dig deeper into their experiences and abilities. A past work review with a hiring team member can spotlight the actual work the candidate has done and how they speak to the job.

Candidates should expect to show one project from their portfolio of work, walking through a high-level overview of their process and outcomes.

The hour-long past work review can take shape as a website walkthrough (or Dribbble/Behance) or other presentation, including a live product demo if applicable. However, preparing a presentation is not encouraged as we want to discuss the work organically, not through prepared notes.

What we look for in the past work review:

• Design quality and candidate behaviors: evidence matches aspects of our internal design rubric with what the candidate shares.
• The material output of the design work as it rates across visual design, interaction design, and product thinking expectations.
• The behaviors of the designer as they speak to experiences: how they talk about past collaboration, communication, and aligning with the business values.
• Attention to detail and top-tier design craft, visual design, and interaction design best practices.

6. Onsite

Finally, we invite candidates to join us for a three-to-four-hour virtual "onsite" interview. The onsite stage is made up of four to five individual steps, starting with a product demo.

6.1 Product demo

A 30-minute overview of our business and product. Before we start the day of interviews, we want to help the candidate become more comfortable and familiar with things like our business model, product vocabulary, and value propositions. The product demo will be the candidate's first honest look at the actual product for many people, outside of marketing materials and conversations.

6.2 Past work presentation

After the product demo, the candidate goes straight into a 60-minute review of portfolio work. A panel of cross-functional peers at the company will attend the presentation, including an engineer or engineering manager, a product manager, and two to three design team members.

The past work presentation, or portfolio review, is time for the candidate to present two or three projects they feel demonstrate their work best. Presentations should highlight the core competencies as well as highlight the strengths and weaknesses of the candidate.

The candidate should make a formal presentation for this stage of the process and plan to present for 45 minutes, making space for 15 minutes of questions from and to the interview panel.

6.3 Design exercise

After the past work presentation, the candidate will move on to a 60-minute exercise.

I’ve written more in-depth details about design exercises here.

In the design exercise part of our onsite interview, the candidate will work through a made-up design problem to work toward a solution. The goal of the design exercise is not to solve the problem presented. The candidate should demonstrate how they might work toward a solution in collaboration with a partner (the interviewer), and that's it.

Candidates are encouraged to use a virtual whiteboard or sheet of paper as they work through the problem. The interviewer's role in the design exercise is not to solve the problem for the candidate, nor is it to serve as a moderator or strict evaluator. Instead, the interview is there to help the candidate stay on track and make progress in the allotted time. The interviewer can ask questions or chime in with their ideas and feedback as the exercise progresses. The interviewer is a collaborator for this exercise, not just an interviewer.

What we look for from the design exercise:

• The candidate's ambition and process for approaching and tackling an ambiguous problem. Do they dive right into solving the problem or hesitate? Are they optimistic about coming to the problem? Do they have energy surrounding the process of solving it? Or do they start paralyzed with indecision or doubt?
• Collaboration: does the candidate engage the interviewer as a partner in ideation and feedback? Do they employ the interviewer with questions, prompts, and ideas? Do they solicit feedback actively at each step of the process? Do they ask for clarity, or do they specifically act as though they need coaching to progress?
• Design process (if you need help here, refer to this guide by Discover Design): does the candidate start by identifying the problem that needs to be solved, or do they jump immediately to solutions? Do they speak to or document open questions? Are they transparent in their intentionality as they move through decisions? Do they try to innovate and push boundaries or go toward the most straightforward solution?
• Time management and prioritization, is the candidate able to manage their time and prioritize their work? Do they make progress in the exercise or dilly-dally in any specific step?

6.4 Lunch or other breaks

At Gem, we always like to include a mid-day break in the formal part of our interview process. A good break is typically lunch or a light snack, anything where the candidate can sit down with a few company members outside the interview panel.

These casual conversations over lunch allow the candidate to know more about the company and team while also giving them a break from doing most of the talking. Ensure every candidate has a lunch break or multiple breaks scattered across the day if they participate in an onsite interview.

6.5 Design critique

The last part of the onsite interview is a design critique.

Critique is a 30-minute product discussion, where the candidate is presented with a mobile or desktop application (always the same app) to review with an interviewer. The interviewer is typically a member of the design team, though a member of the product management or engineering team could also fill in.

The critique is another type of casual conversation wherein the candidate and interviewer talk about the design of the presented app.

Interviewers should engage the candidate by asking what they like and don't like about the product. Let them know it's an open discussion with no right or wrong answers.

What we look for from the design critique:

• Levels of thought: how does the candidate think about the product at-a-glance? What do they speak to, user experience, visual design, brand presence, usability, marketing? Are they passionate about one element of design more than others?
• Does the candidate speak about how the product might benefit others? Or do they talk exclusively in terms of their preferences? Do they say things like: "I could see how this would be helpful for someone…" or "This might be designed for people who..."?
• Does the candidate speak about visual design in terms of consistency, hierarchy, weight, balance, contrast, legibility, accessibility?
• Does the candidate understand what problems the product is trying to solve?
• Does the candidate understand how product decisions might impact a business?
• Is the candidate aware of their intrinsic biases and assumptions during the critique process?

‍

Designers need to invest just as much time in getting to know their teammates and cross-functional peers as they do getting to know their customers.

To be productive on a team, you need strong relationships with those you work with every day. After all, the point of being on a team is to work together. You work together to fill in one another's knowledge and skill gaps and develop solid products and individuals. It's hard to work together when you are doing so based on assumptions of how others like to do their job, their expectations for the work, and how you communicate.

You don't need to become best friends with your teammates to work effectively with them, but you need to know:

• What motivates your teammates?
• How do they measure their success?
• How does your job make theirs easier (or more challenging)?
• How do they like to work together?
• What is their day-to-day "journey"?

Today the design industry regularly praises the importance of working with users in mind and the value of focusing on the user experience of what you design .

Focusing on users and their experience is undoubtedly vital to the success of what you design. Still, less talked about and often equally important as the end-user is the experience teammates have working with you.

Why don't designers invest in their team more often?

Humans are complicated. We each come into situations with life-long perspectives of how things work, what we're responsible for, how we contribute, and what we expect from others. No two people approach the same situation with the same perspective.

So when it comes to working with other people, the most significant barrier to overcome is the false belief that our work and contributions are the same as how others see them.

Everything you learn in school, in previous jobs, or from other relationships in your life informs how you collaborate with your teams at work. Therefore, you assume that you already know how to work well with others and don't need to invest any more time than the occasional one-on-one to do it.

You fail to invest the same research approaches you take with customers to that of your collaborators. Even if you realize the value peers play in your job, you might ignore the work required to understand their perspective of how things should get done.

As a result of your assumptions on how work gets done, you don't want to expose yourself to uncomfortable situations around how you work. You shy away from constructive feedback about how you do or do not communicate. You don't want to feel guilty for not prioritizing more time with your peers than you spend on customers.

Each of these concerns is valid and highlights why it's so important to spend just as much time talking with your teammates as customers: you don't know what you don't know. That's true for both things you design and the processes you use to create them. How can you do your best work if you are operating on limited assumptions? You can't, so you need to spend time on research and explorations.

It's not just the manager's job to build strong working relationships. It's everyones.

Managers often serve teams by helping to unblock obstacles, provide guidance and support, and ensure the quality of the team's output can fulfill customer and business needs.

Often your manager is responsible for bridging gaps between cross-functional groups and working with other managers to ensure you and your team are supported and doing quality work. There are times when managers need to step in and help with interpersonal or team-wide problems too.

Unfortunately, the more time a manager spends resolving conflicts and negotiating things like prioritization or goals, the more you and your team's foundations and maturity erode. Think of manager intervention like a parent resolving a problem on the playground: everyone might walk away content, but the children themselves won't learn how to resolve conflicts.

As a growing designer, you need to find ways to manage cross-functional and stakeholder relationships yourself. Scheduling quarterly check-ins or one-on-ones to discuss prioritization, processes, and any roadblocks is an excellent place to start. Conducting research "studies" with other teammates in and outside of your team is a good exercise as well, where you can get your teammates to share feedback on the work and design decisions directly as if they were a user of the final product themselves.

Designers are often experts at talking with customers, evaluating their feedback, and letting that feedback inform design decisions and product direction. But unless you take that same approach to understand your work to your teammates, too, odds are you aren't doing the best job you could be.

Ensure you prioritize your work in ways that fulfill not only customer demands but also team ones. Find ways to dig into your teammates' modes of operating, their perspective of your work, how they like to work, and how they measure success.

‍

Designers can avoid wasting time and deliver their work more effectively by:

• Focusing on the audience's needs
• Speaking to specific details of the work
• Spending more time listening than presenting

Easier said than done. There's considerable knowledge in designing something, and a designer develops awareness of the customer, business, constraints, potential solutions, and tradeoffs through diligent exploration and experimentation. The work is often time-consuming and exhausting as a result.

It can be tempting to share all the knowledge related to a design when presenting to an audience. The problem is you can only say so much in a meeting or Slack thread. Nobody will look through every document, conversation thread, and past explorations to make an informed decision about a design. It's up to the designer to present the work to convey the most important information for the audience, the customer, and themselves.

Learning to better present designs will make your life easier by getting critical feedback or support quickly and succinctly. The lives of your team and your customers will be made more convenient, too, as a result.

1. Focus on the audience's needs

Before presenting work, ask yourself: what does the audience need to know? What will they do with the information I give them?

Without focusing on the audience's needs, design presentations can be a disastrous scenario. The designer wants to educate the audience on every bit of context relevant to their work, so they present as much as they can cram into the allotted time. The lengthy and complicated presentation or messaging causes the audience to lose interest and attention. The designer is left with a mess of notes to make sense of as feedback is unfocused and scattered around both the designer's process and outcomes.

Not only does focusing your presentation on all the work itself lose audience concentration, but it also takes up much of the audience's valuable time. There's a better way to present, and it's as simple as focusing on the bare minimum information the audience needs to know.

Start by asking yourself what will the audience need to do with the designs you're sharing. Will they need to decide on what to adjust for the project to meet its deadline? Is their job to provide approval or feedback? What type of feedback will they need to provide specifically? Are you providing a status update or convincing the team of a direction?

Rather than presenting every possible detail of the work, emphasizing what the audience needs to know and what they will need to do as a result of that information will tell you what to focus on when you present.

If there were only one takeaway you'd want your audience to get from your presentation, what would it be? If there was only one thing the audience could give you to help improve your work, what would it be? Focus on that.

2. Speak to specifics, not generalizations

Start any presentation or conversation related to your work by being explicitly clear about what's being shown and what specific parts of the work the audience should pay attention to.

When designers only rely on the visuals of what they're sharing to communicate a point, it can confuse the audience.

As a visual medium, it's intuitive to show work and let it speak for itself, but when it comes to presenting work to an internal team, you have to help the audience focus on the right things using the right lens or perspective.

Showing a great-looking design or animated prototype and hoping they convey meaning effectively only leads to different people noticing different details. This broad approach of looking at the work can be constructive for uncovering concerns early in a project, but it's unlikely to get you as a designer focused, constructive feedback for the next steps.

Instead of showing work and speaking broadly about it, tell people exactly what they're looking at on the screen and where to focus their attention for analysis. It may sound counter-intuitive when the audience can look at the work for themselves, but immediately speaking about what's on-screen adds clarity and help everyone focus on the same elements.

To focus on the critical parts of the work, add clarity by explicitly calling attention to the design parts that matter most for the conversation. Sideline anything else by reminding people of what you're showing and why it matters for the meeting or chat thread.

An example of how speaking to the visuals of your presentation might sound: “Here is a concept of our new reporting page. You're seeing six charts in a grid pattern on the screen, each diagram representing data in a concise way. I need feedback on how I can help customers discover the option to modify each chart type without exposing an additional control overlaid on each grid element.”

3. Listen more than you speak

Ensure that when you present design work you are making more time to actively listen and engage the audience than you are on talking yourself.

Presenting work is more about the audience than the presenter — or even the work itself.

Often the point of sharing design work is to get feedback, set expectations, or get approval in some form. If you present work in a way where the audience doesn't have a chance to ask questions, clarify their interpretation or connect the design to other priorities, you ruin the point of sharing in the first place.

Additionally, when designers present work, they often do so with a foundation of assumptions about what the audience already knows and what they care about related to the design. If you aren't giving the audience a chance to clarify their knowledge and needs, you're missing out on an opportunity to ensure the conversation is productive for everyone involved.

Ensuring at least 75% of the time you're presenting designs is set aside for conversation, led by questions or ideas from the audience, means you're much more likely to have a constructive discussion.

A 30-minute presentation might have an agenda with 10 minutes to show the work and provide context to guide the conversation, and 20 minutes is for the audience to ask questions and get clarification or share feedback. What happens if the audience doesn't have questions or feedback in those 20 minutes? Congratulations: you just saved your team 20 minutes each and have done a good enough job to continue with your designs.

Presenting work can be stressful and intimidating, particularly for work in the latter stages of design. If you present work with a clear focus on what the audience will need to do with the shared information, with a shared focus on specific aspects of the work, and by allocating more time for listening and conversation than talking, the work and the team benefits.

‍