Advanced Dropdown Builder
From 200+ option chaos to intelligent progressive disclosure
Quick 3 min
Deep 11 min
Fast Track AI (2024)
SMS Characters: Count & Preview
Preventing costly messaging errors through accurate counting and multi-language support
Impact
- •We went from multiple five-figure billing disputes in a six-month period to zero disputes in the six months after launch.
- •The solution enabled instant calculation, preview, and troubleshooting for all message types, including complex scenarios with emojis, variables, and special characters.
- •RTL text support opened Arabic and Hebrew markets that had previously been inaccessible. Partners who were composing messages externally could now work entirely within the platform.
- •Support tickets for SMS issues dropped significantly, and partner self-service improved dramatically because the interface now documented itself through contextual tooltips and warnings.
- •QA approval safeguards prevented costly sending errors by requiring explicit acknowledgment of cost-impacting elements before campaigns could be sent.
Timeline
Q2 2024 (3 months)
Team
6 (Product Designer + 3 Engineers + Product Manager + QA Engineer)
The Problem
Our enterprise CRM's SMS channel served partners across the globe, but shipped with a basic character counter that couldn't handle modern messaging requirements. The system failed with emojis, non-Latin scripts, and dynamic text fields, causing incorrect message counts and unexpected campaign costs. Partners were blindsided by inflated SMS charges when diacritics or Unicode characters silently pushed messages from one segment to three. Critical billing disputes forced urgent action, while Arabic and Hebrew partners composed messages externally because our RTL text rendered unreadably.
Core Issues:
- •Financial RiskCharacter miscounts were causing up to 3x message costs without warning. A single emoji triggers an encoding switch from 160 to 70 characters per message, potentially tripling costs. We had multiple five-figure refund demands within six months, partners were questioning platform reliability, and campaign ROI was being destroyed by unexpected overages.Impact: Enterprise financial exposure and damaged partner trust
- •Technical LimitationsEmojis were counted as 1 character while actually varying from 2-8 depending on the sequence. Extended GSM characters were triggering encoding switches silently. Dynamic variables showed static counts that bore no relation to actual message length. The input fields did not support rich-text features needed for proper preview.Impact: Systematic undercounting leading to billing surprises
- •Market BarriersPartners were leaving our platform to use external tools for accurate calculations. Broken RTL text rendering made QA essentially impossible for Arabic and Hebrew content. This created competitive disadvantage in international expansion.Impact: Lost market access and reduced platform stickiness
Why It Mattered:
- •SMS encoding errors create enterprise financial risk: one emoji can triple message costs
- •Most CRM platforms handle only ASCII, leaving enterprises vulnerable to billing surprises
- •Partners using external tools signals fundamental platform trust issues
- •Broken RTL support means zero market access in entire regions
My Approach
1. Crisis as Business Case
Decision: Leveraged billing disputes to secure resources for comprehensive solution rather than band-aid fixes
Rationale: Senior management initially viewed this as a minor technical issue until billing disputes revealed enterprise-level financial risk and market expansion barriers. Financial impact created undeniable urgency where user complaints had not. I continued development during regular sprints and kept working on a comprehensive solution, so when crisis struck, we were ready.
Result: Secured full team allocation for three-month sprint instead of incremental patches that would have created new vulnerabilities.
2. Constraint Design Process
Decision: Used support tickets and billing disputes as primary research data instead of traditional user research
Rationale: With no time or resources for extensive user research, we leveraged support tickets and billing dispute details as our primary data source. Each dispute included screenshots, message content, and extra-cost calculations. We essentially crowdsourced our usability testing data from real-world failures.
Result: Rapid problem identification without research timeline, with evidence directly tied to business impact.
3. Real-time Detection Over Post-Composition
Decision: Live encoding detection during typing rather than validation after message completion
Rationale: Cost awareness must occur during composition, not after mental commitment to the message content. Once someone has written their message, asking them to rewrite feels punitive. Catching issues as they type lets them make informed trade-offs naturally.
Result: Partners actively modified content to optimise costs during composition rather than discovering problems after the fact.
4. Risk-First Implementation
Decision: Eliminated financial risk before adding enhancement features
Rationale: A risk elimination attitude ensured financial exposure was removed first. This prevented partial or patchy fixes that could create new vulnerabilities. Comprehensive solution over band-aids meant we would not be back here in six months.
Result: No cascading issues from partial implementations, complete problem resolution in single release.
Key Design Decisions
Intelligent Counting Engine
Real-time encoding detection that handles the full complexity of modern messaging. Emoji sequence handling correctly counts compound emojis (family emoji = 8 characters, not 1). Dynamic variable estimation uses defensive defaults: names at 25 characters, offers at 50, URLs at 100. Nested variables calculated recursively. Undefined variables display as placeholder text (8 chars) to prevent underestimation that would cause billing surprises.
Visual Feedback System with Severity Coding
Different indicators for known versus uncertain costs because they require different mental models. Yellow warnings for uncertain costs (variables that might expand) align with conventions for intermediate alerts encouraging timely adjustments. Blue info indicators for known impacts (special characters with calculable cost) provide reliable context without false urgency. Toggle-controlled character highlighting aids debugging but can be disabled to show accurate final message appearance.
Toggle-controlled highlighting: debugging mode vs. accurate final preview
Contextual Tooltip System
Comprehensive tooltips explain how specific elements affect SMS encoding and segment count. Each tooltip type addresses a specific pain point: emoji impact on character limits, variable expansion estimates, special character encoding switches, hyperlink handling, and footer defaults. Partners can make informed decisions during composition rather than discovering impacts after sending.
Mobile Preview Interface
Full device mockup with real-time updates showing exactly how SMS will appear to recipients. Multi-segment pagination display shows message breaks. Variable field preview with sample data lets partners see realistic message rendering. This became the highest-valued feature per partner feedback because SMS is consumed on mobile, and preview builds send confidence.
Real-time mobile preview: highest-valued feature per partner feedback
RTL Language Support
Bidirectional text implementation with proper cursor behaviour for Arabic and Hebrew composition. Mixed-direction content handling for messages combining RTL and LTR elements (like URLs in Arabic text). Integrated Arabic and Hebrew fonts. Partners who previously composed externally could now work entirely within the platform.
Global language support: proper rendering across Latin, Devanagari, Chinese, and RTL scripts
QA Approval Safeguards
Mandatory acknowledgment system prevents accidental cost overruns. Partners must explicitly confirm understanding of variable text impact before sending campaigns with dynamic content or special characters. Once acknowledged, financial responsibility transfers to partner. The system warns but cannot prevent high-cost sends if explicitly approved, which is the right balance for enterprise autonomy.
Implementation
Technical Approach:
- •Cascading detection system evaluates characters in order of complexity, optimising for both accuracy and performance
- •Debounced checking at brief intervals delays evaluation during typing to minimise computational load while maintaining smooth interface performance
- •Cached encoding for unchanged sections retains results for static message portions, avoiding redundant analysis
- •Lazy evaluation for variable previews with defensive character estimates (names = 25, offers = 50, URLs = 100)
- •Optimised regex patterns for instant character detection and encoding trigger identification
- •Wrapper components built as interim solution while coordinating parallel system upgrade for rich-text input support
- •RTL bidirectional text implementation with proper cursor behaviour and mixed-direction content handling
Rollout Strategy:
- Weeks 1-4: Risk Elimination
- ◦Mapped GSM encoding rules and all edge cases including emoji sequences and extended characters
- ◦Analysed dispute patterns to identify highest-impact failure modes
- ◦Implemented mandatory cost warnings for high-risk SMS containing encoding triggers
- ◦Built basic mobile preview to validate message appearance before sending
- Weeks 5-8: Core Features
- ◦Developed intelligent counting engine with real-time encoding detection
- ◦Built visual feedback system with severity-coded warnings and info indicators
- ◦Created comprehensive tooltip system explaining impact of each element type
- ◦Implemented toggle-controlled character highlighting for debugging
- Weeks 9-12: Market Enabling
- ◦Implemented RTL text support with bidirectional rendering and proper cursor behaviour
- ◦Built advanced character highlighting with mixed-direction content handling
- ◦Deployed QA approval interface with mandatory acknowledgment for cost-impacting elements
- ◦Partner beta testing provided validation that synthetic testing could not achieve
Process
Discovery: Second major billing dispute hit and created crisis-driven urgency. I had been developing a comprehensive solution during regular sprints, so we were ready when senior management finally allocated resources.
Research: Used support tickets and billing dispute details as primary data source. Each dispute included screenshots, message content, and exact cost calculations. This gave us real failure modes with business impact already quantified.
Strategy: Adopted risk elimination attitude to ensure financial exposure was removed before adding enhancement features. Chose comprehensive fix over band-aids to prevent cascading issues from partial implementations.
Development: Three-month sprint with phased delivery. Weeks 1-4 focused on risk elimination (mandatory warnings, basic preview). Weeks 5-8 built core features (intelligent counting, visual feedback). Weeks 9-12 enabled market expansion (RTL support, QA safeguards).
Validation: Partner beta testing in each target market provided feedback that synthetic testing could never match. They caught terminology issues, workflow gaps, and edge cases that would have caused problems at scale.
Launch: June 2024 deployment with immediate monitoring. Success manifested through what did not happen: no disputes, no escalations, no partner churn. The best validation for preventive design is when nothing goes wrong.
Validation & Results
Measured Outcomes:
- Risk Elimination
- ◦Zero billing disputes in 6+ months post-launch versus multiple five-figure disputes previously
- ◦Reduced financial exposure from SMS campaigns through accurate pre-send cost visibility
- ◦Eliminated recurring refund requests that had been damaging partner relationships
- Operational Efficiency
- ◦Support tickets for SMS issues decreased notably as interface became self-documenting
- ◦QA approval process streamlined with clear warnings making review straightforward
- ◦Partner self-service improved dramatically with contextual guidance at every step
- Market Expansion
- ◦Arabic and Hebrew markets now accessible through proper RTL support
- ◦Competitive parity achieved with specialised SMS platforms
- ◦Foundation laid for additional messaging channels (MMS, WhatsApp Business API)
Technical Success:
- •Character counting accuracy validated across GSM, UCS-2, and mixed encoding scenarios
- •High toggle usage for character highlighting indicated clear user value for the debugging feature
- •Zero confusion reported in post-launch support tickets about warning indicators
- •Performance maintained with debounced checking even for extended message composition
What I Learned
What Worked:
- •Using the crisis as a business case worked. Financial impact created undeniable urgency where user complaints had not moved the needle. Quantifiable loss in five-figure disputes drove prioritisation in a way that usability concerns never had.
- •Defensive design philosophy paid off significantly. Estimated labelling and comprehensive warnings prevented new issues while solving the core problem. Building for worst-case scenarios prevented the cascading issues that partial fixes would have created.
- •Constraint-driven research worked better than expected. Support tickets and billing disputes as primary data gave us real-world failure modes with business impact already quantified. We essentially crowdsourced usability testing from actual problems.
Challenges Solved:
- •Legacy system limitations preventing rich-text display in input components: Built wrapper components as interim solution while coordinating parallel system upgrade. This ensured we did not block on dependencies while still delivering the core functionality partners needed.
- •International QA gaps for RTL language validation: Partner beta testing provided better validation than synthetic testing could achieve. Real operators in Arabic and Hebrew markets caught edge cases and workflow gaps our internal testing missed.
- •Support knowledge gaps around encoding nuances: Self-documenting interface reduced dependency on support team understanding GSM versus UCS-2 encoding. The tooltips taught users directly rather than requiring support escalation.
Strategic Insight:
Prevention economics matter more than most teams realise. Reactive fixes cost multiples of proactive solutions, and early investment prevents compound costs. Simple surface features can hide significant technical depth affecting enterprise relationships. Constraints also focus innovation; limited resources forced us to build only essential features, and that comprehensive approach prevented the partial-fix problems that plague incremental work. The foundation now enables future expansion: MMS with media preview, WhatsApp Business API, template libraries with pre-validated content, eventually AI-powered message optimisation.