Forge learning experience

Challenge

How might we support developers onboarding to Forge, who are not familiar with cloud technology?

From research, we revealed our users are still not yet familiar with cloud technology as they were long time desktop app developers mastered at .Net, C# or C++ languages. They were in the position to see the opportunities with Forge (before their competitors do), figure out the processes, and hire developers who can support their jobs. We need to support our users to get onboarded to Forge quicker, easier.

Solution

1. Help users understand our product offerings and imagine what they can create using our products

API cover page and guideline

One of the pain points users told us was that everything is too heavy - currently all information were parked under ‘API documentation’, more than 50 page long technical documents. When they are still ‘exploring’ the options to consider, they just need the light weight, high level information on what kinds of features we offer to them.

API cover page is designed to support users need on high level understanding, includes a value proposition of the API, video if the API has introductory marketing or learning video, and at minimum illustration of how the API works.   

Code sample crawler page and guideline

At the discovery phase, users are also looking at ‘example apps using APIs’.

We do have many examples but there are no easy way to find them. I created a crawler page of curated examples in git.autodesk.com. Set up a standard and guideline for title and description, and mandated all examples include final app screenshot so that users can understand what is the sample is about.

2. Help users jumpstart trying Forge APIs

Getting started

Users told us that we are lacking tutorials. But we do have tutorials in documentations (although not extensive enough, we have some.). What’s wrong with tutorials on documentation?

From our research, users show ‘love and hate relationship ‘ with documentation. When they are in building mode - using Forge APIs to build the solution, they need to thoroughly read through documentation, be mastered at. But at trial, they want quick win - showing on documentation format immediately gives them the impression - this is overwhelming.

I proposed one page design that looks sufficiently different from technical documentation. The experience will be starting off with SDK: so users will install SDK first, then slice the main flow of the SDKs and explain what those are one by one, try to keep the main flow less than 5 so that users won’t feel too overwhelmed. For the first launch, we use one internal API as a pilot.

Behind the scene: Make the contents as part of the process 

As a platform team, we are not creating the content. To make sure the content be created by the teams, I created templates and guidelines and made it as part of the API onboarding process - To make an API to expose in a Forge portal, there are security, code quality requirements to pass. We added UX and content requirements and communicated templates and guidelines, set up onboarding - review sessions to make sure we manage the quality of the content. It required a couple of sessions as some of the teams are not clear about what is the ‘end user benefit’ of using the APIs.