Design for DevRel in 3 Easy Steps

In my last post, Why should DevRel care about Design?, I explained why design is critical to the success of any company that builds products, tools and/or APIs for third party developers. In this post, I’ll tell you my approach and the three steps you can take to seamlessly integrate design into your team’s strategy.

But if your team works as hard as mine does, it’s hard to do more. On my team, we’re extremely passionate about our work. We already spend nights and weekends at developer events, responding to emails, reading up on the latest news and it’s painful to think about trying to add more to our plate. Which is why if you want to incorporate design into your devrel strategy, you need to figure out what complements your team’s priorities, bandwidth, and talents.

How? You say. It’s simple!

Step 1: Learn what’s possible

Step 2: Align with your team’s priorities

Step 3: Measure and share your impact

Step 1: Learn what’s possible

For step 1, to understand the right approach, you should first familiarize yourself with the options. Start by talking to your design teams. What are they working on? Look online and in forums.

Here are a couple of examples:

TIP #1: Two for one. Try merging a technical training with a workshop on design thinking methods and see what ideas attendees come up with.

I’m on a team called the Google Developers Experts program. Each year, I teach the sprint master academy, which is a training program based on the GV google design sprint methodology. Among the attendees were technical consultants, CTOs, and Sr. developers interested in understanding design thinking methods to apply to their product or their client’s products. One of the machine learning GDEs approached me after the training and said he’s been experimenting with a 20 day variation of the design sprint methodology, which is normally run over 5 days, to learn, prototype, test and iterate on new models for his clients.

TIP #2: Go analog. Before an event, try running a sketching or paper prototyping workshop for 30–45 min and help developers think through app navigation and interaction

Another technique is to get developers off the computer to design their product before they start coding. I ran a paper prototyping workshop at Google I/O in 2015 and paired developers with Sr. designers to work through planning their product. One developer came up after his session with a look of frustration and joy explaining he’d spent the past 6 months writing and deleting his code only to find that after a 60 minute session he had a clear picture of what he needed to build and estimated it would take him 6 weeks instead of 6 months.

Developers in the Paper Prototyping Session at Google I/O 2015

Other examples include:

  • Teaching basic user research methods to help developers talk to and learn from their users.
  • Working to build tools that enable better collaboration between designers & developers like the new material components and other tools that turn digital prototypes into code.
  • Publishing rubrics for good design to create a more structured approach when teaching design to anyone new to design, such as the PWA lighthouse score, which highlights site usability metrics that improve the user experience.
  • Incorporating design content at a developer event. I recommend separate speaker tracks for design and technical content with workshops that encourage collaboration or a happy hour that fosters dialog.
Step 2: Align with your team’s priorities

Once you’ve explored some of the formats that have worked for other teams, it’s time to see which one makes the most sense for yours. Start by revisiting your team’s annual goals. If there aren’t any design focused goals, make it your mission to get one added by next year.

As was mentioned at I/O a few weeks ago, our company is putting extra focus on Digital Wellbeing. As product creators we have the responsibility to ensure the wellbeing of our users and design is the tool to help us achieve this goal.

Make it so seamless to integrate design into the existing work that the team barely notices.

But the changes to your everyday execution don’t have to break the mold. Once you’ve reviewed your company objectives and key results (OKRs), talk to the people on your team. What keeps them up at night? What technology or feature of your product are they most passionate about? Cater your approach to your team. Make it so seamless to integrate design into the existing work that the team barely notices.

Step 3: Measure and share your impact

Finally, getting your team to try a new strategy once is the easy part. By measuring both qualitative and quantitative impact, you help ensure your new program isn’t a one-off, but an integral part of your team’s strategy.

Google’s World Usability Day Event Series

In 2017, for the first time Google took part in World Usability Day, which is a public celebration to promote best practices from the professional design community. For us, it took place in 10 countries with over 1,000 hours of content and 72 sessions reaching over 1,300 developers, designers and entrepreneurs.

Some of the topics we emphasized last year were:

  • A solution is only as good as your understanding of the problem, which is at the heart of human centered design
  • How to incorporate the user into the design process.
  • How to effectively conduct usability testing to gain insights.

We’ve just started planning for 2018 and have teams internally reaching out to us to find out how they can get involved.

Being in developer relations means we help developers be successful by helping them create incredible user experiences.

Design shouldn’t be a separate activity and it definitely shouldn’t be an afterthought. It should be integrated into everything you already do with the developer community and remember, it doesn’t have to be hard. And I’ll let you in on a little secret: advocating for design a lot of fun and feels good knowing you’re helping developers be successful and making users happy.

For me, being in developer relations means we help developers be successful by helping them learn about cutting edge technology and create incredible user experiences.

This is Part II in a two-part series about why design education is so critical for a Developer Relations team. For Part I see: Why should DevRel care about Design? This series is based on a talk I recently gave at DevXCon San Francisco. While these insights are geared toward introducing design-strategies to a Developer Relations team, these tips and tricks can also be applied to an internal technical team that suffers from what one might call design-aphobia. Feedback and comments welcome!