SMANAGER / FLAGSHIP CASE STUDY
From field evidence
to product decisions
How usability testing, merchant research, business reality and product strategy shaped a mobile business platform.
02 / PROJECT AT A GLANCE
One product.
A living research practice.
sManager became the place where I learned to connect field evidence, usability, business reality and product decisions.
The work spans research, testing, audits and design across a broad mobile business platform. Due Tracker carries the deepest evidence chain—not the only work.
Can I show how real user and business evidence changed the product—not just prove that research happened?
Research, synthesis, product thinking, interaction design and validation across sManager.
Observe → Diagnose → Decide → Design → Validate. Every major UI should have a reason to exist.
03 / REAL USABILITY TESTING
The shop was the research lab.
These rounds happened around real shops, paper ledgers, phones, customers and operational constraints—not in an abstract lab environment.
Field evidence first. Then diagnosis. Then design.
Why field work mattered
Field work changed the unit of analysis.
Some friction belonged to the interface. Some belonged to language, bookkeeping habits, support, field operations or trust. Research helped us tell the difference.
“The app was only one part of the experience.”Two rounds · two learning loops
What we saw in the field changed both the product and how we ran the next study.
SPRINT 2103 · 25 JAN 2021
22 → 8 → 4 → 3
Contacted → agreed → selected → tested
Selected findings- Day-end cash and profit were missing
- SMS charge timing was not understood
- Alert was tapped instead of the CTA
- Previous-day entries were impossible
- A double-SMS defect surfaced
SPRINT 2105 · 8 FEB 2021
7 shops
Uttara field visits · mostly EMI users
Selected findings- Minus sign in stock was missed
- জমা / নতুন বাকি caused confusion
- Contact name could not be edited safely
- Stock and multi-delete needs surfaced
- EMI settlement promise differed from reality
Before the session
Preparation was treated as part of research quality—not admin.
Define objectives
What must we uncover, what is unknown, what is already working, and what decision will research support?
Recruit the right users
Create criteria, start with a larger contact pool, confirm location and time, and account for drop-off.
Write non-leading questions
Use neutral language that lets the participant show their real behaviour.
Prepare prototype + tasks
Set realistic tasks around a prototype that can answer the research question.
Plan logistics
Plan the visit around operating conditions, people and practical constraints.
Dry run + privacy
Test the session plan, protect participant privacy and make consent clear.
Testing milestones + report anatomy
- Scope
- Prepare
- Recruit
- Pilot
- Conduct
- Synthesize
- Report
- Iterate
Anatomy of the actual sprint reports
Sprint report structure
- Observation
- Merchants could not safely correct a contact while protecting the ledger’s history.
- Why it matters
- A familiar operational task carried a trust and recovery risk.
- Research-led action
- Separate contact correction from transactional history and confirm the effect.
- Status
- Tracked as a product decision for validation.
Diagnose before designing
Not every reported problem belonged to the same layer.
Research separated the evidence before deciding whether interface, product, technical or business work needed to change.
UX findingsWhat was hard, missed, confusing or misunderstood in the experience.
User requirementsWhat people needed to complete work in their own bookkeeping context.
Technical findingsWhat required a system, data or delivery response—not a visual patch.
Business findingsWhat operations, policy, access or trust conditions shaped the right decision.
04 / Flagship case
sManager
Due Tracker
Helping small merchants understand dues, communicate reminders, and preserve the integrity of a working ledger.
Dues are a relationship, not only a number.
A merchant needs to understand where money moved.
The system must preserve clear state, action and recovery.
Show the past, present and next state of money and work.
Protect consequential actions and make recovery possible.
Explain automation, delivery and failure—not only success.
Design for real access, language and channel conditions.
Let merchants record work when it happened, not only when the app permits it.
05 / RESEARCH EVIDENCE → UI DECISIONS
Show me the finding.
Then show me what changed.
Observed“When someone deposits money, the previous amount isn’t shown.”
DiagnosedA generic success state hid ledger context. With money, success had to explain the previous state, the change, and the resulting balance.
DecisionPrevious → New transaction → Current balance
পূর্বের জমা ৳২০,০০০
নতুন জমা ৳৩০,০০০
ব্যালেন্স (জমা) ৳৫০,০০০
ছবি যোগ করুন
Observed · Sprint 2103A merchant could not enter a transaction for a previous day.
Business realityA working ledger must reflect when the work happened.
DecisionMake বাকির তারিখ explicit, rather than silently forcing today.
মোট ব্যালেন্স ৳৬১,২০০
মোট ব্যালেন্স ৳৬১,২০০
মোট ব্যালেন্স ৳৬১,২০০
Observed → Diagnosed → Business context → Decision → UI → Validation
06 / INSIGHT TO PRODUCT STRATEGY
UT found the friction. Business shaped the decision.
Previous amount missing after a deposit
Money-state problem
Previous → new transaction → current balance
Can merchants read the change with confidence?
Previous-day entry was blocked
Real bookkeeping habit
Add বাকির তারিখ as an explicit date decision
Can past activity be recorded truthfully?
Reminder delivery felt unreliable
UX + business + access
Expose reminder set, SMS sent and SMS failed states
Can a merchant understand what automation did?
Online Store adoption signals varied
Opportunity and trust conditions
Use research to shape the bridge, not claim a universal outcome
What remains uncertain after each survey wave?
Repeated qualitative signals, documented counts and source-bounded product states.
Outcome, adoption and causal impact remain unclaimed when the source does not establish them.
07 / Existing full case · research bridge
sManager
Online Store
Two survey waves informed an opportunity map without collapsing different response sets into an invented total.
Wave 1 responses9
Wave 2 responses2
Survey waves1
Documented non-adopter
08 / PRODUCT BREADTH
Research was deep.
Product work was broad.
The archive spans 21 sManager product areas.
Inventory · Sales · POS Orders
Digital Collection · Payments · EMI · Banking
Online Store · Delivery · Top-up · Services
Tracker · Dashboard · Reports
09 / EVIDENCE INTEGRITY
Evidence earns trust.
Judgement earns impact.
Counts and scoped source facts.
Repeated qualitative signal.
Used with explicit limitation.
Not claimed.
Aggregated or excluded.
- Removed identities, exact addresses, recordings, transaction details, phone numbers and private URLs.
- Kept survey waves separate instead of inventing a unique-participant total.
- Separated current product context from historical project evidence.
- Left outcomes unclaimed where release or analytics evidence was missing.