The Community Of Over 578,000

Home ›› Design ›› A New Design-Centered Meeting Framework: Better Capture the Product Design Narrative

A New Design-Centered Meeting Framework: Better Capture the Product Design Narrative

by Chris Hardtman
Share this post on
Share on twitter
Share on linkedin
Share on facebook
Share on reddit
Share on email
Share on print


What does the format convey?

When we were at the office, it was easy to convey the fidelity of the design work using the format and wording of the ask itself. For instance, a product designer may have asked a product manager and an engineer to pop by her desk to review some work-in-progress. Not only was the Figma wireframe clearly a work-in-progress, but the environment (casually stopping by someone’s desk to look over their shoulder) also conveyed this message.

Fast forward well into remote-only world and a casual work-in-progress convo could easily get confused with a higher-fidelity demo (where there is less time to integrate feedback) because we are now using the same format for both informal and formal meeting-types, Zoom. We noticed that even if we stated the agenda in the meeting invitation, we received feedback from teammates who they felt like they were being brought too late into the design process and weren’t sure of their role or the kind of feedback expected. What went wrong?

Create clarity

How do we clearly communicate the product design narrative? How do we let the broader product development team know where we are? The product design narrative includes every step of the design process: discovery, research, product strategy, direction, frameworks, tactics, and most importantly, conclusions (what did we solve for? why?). A lot of the conclusions or solutions part of the narrative is represented in Figma or in Storybook (the Radial design system library) or in Slack threads. How do we better document this narrative in one place? Is one-stop communication even feasible?

The product design narrative includes every step of the design process: discovery, research, product strategy, direction, frameworks, tactics, and most importantly, conclusions (what did we solve for? why?).

Map it out

Where were we having conversations? Where were decisions being made? Who needs to weigh in? If we have the same kinds of meetings, can we create some shape or clear structure around this? Without removing the creative (conversation) aspect?

After bringing up the topic with the design team, one person surfaced Figma’s meeting framework. We liked how this provided some definition to the type of design meetings but didn’t handcuff the team to a particular process. We too wanted to create something malleable as design is about exploration. The Figma model was great inspiration.

In October of 2020, we ran a design team workshop using Miro and Zoom to determine how we communicated, why, with whom, roles, responsibilities and pain points. We framed it as “An open-ended dialogue and workshop on design team responsibilities, communication, tools and process connectivity.”

We started with some free-form post-it dropping. Which started to take shape when we themed the notes, and then noticed that we could sequence the themes or major needs in an order that aligned with the design team process. Notice that we were able to put shape around the pain points (on salmon-colored stickies) and sequence things in an organic fashion.


We were then able to map out the types of design conversations we were having, again with pain points (on salmon-colored stickies). I’m purposely not showing the detail but the visual is good context because you’ll see how much structure we dissect from this later.

The key elements we were able to parse out from this step were:

  1. Discussion format
  2. Participants (who and why)
  3. Input types desired
  4. Expected outcomes
  5. Timing (when to run the meeting during our process)

Which provided a holistic view of design-related conversational inputs.


Pro design leader tip: Keep these design-related conversations very open-ended or risk losing the chance to capture ideas from your team . Beware of narrowing scope too early! Designers need room to explore, test, see and then re-check themselves to arrive at a collaborative solution.

The new design meeting framework

We took the team’s knowledge share and synthesized the insights into a framework. One that brought together the 5 key elements (format, participants, inputs, outcomes, timing) from the last step. When would we run a pair design vs a check-in vs a review?

We begin the design conversation with a Kick Off to discuss a project vision and get early alignment with other disciplines. This could also be the pre-work to product discovery. From there, we typically run Pair Design sessions to ideate with a small group where we create visual artifacts or discuss data and research. Check-ins are informal and a space to discuss work in progress and keep everyone in the loop. Reviews are done with design management to ensure that the work is aligning with product and design strategies. The key difference between Check-in and Review is that the Review is where the design head provides detailed design direction, normally in a group setting so everyone can benefit from the feedback.

This meeting framework was then shared with the broader digital team. It was helpful to align on expectations, vernacular (check-in vs review), and when these meeting types would pop up during the product design process. This framework is meant to be a guidepost and not something we dictate from project to project. It’s need-based and built for clarity.

One of the biggest benefits to the team and our process has been the ability to capture the product design narrative. This narrative includes the reasons why we made certain decisions, our design direction, how it may have adjusted over time and product descriptions. It is the responsibility of the design team to capture the feedback and outcomes that shape the product design narrative and this framework makes it clearer on when to do that and why.

Our new framework 


The meeting types

Kick-off: Discuss scope of project and initial design approach. Input: Information from other disciplines in order to accurately give design estimates. Why: To create a shared understanding of goals, success criteria, stakeholders, and set roles & responsibilities. When: Beginning of process.

