DevRel Scribbles
  • What are Scribbles?
  • Index
  • Developer Advocacy
  • Developer Advocates
  • Life as a developer advocate
  • Modernising Red Hat’s enterprise developer program
  • Engaging 9-year-old software developers
  • Making 22-year-olds love 26-year-old software
  • Dogfooding developer products: gathering insights from internal hackathons
  • How far does your ethical responsibility stretch for the tech your devs create?
  • Outside the lecture theatre
  • How do you design programs for diversity?
  • Build the Platform Your Developers Actually Want
  • Measuring dev rel programs far beyond marketing activities
  • Developer Evangelism
    • Developer Evangelists
    • How to rock a technical keynote
    • The Art of Slide Design
    • The Art of Talk Design
    • The Art of Story Design
    • Dev events beyond 2021
  • Developer Experience
    • The Power of Content
    • Building a Developer Community in an Enterprise World
    • How to lose a dev in three ways
    • Developer relations, why is it needed?
    • The hierarchy of developer needs
    • GitHub is your documentation landing page
    • Docs as engineering
    • Commit messages vs. release notes
    • A11y pal(ly)- crafting universally good docs
    • Inspiring and empowering users to become great writers, and why that’s important
    • Solving internal technical documentation at Spotify
  • Community Management
    • Building community flywheels
    • DevRel = Community Management?
    • Creating high-quality communities
    • How to grow a healthy Open-Source community?
    • Managing communities at scale
    • Using community to drive growth
    • Useful community success metrics
    • Communities aren't funnels
    • How to mobilise your community during a pandemic
  • Managing a DevRel Team
    • Developer Relations + Product
    • Distributed developer relations
    • Understanding company goals
    • DevRel Qualified Leads (DQL)
    • Path to success for DevRel
    • How to move up in your organization
    • Four pillars of DevRel
    • Building your DevRel dream team
    • Managing the burnout burn-down
    • I messed up and I’m going to get fired
    • How to report on community relationships without being creepy about it
    • How to scale a developer relations team
  • Misc
    • Is developer relations right for you?
    • Tooling your way to a great DevRel Team
    • Planning your DevRel career
    • Success metrics as narratives
    • Get executive buy-in or else
    • Introduction to the AAARRRP devrel strategy framework
    • Strategy for developer outreach
    • Connecting dev rel and product
    • Performance DevRel
    • Ultimate cheat codes for healthier travel
Powered by GitBook
On this page
  • Summary:
  • Scribble:
  • 5 Phases of Design thinking
  • Empathise
  • Define
  • Ideate
  • Prototyping
  • Testing

Was this helpful?

Export as PDF
  1. Developer Evangelism

The Art of Talk Design

Drawing on her extensive experience of conference speaking, Mel shared insights that are a must-see for anyone working in developer relations.

PreviousThe Art of Slide DesignNextThe Art of Story Design

Last updated 3 years ago

Was this helpful?

Summary:

  • 5 Phases of Design thinking

    • Empathise

    • Define

    • Ideate

    • Prototype

    • Test

  • Empathise

    • Understand who our users are and what our user needs are.

  • Define

    • Observations that we’ve made so far and defining core issues

  • Ideate

    • Generating as many ideas as possible.

  • Prototype

    • Creating a scaled-down version of the end products.

  • Test

    • Getting deliberate feedback about your product and then making sure that you ask the right questions

Scribble:

  • Designing an effective talk, it’s the same process as designing an effective product.

  • Company launches a product after doing the research of figuring out whether it’s a product that people want, yet, it’s something that happens all the time in our talks.

  • Apply design thinking when creating a new talk?

    • Design thinking is a way of thinking deliberately about what you’re creating and constantly reacting and reflecting on that.‌

5 Phases of Design thinking

  • Empathise

  • Define

  • Ideate

  • Prototype

  • Test

Empathise

  • When building a product, we first try to understand who our users are and what our user needs are.

  • It’s all about doing the research beforehand

  • Researching our users, who will be listening to it, who is the target audience?

Audience

  • Know about the events, the organizers and most importantly, the attendees.

  • What the background is, what prior knowledge they already might have.

  • Figure out what other speakers there are and also what they are talking about because that also influences people’s prior knowledge.

Format

  • Understand what the logistical constraints are.

    • How long is your time slot?

    • What time will you be speaking at?

    • What type of stage are you speaking on?

    • Whether you’ll have access to Wi-Fi or audio?

Topic

  • Write down what you already know about the content of your talk.

    • What’s the title, the abstract, the key takeaways?

Define

  • Analyze all the observations that we’ve made so far and define what our core issues are.

  • So what are the problems that we’re trying to address with this new product?

    • it will always be about convincing the audience of whatever message you’re trying to get across but the angle of that message can be quite different.

    • It might be about teaching a new skill, it might be to convince people to use a specific product,

    • it might be to inspire or motivate or frighten people to do or change something.

Think, Feel and Do

  • Filling up columns of as many ideas as possible with the following questions.

  • Think

    • What do you want your audience thinking about?

    • What mindset do you want to change?

    • What will the audience learn’

  • Feel

    • How do you want the audience to feel?

    • Inspired, motivated, scared?

  • Do

    • What actions do you want the audience to take?

    • What should they do after the talk?

Ideate

  • About generating as many ideas as possible and then limiting and choosing.

  • Diverge

    • Try to generate as many ideas as possible while keeping the goals and the audience outcomes in the back of your mind.

    • Write down all the possible ideas that will help achieve those goals and those outcomes.

  • Converge

    • Distilling all that information into something more usable.

    • Three techniques - prioritize, filter and cluster.

    • Prioritize

      • Putting the ideas that you have in order of importance, highlighting which ideas are the most important ones.

      • Makes it easier to see which ones you might need to drop if you need to.

    • Filtering

      • Dropping off the talk, so which ones just don’t fit in, or things that aren’t as important as the rest, or that you know that you won’t get around to.

    • Clustering

      • Which ideas go naturally together?

      • Can help you identify maybe the three topics that you can cover in a 20-minute talk and maybe you can know from…you can find out from it which topics you might need to ask for a 50-minute talk.

Prototyping

  • Creating a scaled-down version of the end products, which you can then put in front of users and test with.

  • It’s about creating the bare minimum that will get you useful and valuable feedback without really wasting too much time.

  • Prototype your talk structure.‌

    • Before even creating any slides-- Create an outline first.

  • Beginning, middle, and end.

    • Beginning

      • Start of the talk will be in that “what is” phase.

      • The Hook

        • Grad their attention.

      • The Goal

        • Convince them why they should listen.

    • Middle

      • Everything in b/w “what is” and “what could be”.

      • The Main Ideas & Journey

        • Focus on what will bring the audience close to your goal.

    • End

      • “What could be” phase.

      • The Summary

        • Recap the main ideas

      • The Kick

        • Give them something to remember

Testing

  • The testing phase is all about getting deliberate feedback about your product and then making sure that you ask the right questions to get that feedback.

  • Prepare your feedback givers.

  • Prepare actual feedback questions.

    • What areas do you want feedback on?

    • Is it about the timing of your talk, specific sections that you don’t feel are quite right?

“Good presentations, good blog posts, good documentation, they’re all about understanding your audience and building the right message for them.”

Video