MarketplaceTM by Dialog Enterprise

Introduction

Dialog Enterprise Marketplace is the largest public-facing enterprise SaaS product shipped by the Ideamart engineering team at Dialog Axiata. The core idea, in one line: a Shopify for telco-grade enterprise tools. Pick the solution you need, configure it, pay, and it is live, with no developer, no sales engineer, no procurement cycle.

The public marketing site frames it as "a one-stop-shop digital platform with a wide range of easy-to-use, click-and-go type widgets-based enterprise solutions", with three promises on the wall: Zero Complexity, no coding knowledge is needed, a self-service model, and affordability through single-provider billing. The job of the design work below was to make those three promises true at every step of the actual product.

It started in early 2020 as an internal pilot beside the existing Ideamart API and Ideabiz developer platforms. Those products served code-literate buyers well. This one had to serve everyone else.

The Beta went live quietly. Within weeks, marketing, existing Ideamart customers, and Ideabiz business users were pitching it inside their own networks. We had not planned for the attention. Rather than retreat, we kept the Beta live as a research instrument and formed a parallel team to rebuild from scratch as Marketplace 2.0, codename Polaris.

Where it lives today

Scale of the Catalog

By September 2023 the catalog spanned 25 categories and roughly 100 widgets, from corporate voice and digital payments to IoT, security, surveys, location intelligence, and enterprise analytics. The buyer might be a corner shop or a multi-branch enterprise. Designing one discovery surface that worked for both was the central UX problem.

Set of widget categories as of August 2023.

Process at a Glance

The work below maps to an end-to-end design process that I owned across multiple years:

1. Frame the problem. 2020 origin sketches under the Ideabiz Enterprise Solutions brand. Category-grouped catalog, multi-rail checkout, partner revenue model.
2. Ship the Beta as research. Public release of an unfinished pilot, deliberately, to surface real-user constraints.
3. Research and discovery. Qualitative Beta feedback, catalog-scale analysis, structural audit of the inherited onboarding.
4. Constraint mapping. Documenting the Keycloak auth lock as the load-bearing problem to design around.
5. Information architecture. Four user types, journey maps, role permission matrix.
6. Design and prototype. Wireframes, high-fidelity screens, interaction patterns in the new design framework.
7. Build and ship. HTML and CSS implementation of the full UI layer, consumed by React engineers.
8. Standardise. Extract the framework into a reusable system for the next generation of Ideamart products.

My Role

I was the only UX person on this product. Over the lifespan of the project that role kept widening, because the gaps I saw kept demanding it.

UX Designer first

I joined as the UX designer. I owned research, information architecture, user flows, wireframes, and high-fidelity screens for the full product. Every flow you can see on the live portal, I sketched, mapped, and designed.

UX Engineer, by necessity

Designs kept losing detail on the way to React. So I stopped handing off and started shipping. I built the entire UI layer of Polaris in HTML and CSS, component by component, exactly to my own specs. The React team consumed my markup as the source of truth instead of trying to interpret a Sketch file. What I designed is what got built, because I was the one building it.

Part Product Owner, when nobody else held the vision

The original Beta had no UX owner and a fragmented product direction. When the rebuild started, I wrote the roadmap, defined the four user types, scoped the public catalog cut, set the saved-resumable KYC as a non-negotiable, and stayed in the room for every prioritisation call. I was not the product manager, but on every decision that touched user experience, I owned the position.

Architect of the Ideamart design framework

Marketplace became the first product to ship on a custom, in-house design system I built for the Ideamart organisation. The framework, tokens, components, layout primitives, and interaction patterns, did not exist before. Every previous Ideamart product had reinvented its own UI from scratch. Marketplace was the moment the org stopped doing that.

Who I worked with

• Ideamart product and engineering leadership, who set the case for moving from a developer audience to a self-serve business audience.
• The Polaris rebuild team, formed specifically to ship Marketplace 2.0 while the Beta continued serving live users.
• The Dialog Enterprise marketing and sales organisation, who provided early demand signal and acted as a proxy voice of the customer.
• Existing Ideamart and Ideabiz customers, who became unintended Beta testers and the richest source of qualitative feedback we had.

Cross-functional collaboration, start to finish

I was in the room from the first brainstorm and stayed in the room through every phase that followed. That meant pitching the original concept internally, then re-pitching the Polaris vision to the XL Axiata team in Indonesia when the sister deployment was on the table. Day to day, I drove the product sprints alongside the Product Manager and the Project Manager, kept the development team aligned with the build vision, and stayed close to the Product Owner so the satisfaction loop on every release was visible. The job was never just "design and hand off". It was making sure design, engineering, and product strategy stayed in sync at every layer.

The Beta That Forced a Rebuild

