The state of SaaS marketplace UX
source link: https://uxdesign.cc/the-state-of-saas-marketplace-ux-7484ca6cea5
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
What’s the marketplace experience of today?
Let’s have a look at the experience for each user journey phase. Ultimately, we want to learn what kind of experience is expected or must-have, what else might add value, and what might delight users. We’ll use Kano categories (those used in the Kano model framework) to help us organize the findings into those groups.
Journey phases
Stepping into the consumer’s shoes in the SaaS marketplace.
- Entry points: How can I access the marketplace?
- Search and browse: How can I discover what I need?
- Installation: How can I install the app as easily as possible?
- App onboarding: Will I need any help during the first steps?
- App usage: How is the installed app launched, and how is it surfaced?
- App management: How do I manage and configure the app?
Bonus content 🎁
- Naming conventions — a boring, yet useful topic
- Developer experience — a sneak-peek perspective of how it looks for publishers and technical users
Categories and assessment criteria
In the Kano model analysis, you usually aim to enhance your product and service based on customer emotions. For the sake of this exercise, we’ll borrow just the categories to define our common language for this review.
Note: The assessment is not based on a user study like you’d do using the Kano model (surveying users), but it is based on a thorough analysis of the SaaS products in this study. See the criteria for each Kano category below.
The following Kano categories will serve as buckets to define:
- Baseline expectations ✅ — these are must-have qualities. If the product doesn’t have them, it will be considered incomplete or just plain bad. My criteria: Frequent occurrences of certain features or design patterns.
- Linear satisfiers 🌈 — these are one-dimensional qualities. The customer satisfaction is directly proportional to the degree of improvement provided. My criteria: Typically less present in products, they are often differentiators that add value and thus are not essential for the baseline experience.
- Delighters ✨ — these are attractive qualities, with unexpected features, patterns, flows, or behaviors that elicit a positive reaction. My criteria: Delighters are often subjective — in my case, based on my product design taste, experience, and instincts.
1. Entry points to the app offering
Discoverability is always crucial. If users cannot find the features you’ve built — at the right time and in the right context — those features are essentially useless.
Today, users have various ways to discover the app offering, depending on their journey and intent. Are they looking at what’s possible before subscribing? Are they current users looking at ways to streamline their workflow using other tools? Or do they have no real understanding of how their experience could be improved, yet they might get a hint in the right context and at the right time?
Baseline expectations ✅
It’s common to have all apps and integration listings available publicly as well as part of the app.
Slack’s, Examples of in-app entry points to Slack, Figma, and Airtable’s marketplaces.
App-related content is also readily available via search engines, bringing organic traffic to the acquisition funnel. For example, asking Google “Figma app for Slack.”
Delighters ✨
Users using your product focus on the jobs they need to do. We can’t expect them to be thinking, “What app will I add today?” That said, if we invite them to use an app at the right time and in the right context, we bring the experience to another level.
Contextual in-app prompts offer well-thought-through touchpoints that will delight your users, helping them to find what they need without extra effort, often when they didn’t even know it was possible.
An example could be sharing a Miro board via Slack, where Miro adds a contextual prompt to share via Slack, just next to the place where you write a name, email, etc. Not integrated yet? No problem. Simply click to authorize the Slack app, and you are all set to invite others.
Sharing Miro’s board via Slack (after authorization, the list of users is shown).
Onboarding coach marks can be fun — Figma uses fun copy and micro-interactions to grab your attention and pique your curiosity in FigJam.
Fun copy and micro-interaction in FigJam (captured in 2022).
2. Search and browse apps
Helping users to discover what they are looking for is a core job for marketplaces. But to be able to navigate content effectively, you need the right information architecture, meaningful categorization, and tools like search or filters.
Baseline expectations ✅
Meaningful and consistent content and categorization on the web and in-app. What makes the experience a bit different on the web is whether the user is already logged in or not (Install vs. Sign-up, etc.), while in-app it’s always clear who the user is. Using the same content on the web and in-app makes the experience consistent for users while saving time for the business or partners managing their content only once.
Miro’s marketplace layout on the web, shown as a full page, and in-app, presented in a modal form as an overlay.
Featured apps and curated categories are usually chosen to facilitate searching for the most common needs and use cases. For example, Essential Apps to get you started, Daily Tools that are used frequently, or even Enterprise-ready apps to address the specific needs of bigger organizations. A list of featured apps usually forms the content for the marketplace homepage.
Information about the publisher/developer, often including a logo and a disclaimer. For example, “By Zoom”, “By Figma and others”, “Developer: Canva Pty Ltd”, etc. Disclaimers are important to set the right expectations around whether the app was created by a third party or by the platform itself, so users know where to ask for help, etc.
Publisher’s info and disclaimers by the Figma Community, Zoom Marketplace, and Slack App Directory.
Essential app information, usually including its name, a short and long description, key features, a preview (image and/or video), publisher info, links to help articles, pricing info (available on a plan), and general metadata (last updated, etc.).
Linear satisfiers 🌈
Curated app collections focused on specific use cases or known tools. For example, Google Workspace, or Work from home apps by Slack or Miro.
App collections by Slack App Directory and Miro Marketplace.
Advanced app filtering to narrow apps accessible to only admin/everyone, filtering by app type, etc.
Advanced filters in the Zoom Marketplace.
Additional information provided about the app is less common but in certain cases very useful. For example, app version history, compatibility info (e.g. “Works with Zoom meetings,” “Works with FigJam,” etc.), requirements (e.g. “Desktop client version,” “User role,” etc.), and community comments.
App compatibility info by Figma/FigJam Community and Zoom Marketplace.
Comprehensive security and compliance info — dedicated information is appreciated mostly by enterprise customers so they can make educated decisions that meet their internal security standards. For example, Slack went the extra mile by providing very specific details such as “Data archiving and removal policy,” “Data center locations,” “Contact for security issues,” “ISO certification document previews,” etc.
Zendesk’s security and compliance info in the Slack App Directory.
Delighters ✨
Combining a list of features and “getting started” instructions — for example, Slack leverages app descriptions to provide basic help information, so users can get started and find everything in one place. Compare this to an experience where users need to navigate to another site and read through extensive documentation articles.
Loom’s slash commands in the Slack App Directory.
App descriptions are not only about plain copy. They’re about marketing and emotions as well. Look at Miro’s hero image for their Miro for Zoom app. The image conjures up emotions, convincing users to experience Miro’s fun UX even during Zoom calls. The same applies to Asana’s hero image in Figma. Tasks can be fun and part of your design canvas.
Catchy visuals for apps and widgets in Miro and Figma.
Marketplace always at hand — there are various ways to show the app catalog or app detail. A common pattern is to display it in-app as a full page, but that can be cumbersome. Those that use modal windows or floating pop-overs in-app bring a smoother experience, allowing users to access the app catalog in various contexts without navigating far away from their workflow.
Airtable, Figma, and Miro’s approach to making the app offering available in-app.
FigJam’s widget menu, listing recently used ones.
3. Installation of the apps
Installation marks a successful part of the funnel, with users having already explored, considered, and decided what they need. While it doesn’t guarantee they’ll adopt the app, the installation flow may help to set the right context, communicate important information, or most importantly, give the right first impression.
This stage is all about the right level of guidance, context, and most importantly, making it as easy as possible by removing obstacles.
Baseline expectations ✅
Installation starts on the web or directly in-app. An anonymous visitor is usually offered actions to log in/sign up first, whereas logged-in users continue in the installation flow.
Miro’s installation flow for users that aren’t logged in.
Miro’s installation flow for users that are already logged in (regardless of whether you start on the web or in-app).
Contextual installation flows — as the marketplace caters to different users (anonymous visitors, admin, or regular users) via different channels (web/in-app), the experience is usually served contextually. Here are the most common flows:
- Sign-up to install
- Installation is not allowed (e.g. the user must be an admin)
- Follow the manual steps — add the app by following a help article
- Continue installing on the external marketplace
- Upgrade to add — an upsell opportunity
Airtable and Miro show apps even if they are limited by your current plan.
Contextual installation CTAs — each installation flow is different, so the text used on action buttons gives a clear expectation of what’s going to happen next. Here are a few examples:
- “Add,” “Install,” “Get the app,” or “Add to Slack” — gets installed on the current platform
- “Integrate” or “Visit site to add” — continue elsewhere
- “Learn more” — read a help article to set it up
- “Request to add” or “Upgrade to add” — an additional approval or purchase is needed
- “Installed” — already done!
A few examples of the contextual installation calls-to-action in Miro’s marketplace.
Third-party disclaimer and permissions scope — when installing an app, it’s common to learn who the publisher is and where the app has access. This serves as both important security-related information for the user as well as a liability disclaimer for the platform itself.
Airtable’s disclaimer, FigJam and Slack’s permissions info.
Non-admin users can install — naturally, you want everyone to install the app or integrate it, and that’s often the initial default. Of course, this often depends on the organization’s rules, and certain apps might be either pre-approved, restricted, or allowed to be installed only by admins. When installed by individual users, the OAuth 2.0 authentication protocol is usually used to authorize on a personal credential level.
Linear satisfiers 🌈
Additional installation flows — certain platforms go the extra mile to provide a richer, more seamless experience and remove obstacles.
Pre-approved apps by admin — these are listed as safe apps for the given organization. This removes any repetitive approvals and waiting time for the most frequently used apps.
Miro and Zoom’s approach to surfacing pre-approved or pre-installed apps.
Add via Zapier — surfacing more workflows supported by external providers like Zapier enriches the platform’s experience with new possibilities.
“Powered by Zapier” badge in Miro’s marketplace.
Leveraging internal social proof — this may help drive engagement and activation, promoting trust in the app within the same organization. Knowing that 298 peers from my company use this tool may help me decide to install it. This kind of detail may help the platform and its partners become more successful.
A screenshot from Slack showing how many people are actively using Google Drive in your organization.
Delighters ✨
Request app — users will always need to use a specific app on top of what’s been pre-approved by their admin. A great experience removes obstacles, so providing a dedicated flow that facilitates individual app approval is a nice touch that’s contextual and saves a lot of time. The opposite would be an experience that says, “Only admin can install”.
Zoom’s marketplace streamlines the approval process via a dedicated flow.
Try in an app playground — providing users with a demo space is a nice touch. Figma’s playground is a great example, showcasing how seamless it can be to onboard users to a new widget.
Figma’s call to action creates a widget draft file as a playground.
A fine line between web and app experience — the fact that users can undo the app installation is great. Even more, it feels surprising to have such an experience when that happens on the web (while the user is logged in).
Figma allows an “Undo” action, even on the web part of the community marketplace.
Smooth auth transitions between apps — authentication in another app may be confusing, as the user is forced to switch context elsewhere. Miro offers a nice example, keeping their app’s look and feel consistent (using illustration) while applying Figma’s brand guidelines (the CTA color). The bottom line for users is that once they’re logged in, the look and feel stays familiar, even though this part of the flow is technically hosted outside of Figma. On top of that, providing an action to go back to Figma when the user gets lost (e.g. their browser tab gets closed) is a nice touch.
The look and feel of Miro’s app adapts to different contexts.
4. App onboarding
While reviewing these five SaaS marketplaces, it was clear that onboarding in the form of a tour, or sharing basic instructions on how to use apps or integrations, is not common practice. There are a few exceptions, however.
Baseline expectations ✅
App onboarding in the form of a tour is not common — perhaps because most apps and plugins are very intuitive and don’t require much hand-holding.
Linear satisfiers 🌈
App onboarding by app bot — communication platforms like Slack leverage bots and conversational UI experiences to welcome users. There are also guidelines helping developers and designers to craft welcoming onboarding messages using the bot.
Slack’s approach to app onboarding, leveraging its chat messages to explain the first steps. Source: https://api.slack.com/start/designing/onboarding
Delighters ✨
The publishers of Figma’s community can leverage Figma’s or FigJam’s templates as their onboarding playgrounds, allowing them to explain how their widget works while users try it.
Asana uses FigJam’s canvas to onboard users to their widget in a fun way.
5. App usage within the platform
This part of the journey is not related to building marketplaces per se, but it is important to consider when building the overall platform experience. Let’s have a look at some common patterns for launching and using apps, and how they fit into the platform’s UI.
Note: this review will focus on how apps are used within the same platform, thus excluding all interactions in apps living elsewhere (e.g. Zoom extension for Google Calendar).
Baseline expectations ✅
A dedicated app menu is a common UI pattern that allows users to browse apps without navigating to another page. Certain apps, widgets, or plugins interact with the surrounding surface, making the positioning of a toolbar crucial.
Miro, Figma, and Zoom’s dedicated app menu for launching installed apps and discovering new ones.
Conversational UI leverages slash commands to launch and control apps in any conversation within communication tools like Slack, etc. The baseline expectation is thus specific to such tools.
Slack’s slash commands as a way to launch an app in a conversational context. Source: Slack.com
Background syncing is your invisible worker that ensures data is automatically synced with other tools. No UI is usually involved, except for the initial setup.
Linear satisfiers 🌈
Keyboard shortcuts are good for power users. Figma, for example, allows you to run the last plugin used by hitting Option + Command + P. This adds value for routine and repetitive tasks.
Figma’s “Option + Command + P” keyboard shortcut to run the last plugin.
Typical UI surface areas for the apps — the following UI patterns are pretty common for most of the analyzed tools. Modal windows or dialogs are the most frequent way to surface the apps. Another way is sidebars(sheets), or an app with little UI can live in the app menu popover just after you run it. Certain apps are just actions, and thus they have no (or very little) UI. Widgets or bot conversation UI is another example. The bottom line is that it often depends on the nature of the interaction, use case, flow, platform, and conversions. You will know what works best for your users.
Asana’s UI widget as a FigJam object on the canvas, Unsplash’s plugin action in Figma, and an app’s modal window in Slack.
Delighters ✨
Contextual actions streamline the user experience with other SaaS tools. Once you find the sweet spot, where it is the most natural to initiate a certain flow for your users, it will feel like part of your product even though it’s technically not.
Convert a Miro post-it into a Jira issue, or perform actions on top of conversations in Slack.
6. App management
The next stage of an app’s lifecycle is how it is managed, configured, or even uninstalled. Users probably hit this step less frequently than others, but it’s still absolutely essential.
Baseline expectations ✅
Manage apps per workspace or/and per user — app and integration settings are on the level of the team (workspace) and user. Workspaces can have pre-installed and shared apps for all users in the workspace. Those apps that were installed individually are managed on a user level (e.g. the permissions can be revoked from there). The most common approach is to find more information about granted permissions or uninstalling the app.
A list of all added apps by Zoom and an example of installed apps in Miro.
Widgets and plugins are usually configured only in the context of their use (not elsewhere in settings).
Linear satisfiers 🌈
Requested app approval — pending requests are visible in the manage section, so users don’t rely only on email notifications.
An overview of app requests and their statuses in the Zoom app.
Delighters ✨
Contextual management experience — some marketplaces can recognize whether the user is logged in and, based on their role, display additional management actions, e.g. in the app detail. Contextual experience is always tailored for users, making it easier to find out how to manage the app. This creates a fine line between in-app and marketplace experience.
Contextual manage actions on Zoom’s marketplace website (the user is logged in).
In addition to reviewing the core journey, here is some additional information to provide a complete picture when building a marketplace for your SaaS platform.
- Naming conventions — a boring, yet useful topic
- Developer experience — a sneak-peek perspective of how it looks for publishers and technical users
Naming conventions
A familiar name plays an important role in the success of a platform’s offering, ensuring that users get a clear understanding of what it’s all about and what they can find there.
Baseline expectations ✅
A clear, descriptive, and familiar name for the offering directory. Based on my evaluation of five popular SaaS tools, the name “marketplace” seems to be the most common naming convention. Other names (on top of the 5 reviewed tools) include: “Apps,” “App directory,” “App Store,” “App hub,” or just “Integrations.”
Miro, Zoom, and Airtable use “marketplace” as a name.
Slack uses “App directory” and Figma uses “Community,” where it combines all types of content under one roof.
Users of a SaaS product can usually choose from apps that extend certain functionality. Note that other common names include “extensions,” “widgets,” “plugins,” “embeds,” “bots,” etc. Naming does not seem to be standardized, and SaaS companies often experiment with the right name that works for their customers and product. For example, Notion recently renamed “Integrations” to “Connections”, while Airtable changed their offering from “Apps” to “Extensions”.
- Apps — a piece of software typically installed on a platform to do a certain job, facilitating a tailored workflow. It can be added or installed to enrich the experience of the same product (e.g. managing Asana tasks directly in Miro’s board as cards), and it may help to facilitate a certain job with another product (e.g. creating a task in Asana directly from Figma’s canvas). All true platform products have UI-driven experiences that allow partners to build workflows on the target platform directly.
- Integrations — generally speaking, integrations represent a way to connect your product or internally built tools to customize your experience of the platform. Besides that, integrations allow platforms to connect to external data sources, allowing the exchange of data (e.g. Productboard imports Amplitude segments to help product managers narrow down customer feedback combined with behavioral data). Building on a platform usually happens via a standardized programming interface (API) and often uses SDK to help speed up development.
Developer experience
Developers/publishers are first-class citizens of marketplace ecosystems. They sit on the other side of the user, building the actual apps and integrations. Let’s take a sneak peek at what that experience looks like for a tech audience.
Note: Although this topic deserves its own in-depth review, the following is just a basic overview. Leave me a comment if you are interested in learning more, and I’d be happy to dig deeper.
Baseline expectations ✅
Dedicated landing pages for developers/publishers — tailoring the experience for a small yet very important audience is crucial. The platform needs marketing to convince the tech audience as well. Publishers need to learn what typical use cases they can build for and learn more about the implementation details during their technical discovery, etc.
Miro and Figma’s landing pages for developers.
Technical documentation — it’s fairly standard to document all the toolkits that are provided to developers (API, SKD, etc.). Without that, it would be impossible to build stuff, and it wouldn’t even be scalable enough to support any platform on a larger scale.
Best practices, guidelines, and developer docs by Slack and Figma.
Manage custom apps/plugins within the product — a self-served developer experience is a must for scalable SaaS platforms. Being able to see and manage your own (non-published) apps under a personal account is an important experience to streamline basic operations during development and testing — avoid relying on customer support.
Manage your custom apps in the Zoom App Marketplace and Slack API.
Getting started wizards — the developer experience usually reflects the fact that it relies on power users. Engineers rely on text-heavy documentation that they need to crunch through. Documentation works great when you need help and further learning, but reading “books” isn’t the best way to get people on board fast. Fortunately, there are some good examples out there that hand-hold developers through their first steps using tailored wizards, making the process easy. This is a nice touch that may help drive better adoption and scale your platform, as it mitigates the initial pains that come with getting started. Overall, it improves the developer experience.
Getting-started app wizards by Slack, Figma, and Zoom.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK