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:
  • Scribbles:
  • Design Thinking Framework
  • Vision
  • Understand
  • Define
  • IDEATE
  • Test
  • Leverage

Was this helpful?

Export as PDF

How do you design programs for diversity?

TechLadies founder, Elisha Tan, describes how to apply design thinking to creating developer programmes in this opening keynote from DevRelCon London 2019.

PreviousOutside the lecture theatreNextBuild the Platform Your Developers Actually Want

Last updated 3 years ago

Was this helpful?

Summary:

  • Design thinking - Programme Design Thinking

  • Vision

  • Understanding

    • Knowing why you are doing something.

    • Understand what problem you are solving

    • What context in which the problem exists.

  • Define

    • Who is the target audience?

  • Ideate

    • Finding the best idea.

  • Test

    • Testing the idea.

  • Leverage

    • How can we maximise benefits?

  • This process helps in becoming a better organizer, and helps to be a better leader then eventually leads to the creation of something meaningful.

Scribbles:

‌

Design Thinking Framework

  • Brings you through to integrate the needs of the users, understand the possibilities of technology, and the requirements of business need to come to a solution that can meet all of that.

  • How can we use this, how can we copy this, and apply it to the programs?

  • Mistakes many people make is to jump straight from ideation straight to execution.

  • Without a very mindful approach to understanding why we are doing this and what problem we are solving, it is very easy to be pulled in a different direction like I was.

Vision

  • Questions to ask …

    • Why are you doing this?

    • What are your goals?

    • What are the desired outcomes?

  • Vision helps with understanding if we’re solving the right problem.

  • DevRels can solve a lot of all the problems - not all problems are the right problems to solve.

  • Having a strong vision sets the foundation, helps set the right direction

  • Understand what sort of metrics will be important for you.

Understand

  • Questions to ask…

    • What is the problem?

    • How are people solving the problem now?

    • Why are the current solutions inadequate?

  • Not everyone learns how to code to become a software engineer. Some of them just want to learn because it’s fun.

    • Some of them want to learn to enhance their current role.

Define

  • It's between the more abstract research and vision with the very tangible execution strategy.

  • Define is understanding who our audience is, what are their hopes and dreams and fears, and how can we reach out to them.

  • Helps in focusing on who exactly I’m helping.

User Persona

  • User Persona is related to your vision and also what problem you’re solving.

‌

IDEATE

  • Questions to ask

    • What are all the possible ideas?

    • Which is the “best” idea?

    • What idea gives you the shortest feedback loop?

  • Find out what is the best idea to pursue given the constraints and the resources you have.

  • Learning is to prioritize ideas before a short feedback loop.

    • A feedback loop is a time taken to plan, execute and learn from that experience.

  • So ideas for a short feedback loop helps you learn more faster.

  • Talk to different people to help me refine the idea.

Test

  • Questions to ask..

    • What is the best way to test this?

    • What are the risks involved?

    • What did you learn?

Testing Methods

  • Feedback from users

  • Run a small event

  • Creating prototype

Leverage

  • Leverage is simply to squeeze any ounce of, in fact, other things that you are already doing.

  • What are some other goals that you can achieve?

  • What are some of the momentum that you can create from the things that you are already doing?

Video