Pair Design: Ideate with small group to gather ideas and synthesize together. Some sketches, inspo or data gathering may be done ahead of time to get convo rolling. Input: Deep, expansive dive on subject. Keep open ended to gather as much info and ideas as possible. Why: Flexible and hands-on meeting required to get early alignment and inputs. When: Very early in design process.

Check-in: Informal conversation to discuss work in progress, show options, get other’s perspectives (e.g. Dev, Product, Content, Marketing) and to keep everyone in the loop. Input: Focused input on artifact type and within scope and theme. Looking for others to provide input from their expertise. Feedback is recorded. Why: To discuss the design work and get feedback in order to move project forward. When: Middle of process.

Review: Design direction and alignment with design management. Small meeting within the design team to discuss work, strategy, output and next steps. Why: To ensure that the work is as expected, meets goals, adheres to design direction and standards. To get feedback and approve work as complete or design done. When: Beginning, middle and/or end of process.

Demo: Formal presentation with scrum, digital, cross-department or external groups to share work. Input: Feedback is welcome and captured (but not integrated) as this meeting occurs late in the product design process. Why: To ensure a shared understanding of what is going to be built. When: Nearing the end of the process.

So what replaced that use-case of people popping by a designer’s desk? The check-in. This can happen asynchronous or synchronously (typically over Zoom) but it is now clear that there is a space to discuss work in progress AND a place where the designer is responsible for capturing feedback, mentioning that feedback in the project Slack channel and showing up at a later point with visuals that reflect team inputs. The goal is to ensure that everyone on the Digital team knows the progress stage of the work, who to go to with questions or suggestions, and where to access the latest visual files or mockups.

One final takeaway from this process and our lived experience working remotely for more than a year: you have to communicate MUCH more often in a remote-only environment. Repeat yourself. Threads disappear in Slack and in email, bookmarks to links you need can get lost. You have to capture that product design narrative and share it with the team. The NYPR design team utilizes radical transparency in everything we do. We ask the team to over-communicate. That can be a burden and you do need to set limits (and time off of Slack) but in a remote-only world, giving your teammates a heads up, note-taking and providing minutes in an open channel, all lend themselves to a more informed and better-aligned team.

post authorChris Hardtman

Chris Hardtman, Product design director, design team manager, mentor and innovator, leading teams to develop scalable, expressive design systems that extend a brand's storytelling reach. As the scaffolding to any great design, Hardtman delights in building positive people relationships. She is currently the Senior Director, Digital Design & UX at New York Public Radio.

Share on twitter
Share on linkedin
Share on facebook
Share on reddit
Share on email
Share on print
Ideas In Brief
  • Understanding what users feel when using the product is the path towards a great user experience.
  • A good starting point is to research who are the users and subsequently map their emotions at different stages of using the product.
  • Once users emotional background is figured out, it’s easier to frame problems, prevent negative emotions and build a greater user experience.

Read the full article to learn about designing great interactions that suit human emotions.

Related Articles

The Liminal Space Between Meaning and Emotion
  • To innovate well is to search for meaning behind the innovation first. This requires investing time into discovering what users need and think of unique ways to serve them and better solve their problems.
  • Emotions are widely misunderstood in UX design and often manipulation is used to predict user behavior. However, a much better approach to UX design is storyscaping, which aims at empowering users, rather than controlling them.

Read the full article to learn more about liminal space and how to apply this thinking to your design.

Share:The Liminal Space Between Meaning and Emotion

Stop frustrating your users. Invest in notification strategy instead.

The UX of Notifications | How to Master the Art of Interrupting
  • As part of UX, notifications are key to leading the user to a better interaction with the product. Therefore, notification strategy should have a central role in UX design.
  • A good starting point is to create a user’s journey map and identify major pain points. This should serve to understand when and where notifications might be of help, rather than create confusion.
  • It’s a good practice to use a variety of notifications and provide the user with opt-outs so they don’t feel overwhelmed.
Share:The UX of Notifications | How to Master the Art of Interrupting

Clear processes for secondary research are rare. Some ideas on how to improve the way designers collect and document existing knowledge.

UX Case Study: Encouraging Secondary Research in Design
  • Teisanu Tudor started an exploration of around 47 designers, managers, and researchers in order to figure out how they could enrich secondary research.
  • There are a few designers author talked to who run exploratory research studies before sketching out any ideas.
  • Before diving into visual work, there are plenty of sources that could (and should) provide crucial insights for building a foundation.
  • Equipped with feedback from that 47 people, Teisanu Tudor explores the idea of designing a refined aggregator to help product designers obtain a diverse and comprehensive range of data while conducting the secondary research.
Share:UX Case Study: Encouraging Secondary Research in Design

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and