Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

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
6 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

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.

Image4

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.

Image4

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 

Image4

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.

Tweet
Share
Post
Share
Email
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

AI is reshaping the role of designers, shifting them from creators to curators. This article explores how AI tools are changing design workflows, allowing designers to focus more on strategy and user experience. Discover how this shift is revolutionizing the design process and the future of creative work.

Article by Andy Budd
The Future of Design: How AI Is Shifting Designers from Makers to Curators
  • This article examines how AI is transforming the role of designers, shifting them from creators to curators.
  • It explores how AI tools are enhancing design processes by automating routine tasks, allowing designers to focus on strategic decision-making and curating user experiences.
  • The piece highlights the growing importance of creativity in managing AI-driven systems and fostering collaboration across teams, ultimately reshaping the future of design work.
Share:The Future of Design: How AI Is Shifting Designers from Makers to Curators
5 min read

Join the UX Magazine community!

Stay informed with exclusive content on the intersection of UX, AI agents, and agentic automation—essential reading for future-focused professionals.

Hello!

You're officially a member of the UX Magazine Community.
We're excited to have you with us!

Got it!

Thank you!

To begin viewing member content, please verify your email.

Tell us about you. Enroll in the course.

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