A high fidelity mockup as a beginning template for the N-able developer portal. The developer portal was created as a public documentation and code repository for scripts that facilitiate integrations with our products. It’s just one piece of the bigger picture in expanding the capabilities we offer.
Overview
Note: These concepts show early work and take care not to reveal any confidential details of non-public work.
Historically, N-able products offered separate, standalone products that cover different areas (backup, security, remote monitoring and management, endpoint detection and response) for IT service providers to cover their client’s technology support needs. The need has evolved to provide a unified service with feature sets that integrate with other products and services to meet the business needs of our IT service provider clients. Additionally, we have begun offering API access for developers to create scripts for their own integrations, and we want to allow them to share their scripts and build a platform to do so in our marketplace.
Provisioning, contracting and billing for our software-as-a-service products has also been a historically manual process that requires high touch and direct involvement with sales and account managers. Creating a space for self service releases the need for high-touch provisioning, especially for existing clients who already know what they want.
The work shown here details steps that have been made to establish self service flows, streamline the trial and purchase process, and allow third party developers to publish their integrations to our marketplace.
Project details
Self service
The foundation of expanding product adoption was established by offering new pathways for users to learn about what they can accomplish and try things out for themselves, on-demand. This gives users the freedom to inform themselves and decide the path they’d like to take to expand their capabilities with our products.
Below shows some guidance I’ve created to strategize with and align cross-team stakeholders, sharing best practices for introducing new information and developing a space for users to expect to accomplish self-service actions.
Boiling down the user flow for self service along with wireframe examples of the UI that might be used to share with teams outside of UX.
A high fidelity concept of the future Marketplace main page.
Establishing a developer portal
Part of the larger strategy to expand product and feature adoption beyond enabling self service is allowing developer access to our APIs and sharing scripts amongst our technology partners. In collaboration with multiple cross-organization teams, I led the effort to style and structure our public facing developer portal, which creates a hybrid branded space that appears similar to our public facing website, but crosses over with our internal product design as well.
Light mode and dark mode themes were created for API documentation pages.
API integrations + token management
Allowing API integration and access to our data involves token creation and management - and some of my latest work includes determining the UX for accessing token creation and management, and mapping how it is accessed from logged-in, authenticated users - considering the flows and different needs between admin versus individual contributors.
The UI for token management for organization administrators.
Connecting the dots
Determining how all the pieces fit together between business goals and meeting user needs is part of my core day-to-day work. For this project, determining where the marketplace and developer portal fit in along with other N-able web properties and functions (in their current and future states). How are they accessed, who has permission to do what, what is the minimum viable product versus the ideal state, and how can the best experience be accomplished through the backend capabilities we have available? What is the content strategy that guides the experience? Answering all these questions ahead of time through working with engineers, product managers, and marketing leads helps carve out the UX design and strategy and any further research needed.
Ideation - mapping out how marketplace content is accessed in current and future states.
A high fidelity mockup as a beginning template for the N-able developer portal. The developer portal was created as a public documentation and code repository for scripts that facilitiate integrations with our products. It’s just one piece of the bigger picture in expanding the capabilities we offer.
Overview
Note: These concepts show early work and take care not to reveal any confidential details of non-public work.
Historically, N-able products offered separate, standalone products that cover different areas (backup, security, remote monitoring and management, endpoint detection and response) for IT service providers to cover their client’s technology support needs. The need has evolved to provide a unified service with feature sets that integrate with other products and services to meet the business needs of our IT service provider clients. Additionally, we have begun offering API access for developers to create scripts for their own integrations, and we want to allow them to share their scripts and build a platform to do so in our marketplace.
Provisioning, contracting and billing for our software-as-a-service products has also been a historically manual process that requires high touch and direct involvement with sales and account managers. Creating a space for self service releases the need for high-touch provisioning, especially for existing clients who already know what they want.
The work shown here details steps that have been made to establish self service flows, streamline the trial and purchase process, and allow third party developers to publish their integrations to our marketplace.
Project details
Self service
The foundation of expanding product adoption was established by offering new pathways for users to learn about what they can accomplish and try things out for themselves, on-demand. This gives users the freedom to inform themselves and decide the path they’d like to take to expand their capabilities with our products.
Below shows some guidance I’ve created to strategize with and align cross-team stakeholders, sharing best practices for introducing new information and developing a space for users to expect to accomplish self-service actions.
Boiling down the user flow for self service along with wireframe examples of the UI that might be used to share with teams outside of UX.
A high fidelity concept of the future Marketplace main page.
Establishing a developer portal
Part of the larger strategy to expand product and feature adoption beyond enabling self service is allowing developer access to our APIs and sharing scripts amongst our technology partners. In collaboration with multiple cross-organization teams, I led the effort to style and structure our public facing developer portal, which creates a hybrid branded space that appears similar to our public facing website, but crosses over with our internal product design as well.
Light mode and dark mode themes were created for API documentation pages.
API integrations + token management
Allowing API integration and access to our data involves token creation and management - and some of my latest work includes determining the UX for accessing token creation and management, and mapping how it is accessed from logged-in, authenticated users - considering the flows and different needs between admin versus individual contributors.
The UI for token management for organization administrators.
Connecting the dots
Determining how all the pieces fit together between business goals and meeting user needs is part of my core day-to-day work. For this project, determining where the marketplace and developer portal fit in along with other N-able web properties and functions (in their current and future states). How are they accessed, who has permission to do what, what is the minimum viable product versus the ideal state, and how can the best experience be accomplished through the backend capabilities we have available? What is the content strategy that guides the experience? Answering all these questions ahead of time through working with engineers, product managers, and marketing leads helps carve out the UX design and strategy and any further research needed.
Ideation - mapping out how marketplace content is accessed in current and future states.
A high fidelity mockup as a beginning template for the N-able developer portal. It was launched as a public documentation and code repository for scripts that facilitate integrations with our products. It’s just one piece of the bigger picture in expanding the capabilities we offer.
Overview
Historically, N-able products offered separate, standalone products that cover different areas (backup, security, remote monitoring and management, endpoint detection and response) for IT service providers to cover their client’s technology support needs. The need has evolved to provide a unified service with feature sets that integrate with other products and services to meet the business needs of our IT service provider clients. Additionally, we have begun offering API access for developers to create scripts for their own integrations, and we want to allow them to share their scripts and build a platform to do so in our marketplace.
Provisioning, contracting and billing for our software-as-a-service products has also been a historically manual process that requires high touch and direct involvement with sales and account managers. Creating a space for self service releases the need for high-touch provisioning, especially for existing clients who already know what they want.
The work shown here details steps that have been made to establish self service flows, streamline the trial and purchase process, and will eventually lead to allowing third party developers to publish their integrations to our marketplace.
Project details
Self service
The foundation of expanding product adoption was established by offering new pathways for users to learn about what they can accomplish and try things out for themselves, on-demand. This gives users the freedom to inform themselves and decide the path they’d like to take to expand their capabilities with our products.
Below shows some guidance I’ve created to strategize with and align cross-team stakeholders, sharing best practices for introducing new information and developing a space for users to expect to accomplish self-service actions.
Boiling down the user flow for self service along with wireframe examples of the UI that might be used to share with teams outside of UX.
A high fidelity concept of the future Marketplace main page.
Establishing a developer portal
Part of the larger strategy to expand product and feature adoption beyond enabling self service is allowing developer access to our APIs and sharing scripts amongst our technology partners. In collaboration with multiple cross-organization teams, I led the effort to style and structure our public facing developer portal, which creates a hybrid branded space that appears similar to our public facing website, but crosses over with our internal product design as well.
Light mode and dark mode themes were created for API documentation pages.
API integrations + token management
Allowing API integration and access to our data involves token creation and management - and some of my latest work includes determining the UX for accessing token creation and management, and mapping how it is accessed from logged-in, authenticated users - considering the flows and different needs between admin versus individual contributors.
The UI for token management for organization administrators.
Connecting the dots
Determining how all the pieces fit together between business goals and meeting user needs is part of my core day-to-day work. For this project, determining where the marketplace and developer portal fit in along with other N-able web properties and functions (in their current and future states). How are they accessed, who has permission to do what, what is the minimum viable product versus the ideal state, and how can the best experience be accomplished through the backend capabilities we have available? What is the content strategy that guides the experience? Answering all these questions ahead of time through working with engineers, product managers, and marketing leads helps carve out the UX design and strategy and any further research needed.
Ideation - mapping out how marketplace content is accessed in current and future states.