Every year we work with Mozilla on the MDN Developer Needs Survey, and then every 3 months we run a survey with a random sample of web developers to understand how they view web development, what works for them and what doesn't.
These surveys give us a decent picture of how the broad challenges that developers face building for the web, and they help us prioritize where we should invest Engineering, Product and Developer Relations support. For example, from both of these Surveys it is clear that Web Compatibility, Testing and Documentation have been major areas of frustration for the developer Ecosystem.
It has been great to see how this impacted our teams direction over the last year or so. Firstly we prioritized Web Compat, and we've seen a number of improvements in Grid and Flexbox across all browsers. We also focused on improving documentation across the web by ensuring that a large number of API's that land first in Chrome have reference documentation on MDN, as well as becoming a founding member of the Open Web Docs collective to provide a neutral space to prioritize the reference docs that developers need the most.
These surveys are good for a general steer of what's happening, we find getting very direct feedback hard be it on specific projects, API proposals, or even our documentation. For example, just one area that I am looking to improve is when a Blink Intent is launched and we say there are "Web Developer Signals", where do this signal actually come from? Is it Twitter? A survey after one of our events? A well-placed contact within the Chrome team? The answer is, probably all of the above. We have previously defined what counts as a developer signal, however there is more we can do.
We do get a lot of great feedback from Twitter and from developers that we interact with 1:1 (you can still book meetings with me if you want), but our process for getting feedback for any of our projects is not very formal nor is it consistent. I've had feedback from many developers that web dev on Twitter don't represent the wider developer community and bias can be introduced there if we use that as our primary source of input.
So how can we make the process of getting actionable developer feedback to our teams?
Introducing the Web Developer Insights Community
We've worked with C SPACE to build a dedicated community of about 1000 web developers from a range backgrounds, experiences, skill sets and industries who will provide us direct feedback to questions that we have about developer needs. The nice thing is that the community is a community, it's not just a place for us to ask questions - there's a lot of talk about many web development topics and challenges already (including Google's lack of ability to do support for some of our products....)
To maintain open communication in the group and reduce the influence a Chrome team member might have as well as the perception you have to keep us happy to be part of the group, we're not allowed to participate in the conversation outside of scheduled times that we will work out with C SPACE - we do get the feedback though, and it goes directly to our engineering teams.
I'm excited to see how this community grows, and I'm looking forward to the feedback that we get directly from everyone involved. If you are interested in joining, we should still have space for you to sign-up, if by the time you read this we don't have here is the quick intro video I made for the community explaining to all the members what we want to do.
About Me: Paul Kinlan
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.