The Ideamart API and Ideabiz developer platforms served code-literate buyers well. The pilot tested whether the same enterprise tooling could be wrapped in a self-serve surface for buyers who had never seen a webhook.

The internal pitch landed instantly. Rather than shelve an unfinished product, we published it as a Beta. The bet: every real user who hit a wall would point us to a constraint we had not seen. The Beta became our biggest user interview, conducted live, in production, at zero research cost.

Origin Sketches, 2020

The earliest artifacts of this product are wireframes I drew when the brand was still "Ideabiz Enterprise Solutions", before the Marketplace name existed. The Shopify-like idea is already visible: categorised solutions, a dashboard that tracks what is active and what is expiring, a checkout that aggregates a cart of services across multiple Dialog payment rails. The vocabulary changed. The shape did not.

Research and Discovery

The discovery work happened in three streams running in parallel: qualitative feedback from the live Beta, a hard look at the catalog scale problem, and a structural audit of the inherited onboarding flow that I had not designed.

Learning from Beta Public Feedback

Once the Beta was live, the feedback was almost universal in shape: people appreciated the effort and the ambition, then quickly hit a wall. The walls were almost always in the same places. Onboarding was too long for the value being offered. The decision of what type of user someone was got made before they understood the choices. The catalog itself was hidden behind sign-up, KYC, and manual approval, so prospects who wanted to evaluate fit could not even see what was on offer.

This was the signal that justified the rebuild. The product was solving a real problem, the surface that wrapped it was not.

The Catalog-Scale Problem

Roughly 100 widgets across 25 categories is a lot of surface area to expose to a non-technical buyer. The Beta tried to surface everything as a flat grid once you got inside, with no progressive disclosure, no comparison helpers, and no contextual recommendation. The information architecture needed to start over with the buyer in mind, not the product taxonomy.

Inherited UX Violations in the Beta Onboarding

The Beta onboarding flow had been built as a prototype, without UX involvement. Once I was given the mandate to lead the rebuild, I documented the inherited flow in full so the team had a shared reference for what we were redesigning away from.

Re-architecting the User Journeys

Marketplace 2.0 had to serve four distinct user types, each with a different reason for being on the platform, a different permission surface, and a different journey. Designing one flow for all four was the trap the Beta fell into. Designing four journeys that converged on a shared catalog was the way out.

• Enterprise owners, the buyers. They want to discover, evaluate, configure, and subscribe to solutions for their own business.
• Marketplace partners, external resellers. They want to discover demand, configure on behalf of customers, and earn margin on subscriptions they bring in.
• Service providers, the solution publishers. They want to list, price, and operate a widget on the catalog and reach the buyer base directly.
• Dialog account managers, internal sales. They sit on a separate internal admin surface in Polaris rather than the public signup, because their access path is account-attached, not self-serve.

Permission-Aware Journey Mapping

Before any screens were sketched, I mapped the partner portal journey end to end, including which screens each role could see, which actions each role could take, and where the journeys diverged versus shared a screen. The map became the single source of truth for the rebuild team, and it caught permission edge cases that would otherwise have surfaced only in QA.

Wireframes That Anchored the Rebuild

Before any pixel-perfect work, the rebuild was scoped out in wireframes that covered every public surface, every gated surface, and every wizard state. The set below is the wireframe sheet I used to align the Polaris team and the React engineers on what to build, in what order.

Public Marketing and Catalog Before the Gate

The most consequential change was structural. The marketing site, the category browse, and the individual widget detail pages all moved in front of authentication. A first-time visitor can land on the homepage, follow a link to a specific app, and read what it does, what it costs, and how it integrates, without ever signing up. KYC and approval still gate the act of subscribing, but they no longer gate the act of looking.

Key Decisions and the Tradeoffs Behind Them

• Parallel rebuild, not in-place refactor. Considered: refactor the Beta incrementally to preserve continuity. Rejected because the Beta's auth, IA, and onboarding were structurally entangled, so an incremental fix would have meant living inside Beta scaffolding for the entire rebuild. The cost was running two products at once for the transition window. The win was a clean foundation and zero churn for existing Beta users.
• Move profile-type to a wizard step, not a blocking modal. Considered: keep the four-option pre-signup modal but with better copy. Rejected because asking someone to declare their role before seeing the catalog is the wrong order of decisions. The wizard step lets the user complete it once they have context, and the role can change behaviour of later steps inline.
• Keep human approval, fix the experience around it. Considered: remove manual approval entirely for low-risk roles. Rejected because owner identity, business legitimacy, and partner payouts genuinely need a human check, and arguing that internally would have delayed the rebuild by quarters. The tradeoff: keep the gate, but ship a stated SLA, a celebratory approved state, and a transparent pending screen so the wait feels honest instead of opaque.
• Build the UI in HTML/CSS, not just hand off Sketch. Considered: high-fidelity Sketch files plus a design spec for the React team. Rejected because in Beta we had already seen Sketch-to-React lose detail at every handoff. The tradeoff: I personally owned more implementation work, but what I designed is what got built, with no interpretation gap.
• Open the catalog publicly, keep purchase gated. Considered: stay fully gated for simpler compliance and analytics. Rejected because the Beta's drop-off lived right at the gate, before anyone could evaluate fit. Separating discovery from commitment was the highest-leverage UX move in the rebuild.

