Namabar Admin Dashboard

Operator console for Namabar — message ops, campaigns, templates, and verification services

2026·Product Design

Background

Namabar is a multi-channel messaging platform for OTPs, alerts, and notifications across SMS, WhatsApp, Telegram, and Viber. The landing page sells the product; the admin dashboard is where teams run day-to-day operations — send volume, delivery health, campaigns, templates, and verification services.

I designed the admin as a single operational workspace: a dashboard for at-a-glance status, deep message inspection, creation flows for campaigns and templates, verify-service setup, and in-product documentation — shared navigation, tables, and form patterns so it feels like one console, not a bundle of tools.

Same brand anchor as the Namabar landing page.

The Problem

Messaging platforms often ship a strong marketing site but leave operators with fragmented admin UIs — send logs in one place, templates elsewhere, OTP services in a separate panel, and API docs only on the public site.

Namabar needed operators to see delivery health quickly, drill into failures, launch campaigns, and configure verify services without re-learning layout on every screen. Dense tables and multi-step forms had to stay scannable under real support and ops load.

Namabar admin dashboard overview — Dashboard — volume, status, and navigation need to anchor ops before deeper flows.

What I did

I structured the admin around one left-nav shell and repeatable patterns: KPI cards and charts on the dashboard, filterable message tables with a detail drawer, stepped create flows for campaigns/templates/services, and embedded docs for engineers.

Hi-fi screens share type scale, green accent, and table density with the Namabar landing page so the product reads as one family — marketing surface and operator console, not two brands.

Dashboard

01 / 06

The home view surfaces send volume, delivery breakdown, and recent activity with chart and table summaries — enough signal for ops to spot spikes or failures before opening individual messages.

Namabar admin dashboard — Dashboard — KPIs, delivery chart, and recent messages in one ops home.

Message details

02 / 06

A message detail view shows channel, recipient, status timeline, payload, and errors — so support can answer “what happened to this OTP?” without exporting logs or asking engineering.

Namabar admin message details — Message details — status, payload, and delivery trail for a single send.

Create campaign

03 / 06

Campaign creation walks operators through audience, channel, content, and schedule in a disciplined form — complex sends stay guided instead of buried in raw API fields.

Namabar admin create campaign flow — Create campaign — stepped setup for multi-recipient sends.

Text templates

04 / 06

Reusable text templates get a dedicated create flow with naming, body, and variable placeholders — so marketing and ops can standardize copy without duplicating sends by hand.

Namabar admin create text template — New text template — structured fields for name, body, and variables.

Verify services

05 / 06

OTP and verification flows need explicit product setup: Create New Verify Service captures service name, channel, and routing rules so authentication traffic is governed, not ad-hoc per integration.

Namabar admin create verify service — Verify service — configuration for OTP and authentication traffic.

Documentation

06 / 06

In-admin documentation mirrors the developer story from the landing page — API reference, auth, and examples — so engineers configuring keys or webhooks do not leave the console for the marketing site.

Namabar admin in-product documentation — Documentation — API reference and integration guidance inside the admin.

Results · Key takeaways

The admin dashboard is documented as a complete operator product direction: dashboard → message drill-down → campaign and template creation → verify-service setup → in-product docs, with shared shell and visual language aligned to Namabar’s landing page.

Namabar admin documentation at a glance — Docs in-console — developers stay in the same shell as ops and support.

Key takeaways

Ops UIs earn trust through message truth — dashboards are useful only if detail views answer delivery questions without engineering escalation.
Creation flows should match object mental models — campaigns, templates, and verify services deserve distinct stepped forms, not one generic “send message” dialog.
Docs belong in the admin — when configuration and API keys live in-console, documentation should too, or integration friction returns.