Designing a developer portal experience
In designing a developer experience, you have to consider the lifecycle of the app or connector or what-have-you from installation to update to uninstallation to retirement. You need to think about how they’ll build, publish, update, monetize, and decommission their apps or other marketplace offerings. And to get them building, you’ll need to engage them. How? You’ll need content and training to show them how easy it is to build something cool with your product. They’ll also want some social proof that they’re not the only ones building for you — they’ll want to connect and ideate with other developers — which means you’ll need to build a community.
Engage developers with a dev portal
How will you initially engage those developers to use their own time and resources to build apps that will extend or enhance your product. How will you keep them interested? You’ll need to provide training to help them get up to speed quickly and videos to help them understand why they should build apps for your product. In short, what’s in it for them? How can they monetize their app or connector? How can they manage their item’s lifecycle? Where will they sell their new creation? And that leads us to the marketplace or app store.
Keep them engaged with a community
At the minimum, they’ll expect an online community, ideally with gamification and leaderboards for participation and expertise. As your brand grows, you should invest in in-person events for them, from workshops to social functions, which will further build your brand awareness and strengthen your market share. The most engaged developers will act as connectors and help build your brand, so treat them like valued members of your team, because they are!
Marketplace or app store
As of this writing, the most popular app stores are Google Play, Apple App Store, and Windows Store. Other popular ones are Amazon Appstore and AWS Marketplace. The name varies depending on the content — some have just apps; others have apps, connectors, components, extensions, etc.
You also need to decide what type of content you’re going to include. Is it apps and extensions and connectors only? Does it include events, reports, training? Will there be free trials? Will any apps be available for free?
So, without further ado, let’s look at the use cases across the entire developer experience of dev portal and marketplace.
Developer experience use cases
Provide a single sign-on experience across the website and console. The website is where you first engage your developers with what you offer. The console/portal is where your developers will either build or upload the things that they build somewhere else. This could be APIs, connectors, apps, etc. The console will have to be easy for a first-time user to get started. They should also be able to either flip back to the website or be able to access any training in the console itself. Providing an intuitive way to navigate between the dev website and console will make it so that you don’t have to store everything in two places.
Here’s an example IA diagram for how this could work.
Sign up
We’ll be moving across multiple areas for the developer experience but there will be a single sign-on experience. Ideally, you’ll ask for the minimum information from them at first. Just email and password and maybe their name. We know that your marketing team wants way more, but it’s not worth the risk of losing them before they even start. Wait until they’re more invested in your portal before you ask for more identifying information.
Sign in
After they’ve validated their email either by clicking a validation link in the email you send, or by entering a code that you send by email or SMS, they should be on your sign in page. If they haven’t created their password during the initial sign up process, this is where they’ll need to do it. Have a create password and confirm password field, make sure there are toggle eyes to let them see what they’re typing. Anyone can fat-finger, especially on mobile. I hate Captcha because it degrades and slows the user experience without adding much value, but if decide you must have it, here’s where you put it.
Free trial
Gone are the days of monolithic software applications (or almost gone). In their place, people expect monthly or annual subscriptions. And they’ll want to try before they buy. If you won’t let them, be assured your competitors will. No more waving your hands and demoing smoke and mirrors nowadays before the contract is signed. And no major impact on them for switching to your competitor, either. Usually, a free trial is 30 days. You’ll have to decide whether you want it to be a full trial or a limited feature trial.
Add to wishlist / Save for later
If you have a lot of content on your dev portal or a lot of items in your marketplace, people will want to save it to watch or purchase later. You’ll need to have a visible place for them to find these items. You could even send them periodic notifications in-app of these items, as well as adding it to their account preferences.
Set up account
An account will at the minimum have name and email. If you want to send your users notifications, remember you’ll have to have them opt-in. You can do this during sign up, or you can allow them to customize their notification preferences, such as receiving emails or SMS messages for new and updated items, training or offerings in content categories they select. They should also be able to change their password from the account settings.
Set up billing
First, you’ll have to figure out what payment methods you’ll support. You’ll almost certainly want to support the major credit cards, but will you also support Google Pay, PayPal, etc.? Especially for smaller purchases like apps, these would be good methods to support.
View what’s new and recommendations
Show them new items and recommended items based on their account notification preferences if they’ve set them. If they haven’t, show them items based on what you know about them so far. If they’ve purchased an app in a particular category, show them new items and recommended items for that category. As your recommendation system gets more sophisticated and as their purchase history expands, you can show them recommended items based on what other users like them (who buy the same or similar apps in a particular category, for example).
Browse
Browse and search are the two main use cases you’ve really got to nail down. For both training and marketplace items, you’ll want an image and a title to get people interested in clicking in. for marketplace items, you’ll also want rating (and how many people contributed to that rating). For your main tabs in your marketplace, you’ll want to provide a tab that lists all of your offerings, broken down by different sections, such as Featured, What’s New, Recommended for You, and All. You’ll also want a tab that just shows your categories in visual form. The other tabs you’ll want to include are a place to view purchases and one for viewing and installing updates. Apple’s App Store uses their Purchases tab to not only view your purchase history but also to see the current installation status of each item. As your marketplace becomes more established and you have more users and ratings, you can add a tab for Top Rated.
Search
Don’t just assume that your search engine works — test it. Especially if you’re using a free source search engine like Solr or ElasticSearch. In that case, you’ll need to know about boosting metadata categories, creating a file of synonyms (such as product acronyms and full product names, common misspellings and their proper spellings, and platform/OS names can change based on the company that owns them, so make sure you map between the old and new names), and a lot of manual testing to ensure search accuracy and relevancy.
Once they’ve initially searched via your search box, they’ll need a way to filter down. If there are only a few simple categories and you don’t have to worry about needing to search on multiple items in a category, then you can use drop-downs above your search results. If there are many categories and you have to worry about, for example, searching multiple versions of a product or app, or multiple items in multiple categories simultaneously, you’ll want to have a sidebar dedicated to your search filters. You’ll also ideally allow them to sort based on relevancy, recency, and alphabetically. Here’s more detailed information to test and customize your search experience. Remember, a bad search experience can be worse than no search experience!
View details and dependencies
If you’re offering connectors and extensions, you’ll need to worry about identifying dependencies and ensuring that these dependency versions are compatible with the new item or update your user is trying to install. They’ll need to be able to see more information on the item: image, title, price, current version, any necessary compatibility information, the publisher, a support link for the item, a blurb, screenshots, any training or videos you might have for that item, and of course, a way to either download it to install later or install immediately.
View available updates
As mentioned, these should display on a tab such as Updates (x), where x is the number of updates for their items. You’ll also want a notification bell and badge icon on your global header, next to your user name, with a notification drop-down panel, allowing users to view and act on notifications. Depending on what they set up in their account preferences, you may also need to send them email or even SMS notifications about new and updated items.
Will you allow your users to ignore updates? If so, you’ll need a way to do so, then a place to see those ignored updates later.
I’ve been meaning to come back and add mocks for this, and keep thinking about this and not having time, thus my apologies for the abrupt ending, but I’d rather get these out than continue to let them languish on a shelf, in the hopes that they help someone starting down this very path!