The Polaris Rebuild

Rather than refactor the Beta in place, we ran two products in parallel. The Beta kept serving its growing audience and kept producing feedback. A separate team, with me leading UX end to end, built Marketplace 2.0 from a clean foundation. That decision protected the live users from churn, protected the rebuild from being constrained by Beta scaffolding, and let us cut over only when the new product was demonstrably better on every flow we cared about.

The live portal is at marketplaceportalbeta.dialog.lk, the consumer marketing site is at marketplace.dialog.lk, and the corporate placement sits at business.dialog.lk. The walkthrough below covers the flows that resolved the Beta's biggest UX failures.

Marketing in Front, Catalog Open

The Polaris homepage is a public marketing surface, not a login wall. Anyone can read the value proposition, follow the Products menu into a category, and open a specific widget detail page. The Beta's first impression was a credential prompt. Polaris's first impression is the product itself.

AI-Powered Match Scoring

Even in 2023, we shipped a native AI match score on every widget detail page. The score reflects how well the widget fits the visitor's business profile based on the categories they have explored, the apps they have viewed, and the inputs they have already given the platform. It was the first native AI-driven recommendation surface on a Dialog Enterprise product.

The First-Time User Wizard, Saved and Resumable

The single largest behavioural change between Beta and Polaris is here. KYC stopped being a one-shot form gauntlet and became a four-step Build-your-Organization wizard with a progress bar, independent steps, and a save state on every input. A user can complete the four steps in any order, leave halfway through, return days later, and pick up exactly where they left off. The product never asks them to start over.

The four steps are Your Profile, Account Type, Business Profile, and Terms and Conditions. Each step is independently completable, independently saveable, and shows a clear status on the parent screen. Sign-in is offered inline on the very first step for users who already have an account, so the "am I new or returning" ambiguity that the Beta forced into the login form is resolved here instead.

Before and After, by the Screens

Counting screens to get from "new visitor" to "able to use the product":

Same compliance outcome, very different path through it.

Honest Waiting and a Clean Handoff to Approved

Approval still exists. Owner identity, business legitimacy, and partner payouts demand a human review step, and removing that was never on the table. What changed is how the waiting period is communicated. The Beta dropped users into an opaque "pending" screen with no expectation set. Polaris commits to a 1 to 12 hour SLA, surfaces the completed steps the user just submitted, and explains the next handoff in plain language. When approval lands, the same screen flips to an "Approved" celebratory state with a direct CTA into Discover.

A Dashboard, Not Just a Catalog

Post-approval, the user lands on a portal home that frames Marketplace as an operational surface rather than a one-time purchase. Month-to-date spend, active apps, average app cost, what is new in the marketplace, and onboarding videos all live on the home screen. The Discover surface sits one click away and is built as a dynamic feature page with featured apps, top apps by usage, categories, and audience-segmented entry points for Startups, SMEs, and Large Enterprise.

Subscribe, Without Leaving the App

Activating a widget pulls payment method, package selection, and partner attribution into a single confirmation flow. Add-to-bill or card payment, monthly versus per-month versus per-request pricing, and a marketing-agent assignment field for partner-led deals all live on one screen. The user reviews, confirms, and is redirected back into the app home page with a clean success state.

Settings, Mapped End to End

Settings was the surface where every role, every billing rail, and every account-management action collided. I mapped the entire flow before the visual design so the team had a single reference for what lived under each settings entry point.

The Surface, at a Glance

A quick sweep across the rest of Polaris: multi-business switching, mid-flow KYC states, alternative widget detail pages, payment method variants, and the success state after a subscription lands.

Outcome and Impact

