In-App Stories
in m10

Discovery

The first person to touch the tool

Before Stories existed in m10 at all, I found and evaluated InAppStory — the vendor platform behind the format — and was the first person at the company to actually get inside it: testing the editor, the cover export constraints, the widget library, and the publishing and segmentation controls. That hands-on exploration is where the design guidelines further down came from — reverse-engineered from the tool's real limits, not written from a brief.

Context

A new home-screen channel

Stories is a short-form, full-screen slide format that lives in a row on the m10 home screen — tap a cover, and it opens into a sequence of slides with images, video, buttons, and interactive widgets. It's configured per story on InAppStory rather than custom-built. m10 uses it across six content types: Product (new features, reminders), Promo (offers, bonus campaigns), Study (onboarding, tips), Gamification (quizzes, games), Feedback/Survey, and Inspiration (brand, values, causes) — in service of MAU growth, feature activation, engagement, and fast qualitative feedback.

Before / after — the Stories row sits between My Payments and Our Services. (The broader visual refresh across the screen shipped in the same period and isn't a Stories change on its own.)

Problem

Nobody had a playbook

The first wave of Stories launched without shared rules. Every requester designed their own slide layout, text hierarchy, and pacing from scratch — different placement of image and text slide to slide, too many competing type styles, and no distinction in structure between a feature announcement and a quiz.

First iteration — testing formats and content with no shared structure

Low read-through meant most slides after the first were never seen; low click-through meant the CTA — when there was one — rarely landed.

Design guidelines

Rules for a screen the size of a fingertip

Covers compete for attention in a home-screen row already crowded with quick actions and services, so I documented exactly what a cover needs to work: seen/unseen frame states so read stories visually recede, title character and line limits with a defined truncation rule, safe-zone maps for where illustration can and can't sit, and WCAG contrast checks so title text stays legible against any background art.

Seen/unseen frame states, title character and line limits, title container behavior

Illustration safe zones and alignment rules, export specs, title/background contrast checks

Content structure

One layout, repeated on purpose

Every slide in a story follows the same visual grammar: if slide one puts the illustration on top and text below, every slide in that story does too. Text is limited to three styles — title (max 3 lines), subtitle (max 4 lines), and an optional badge (1–2 words) — so no story turns into a wall of competing fonts. From there, the rules split by what the story is trying to do:

• Informational — new features, updates: 2–3 slides, one CTA for the whole story rather than one per slide. Don't route a user to a feature and ask for feedback on the very next slide. No empty headers — every title carries information, and CTAs need enough contrast to read as clickable.
• Feedback & quizzes — widgets, tests, ratings: max 5 slides, one question per slide. Highest-priority questions go first, since conversion drops with every added slide. Multiple-choice over open text wherever possible. Full quizzes need their scoring logic scripted in advance — which answer earns which points, which result each score range maps to.
• How-to — step-by-step instructions for a specific service, documented as its own reference guide for whoever's building that story.

Guidelines in practice

Same system, dozens of stories

Once the rules existed, output multiplied without losing consistency — product announcements, quizzes, seasonal promos, and brand moments all reading as the same family, each still distinct in content.

Product & promo — Birmarket lottery bonuses, the Garage, FIN reminders, cross-border transfers

Feedback & activation — a financial-decisions quiz, one-click transfers, a personality quiz, card activation

Status & seasonal — a paused-feature notice, the AI assistant launch, a limited-time offer, a seasonal quiz

Process & governance

From me to the team

Publishing a story end-to-end touches six functions: Content owns the process from brief to publish; CVM handles segmentation, testing, and monitoring; Product Marketing supplies the brief and message; Growth runs experiments and technical support; Design — the graphic designers I art-directed — builds the visuals; Analytics reads results back against product metrics. I wrote the brief template every request now starts from — goal and CTA, audience segment and whether it needs a control group, launch dates, message, format, and a post-analytics plan — and ran the sessions that trained CVM and Marketing on the platform itself, so the process could run without me in the loop. The guidelines above were the handoff document.

Results

A channel that scaled

After the guidelines and process shipped, the same format that struggled at 7–8% click and under 30% read settled into a consistent, repeatable performance band.

Daily reach, reads, and read rate for a single story over two weeks — a consistent, repeatable performance band

Stories is now the team's default lever for in-app communication — not just for promo pushes, but as a fast, cheap research channel: quizzes and polls that used to require a separate survey tool now ship as a story and return results in days.