Designing for the Platform — Developer Experience

There is a simple mantra to keep in mind here

This is the flow for any developer who you are trying to attract. The design here needs to make sure to nail each of these elements of the mantra. If you do it well, they will stick around, experience this flow and come back for more. If you don’t, they will leave as soon as they get the least bit distracted.

What this means is not only do you need to make sure you fully complete that element of the flow and nourish them with your design…you need to keep them interested. Engaged. Excited.

Let’s look at each part, first Discover.

Here you need to accomplish a couple of things. First you need to do a great job in designing your developer experience so that it is easy to discover. Search Engine Optimization (SEO) is one of your friends here, and the good news is there are a lot of resources to educate you and help you in this. But it’s not the only way you get them to discover you.

You and all of your cohorts should establish social media presence, Twitter, Facebook, LinkedIn certainly — other places as well, like Medium can’t hurt either. You need to get the word out, and you can use this avenue to do more than just get attention, you can teach them here too…this part of Discovery can actually cross over to Learn, Play or Build as well. When it comes to using this tool, providing regular, reliable and valuable information will build you a following. And yea, there are a lot of good resources out there to teach you how to build a social media following, so use them.

Discover also is where you can do things like presentations, conferences and other events to network and get the word out. There are organizations that will help you here too, for developers, you may need to volunteer some time and ideas — but this will build interest and drive folks to discover your Developer Experience.

Having some money to do things like advertise can lead to more uptake as well.

Now if you get them to come you need to do something to get them hooked and as I said above, you need to keep this mentality through out each phase of this experience, keep them interested. In the discover part it means two things. Get them to understand what is valuable about your platform, you need to do this in less time that a 30 second commercial. You need to attract their interest so they will give you another 30 seconds of their time to stay engaged. And once you’ve done a great job understanding your platform you need to hook them with some interaction that proves to them your platform is valuable and simple too.

Summarizing, in Discover you:

  • Get them to come to your Developer Experience
  • Quickly show them the value of your platform
  • Then hook them by proving quickly through a simple interaction

If you’ve piqued interest they will move over to Learn, now things get a little harder for you. Here you need to give them guidance, build on what they took away from the Discover part and help them to see more. To do this you really need to do what every designer already knows how to do, tell them a story…tell them a bunch of stories. This time you need to design your stories so that they fulfill the needs a developer would bring to your experience, introduce them to your platform in a little more detail, and walk them through how to assemble this all into something cool — and do so in a way that makes them realize they can do this themselves.

The way to think about this part is that it’s a lot like a cook book. You need to give them an intro to the recipe, then give them a story as to why this recipe is valuable, then walk them through the construction and execution of this recipe…and also give them the list of ingredients. For developing code, this means, tell me something I can do, make use of one element or a few (but keep it as simple as you can for some of the earlier guidance, later you can add more complex guidance), then walk them through the choreography of the various API’s (these are the ingredients) and how you use them in a flow to get to the outcome that your story promised from the beginning.

Words work great here, code samples too, video is even better as it’s more easily consumed (initially) and then they can come back to the words and code samples to spend more detailed focus. And the more interactive you can make this where they themselves can touch the code and feel it work — well, you’re giving them a taste of the recipe as they learn it. How cool is that?

Summarizing, in Learn you:

  • create a set of guides
  • use video and words
  • each guide is a story revolving around a start to finish journey
  • make it interactive

Now if they stay engaged, they will start to Play. They may jump into this from within the Discover or Learn phases, because many developers learn through play more than any other way. To support them you need to give them the tools of play — which you should have already started in the prior two phases. Interaction is play. Now in the Discover phase and in the Learn phase, the interaction should be much more guided — spoon fed. You need to give them a way to do much more self directed play — so here you make use of tools. Tools that allow them to explore the API’s, that let them try them out and let them twist, poke, change and break things — so they can learn. One of the great examples of this kind of Developer Experience can be seen on www. w3schools.com, here’s one for getting going with Javascript, https://www.w3schools.com/js/tryit.asp?filename=tryjs_myfirst.

It’s a kind of “safe” play space where you can do whatever you want and break things and try things…they start these with a pre-set set of code that the user can just click to run, but it’s an editor where they can change things and see, feel and experience the success and failure of this. Play leads to understanding, and this way of trial and error, it’s ingrained in every one of us, it’s how humans learn in a deep, satisfying and long lasting way.

Summarizing, in Play you:

  • give them tools so they can Play with your platform
  • give them a start, but let them break things, trial and error is how we learn

Let’s look at the last phase, Build.

Here the developer will transition from playing with the interactive parts of your design, taking the things they’ve learned and also, hopefully a sample or two that you’ve provided and start to build something that aligns with their interest and their particular value. They may be just someone who wants to learn and use your technology, so they’ll take a personal approach to what they build. Or they may be someone looking to make money with your services — either because they have a value they can integrate with your services, or because they can add value above what you’re providing to your users. Their efforts may be very focused on a specific business value outcome or they might just be creating a proof of concept.

Keeping in mind all of these kinds of mind sets, your design challenge here is to get them into building with as little resistance as possible. There are really two elements to provide here, a critical mass of code and techniques so they can copy and paste and get things up and running quickly, seconds if you can manage it. The more framework you provide here to get from nothing to something they’ve built will make this as quick and painless as possible for them.

In addition to getting to a cruising speed fast, you want to enable them to quickly add value — this means providing them enough varied samples, tying those into the kinds of things that you understand will be of value to them. For example, for that developer who has the personal view point and is just learning your services and wants to build something of value for themselves — providing them a working sample that connects to GitHub will likely bring some attention and interest. Here your design challenge is to get enough samples of the right kinds of things to attract the right kinds of developers, and it goes beyond sample code too. Make sure your services work in ways that are complementary to these common kinds of use cases.

If you do a good job with this second aspect, then the developers will invest enough time to get something built and working here. Once you’ve done that, they now will take on a personal ownership of this asset — this will reinforce feelings of loyalty to your services. Making them have a more personal attachment, this is an important transition point for your services and your design.

Summarizing, in Build you:

  • enable developers to build things with as little resistance as possible within a very short time frame
  • provide common use case samples, techniques and guidelines so they can build and start to have a personal attachment to your services