• Shipped live. Marketplace 2.0 is the production experience at marketplaceportalbeta.dialog.lk and remains the largest public-facing enterprise SaaS product released by Dialog Ideamart engineering.
• Marketing and catalog opened up. Prospective buyers can read the value proposition and explore individual widget detail pages without an account, removing the single largest drop-off in the Beta funnel.
• Saved, resumable KYC. The four-step Build your Organization flow replaced the Beta's one-shot form gauntlet. Every input is saved at the moment it is entered, and the user can resume the flow days later without re-starting.
• Native AI match scoring, in 2023. Every widget detail page surfaces a personalised match score with an explainer modal, well ahead of generative-AI being mainstream in enterprise SaaS.
• Partner program enabled. The Marketplace Partner role moved from a paper concept in the Beta to a working revenue stream, with partner attribution baked into the subscribe flow itself.
• Three public roles, one product. Enterprise owners, partners, and service providers coexist on a single platform with role-aware journeys. Dialog account managers operate on an internal admin surface that maps to the same data model.

By the Numbers

• ~90% reduction in manual onboarding calls. Self-serve onboarding scaled to the point that the manual call-to-onboard motion for Owners and Partners was almost eliminated. Partners began joining the platform without ever contacting support, because nothing was blocking them.
• ~60% reduction in inbound support calls. Polaris shipped with a well-organised, highly searchable support catalog. Users found their own answers, and the volume that used to land on the support team's phones dropped accordingly.
• Time-to-activation collapsed from 24, 36 hours to almost instant. The combination of the saved-resumable wizard, the public catalog ahead of the gate, and the eventual auto-approval of KYC closed the wait between visitor and active widget.
• Two-country deployment. The product, the architecture, and the design framework were portable enough that XL Axiata in Indonesia picked the platform up almost verbatim for a different regulatory and payment-rail stack.

A sister deployment in Indonesia

While the rebuild was wrapping up, our fellow Axiata Group company, XL Axiata in Indonesia, learned about what we were building. After the majority of our scope was complete, a small group of individual developers from our team were sent over to XL Axiata to customise the platform for the Indonesian market and deploy it there. The product that started as an internal Sri Lankan pilot now also runs at a second telco, against a different regulatory stack, a different language, and a different payment-rail mix. The architecture and the design framework held up well enough that a sister telco picked it up almost verbatim.

Building the Ideamart Design Framework

For years before Marketplace, every Ideamart product reinvented its own UI from scratch. There was no shared component library, no token set, no agreed-upon interaction patterns. Each release looked, behaved, and broke differently. Marketplace was the first product where I refused to start from zero, and the framework I built for it became the standard the org had been missing.

What the framework gave us

• A token system for colour, spacing, type, and radii, so the same primary purple, the same button rhythm, and the same step-cards appear across every screen without anyone making a fresh decision each time.
• A component library for the patterns that repeat: step cards, status badges, role cards, app cards, package selectors, payment-method tiles, search bars, dashboard tiles, agreement gates.
• Layout primitives for the screens that recur: dashboard shells, multi-step build flows, app detail pages, confirmation flows, empty states.
• Interaction patterns for the moments that mattered: saved-step transitions, in-place pending-to-approved flips, modal-on-context-not-as-blocker, mobile OTP verification.

Why this matters beyond Marketplace

Once the framework existed and shipped on a flagship product, it could be reused. New Ideamart enterprise products no longer needed a UX designer to start from zero, because the surface area, the look, the rhythm, and the components were already decided. The framework became a reusable foundation for the next generation of Dialog Ideamart enterprise products. The gap that had existed in the org for years, no shared design language, closed with this release.

Reflections

A live Beta is the cheapest research budget you will ever have

Shipping an unfinished product is a cost. Shipping it deliberately, with the team aligned that the first version will be replaced, turns that cost into a research investment. Every wall a user hit in the Beta was a brief for the rebuild.

Discovery and commitment are different problems

The single biggest design decision in Polaris was to stop treating browsing and buying as one funnel. Discovery wants minimum friction. Commitment wants verification. The Beta forced the same gate on both, and lost most users at the first step.

Map the journeys before you draw a screen

Four roles on one product is the kind of complexity that explodes into edge cases late in build if it is not modelled early. The partner portal journey map paid for itself many times over by catching permission conflicts and shared-screen ambiguities before any React component existed.

Being the sole UX is a forcing function, not a limit

Owning research, IA, interaction, visual, and front-end implementation on a product of this scale was demanding, and it removed every excuse for misalignment between what was designed and what was built. There was no handoff to lose anything in, because there was no handoff.

Where the work was not finished, and what happened next

At the time of the Polaris rebuild, approval was still a wall, just a more humane one. Owners and partners could browse the catalog freely, but could not activate a widget until KYC was approved. We had replaced an opaque blocker with a transparent one, complete with a stated SLA and visible progress, but the human review step itself remained. I framed it as an organisational decision rather than a UX one.

After I left Dialog in November 2023, that organisational decision was made. The team implemented auto-approval for KYC, and the last wall came down. Time-to-activation went from 24 to 36 hours to effectively instant. The system was designed to be finishable without me, and the next team finished it.