Creating a Style Guide for Meeting Notes

All content has a purpose and an audience. Meeting notes are no exception. And yet meeting notes oftentimes seem to lack both of these. Meetings take place and yet notes gather proverbial dust. When we do look back at notes to get clarification on a decision made it’s often unclear or difficult to find. A great way to add purpose and clarity to meeting notes is by accounting for them in a content style guide.
A content style guide is a list of guidelines and styles to consider when creating content. Having this coherence across meeting notes ensures the notes taken are meaningful and relevant.

Purpose

Everything we create should have a purpose. First determine what is meaningful to record from meetings. Here is a list of questions I ask myself to suss out the purpose to meeting notes and also whether to take notes at all.

  • What information from the meeting needs to be documented?
  • Will information from meeting notes be transferred to other locations and formats?
  • Who needs to access information from meetings and why?

Audience

Knowing our audience informs our style. If the notes are internal only, I can use acronyms and company jargon liberally. For collaborative notes between our company and a client, I am careful to use terms familiar with everyone. If they are public and open to people outside of a project then I will spend more time linking out to relevant documents and providing additional context or definitions when necessary.

Key Content

Not everything in a meeting needs to be recorded. In fact, some meetings won’t need notes at all (which we determine from the above purpose and audience steps). For meetings that do have notes, think about the content that is most important.
At Aten, we decided that for notes from working meetings with our clients we needed to know the following -

  • Date
  • People in attendance
  • Agenda items covered
  • Decisions made
  • Next steps identified (action to take and person responsible)

Depending on the nature of the working meeting this list can expand. For example, during a design exploration meeting with multiple stakeholders we also need to record the opinions people have on different design options. From those opinions we need the following

  • The design element/idea
  • The person stating the opinion
  • The actual opinion (including why they think that way)
  • Examples or counterexamples to support their opinion

For an open source project I’m working on we decided to record the following in our notes intended for the general public -

  • Date
  • People in attendance
  • Updates
  • Decisions made
  • Actions
  • Additional Notes

Style

Now that we know our audience and the key content we need to record, we can define styles that are useful to our audience.
Here’s a sample from our styles for working meetings.
Meeting Titles
Meeting titles use the heading 1 style and follow the format of 6/22/16 - [Meeting Title]
The meeting title is optional, a date oftentimes is enough.
Attendees
Always include the people in attendance at the meeting. This allows people who weren't in the meeting to know who to reach out to if they have questions about the meeting notes.
Suggested format-
Attendees: Brian, Clayton, Erin, John F, Roxy
Include a last name initial if there are multiple people from Aten or the client team with the same name.
Agenda Items
Start the structure of the meeting notes with the agenda items using an unordered list.
Example:

  • Design Review
  • Content Maps Check-in

Nest items that are sub-topics to the main agenda items.
Example:

  • Design Review
    • Homepage Comp
    • Resources Comp
  • Content Maps Check-in
    • Resource Detail Page
    • Blog

Recording Decisions
If a decision is made on an agenda item it should be recorded.
Suggested format -

  • Decision made - [decision on x] by [group/individual making the decision]

Example:

  • Decision made - Homepage comp approved by Client X

Recording Tasks
When someone commits to doing something outside of the meeting, record it for appropriate ticketing in Basecamp, JIRA or any other relevant project management tool.
Suggested format -

  • TO DO - [task name] (Assignee)

Examples:

  • TO DO - Schedule a design handoff for the approved homepage comp with Ken (Erin)
  • TO DO - Create a wireframe for the Resources page (Clayton)

Using consistent language like Decision made- or TO DO makes our meeting notes scannable and easy to retrieve important information.
By documenting what we find useful from meeting notes and the optimal styles to record important information we have meeting notes that are clean, consistent and easy to scan and understand.

Content

Read This Next