POCO Myanmar
A cross-platform B2B enterprise ecosystem that unifies three disconnected data sources: Odoo ERP at the corporate level, field sales inputs from teams spread across multiple regions, and manual Excel sheets from external distributors into one connected, validated system.
250 - 500
Active users, daily operations
6
Distinct role interfaces, 1 app
4 months
Concept to live deployment
3
Data pipelines into one system
What I do
I was the only designer on the project, responsible for both design execution and project management from kick-off to delivery.
Discovery & Stakeholder Consultation
Mapped all six user workflows through direct consultation with Astra Wealth stakeholders. Storyboarded each user flow scenario before touching any screen design.
Concept Validation via Wireframes
Built low-fidelity wireframes first to validate product ideas with stakeholders before committing to high-fidelity design. Caught major flow issues early.
Agile Sprint Design & Development
Ran sprint-by-sprint cycles: design, build, test, deliver, retrospect. Iterated based on real feedback each sprint rather than big-bang delivery.
Cross-functional Project Management
Coordinated between my dev team, Astra Wealth stakeholders, and the Odoo ERP team. Handled user testing sessions, timeline, and all integration milestones.
CONTEXT
The Problem Space & Business Context
Astra Wealth, an authorized distributor for POCO in Myanmar, needed a unified digital architecture to manage its massive scale. Their existing operations suffered from fragmented tracking, a lack of real-time visibility, and severe data mismatch risks.
The system had to seamlessly pull real-time data from an Odoo ERP portal while simultaneously synchronizing transactional inputs coming from field sales teams spread across multiple regions and divisions.
What Astra Wealth Needs
A sales and inventory management system: a web admin portal for HQ and a role-based mobile app for all 250–500 field staff across Myanmar's divisions and regions.
The Core Challenge
Six completely different job roles. Each needs a different interface, different data access, and different responsibilities, all in one product.
Key Integration
The system needed real-time data sync in two directions, pulling stock and shop data from Odoo ERP into the admin portal, and syncing mobile sales back to the same portal simultaneously. Any data lag would break inventory accuracy.
It was not "make a nicer dashboard." It was: how do you design a system that pulls from three conflicting data sources, enforces strict validation at every input point, and remains usable by both a corporate director reviewing strategy and managing 6 hierarchies roles?
Logic thinking and design approach
6 user roles for mobile apps. All needing different data from the same system.
The sales hierarchy defines what data each person is authorized to see, what actions they can take, and how much of the organization is visible to them. Before designing any screen, I mapped how data controls flow downward through each tier because the wrong structure here cascades into every decision that follows.
Sale Director
Regional Sale Manager
Area Sale Manager
Trainer
Sale Supervisor
Promoter
Sale Director
Regional Sale Manager R
Area Sale Manager A1
Trainer T1
Sale Supervisor S1
Promoter P1
Different functionalites of 6 user roles
Sale Director (Admin)
All regions, All levels
Views full system performance. Top of hierarchy.
No KPI
Regional Sale Manager
1 region
Oversees all levels below. One RSM per region.
Monthly KPI
Area Sale Manager
1 division
Oversees trainer and below. Multiple ASMs per division allowed.
Monthly KPI
Trainer
Assigned staff
Same scope as ASM but focused on performance review, not sales target.
No KPI
Sale Supervisor
1+ shops
Sells directly and manages promoters. Submits stock-in IMEI per shop.
Monthly KPI
Promoter
1 counter
Sells at assigned counter. Scans and submits received IMEI items.
Monthly KPI
I didn't build 6 apps. I designed a 1-to-1 Device-to-Role validation flow.
Building separate apps for each role would multiply maintenance costs, create inconsistent experiences, and make updates painful. Instead, I used role ID + device ID at login to gate access. The app matches the correct interface per role from a single codebase. One device is registered to one role, and there is no sharing, no workarounds.
Outcomes
Unauthorized access reduced to 0% from launch. Maintenance stays manageable with one codebase. Any role update deploys once, not six times.
The Login & Authorization Flow:
For role login, I decided to use the same screen login pattern with different role id authorization.
Login
Here are the same mobile application home screen displaying different UI elements based on who logs in.
Sale Director
Regional Sale Manger
Area Sale Manager
Trainer
Sale Supervisor
Promoter
Logic thinking and design approach
IMEI Scanning Logic. Promoter vs Supervisor
Both promoters and sale supervisors scan IMEI when stock arrives. But the interfaces are intentionally different.
Promoter: Scan & Submit
Scans IMEI for their assigned counter only. No checklist feature. Includes stock-in history for tracking wrong submissions.
Sale Supervisor: Scan & Checklist
Same IMEI scan flow, but with an added IMEI checklist. Supervisors handle multiple shops alone so a checklist speeds up bulk submission with no duplication risk.
Why I don't add checklist for promoters?
Multiple promoters share one shop. If all of them could check a shared IMEI list, they'd check the same items, creating duplicate submissions and wrong inventory data. Supervisors get the checklist because they work solo across multiple shops and no duplication risk exists there.
Outcomes
IMEI submission accuracy held. No duplicate stock-in entries. Unauthorized items reaching shop counters dropped to near zero.
No IMEI checklist for promoters. It is intentional, not an oversight.
Promoter Stock Scan and Submit
Sale Supervisor Scan and Submit
The reasons why promoters and sale supervisor don't allow to type IMEI
The mobile app restricts data input fields during field stock-ins. Field workers cannot arbitrary type numbers; they must scan or submit IMEIs that match the master inventory whitelisted for their assigned shop or counter.
Logic thinking and design approach
3 types of stock transfer for admin portal.
The unique IMEI number is the critical anchor for tracking stock, managing data, and verifying transfers across the entire application ecosystem. Inventory movements follow three distinct operational pathways, requiring a unified interface in the Web Admin Portal to track varied data ingestion models cleanly:
Type 1: Counter to Counter
Stock items can be transferred between counters that are under the same shop.
Type 2: Shop to Shop
Stock items can be transferred between shops.
Type 3: Wholesaler to Retail
The wholesalers sell to external retail shops are transferred as sold qty to admin portal, which is the highest risk channel because it is done by manual Excel upload.
Pre-ingestion pipeline
The highest-risk channel (wholesaler Excel uploads) gets a pre-ingestion pipeline: the file is parsed and previewed before anything commits. Duplicates and format errors are flagged in place. Successful IMEI validations with wholesalers' stock from Odoo ERP are transferred to created retail shops. Invalid IMEIs are logged out with an error message line for Excel.
Upload Excel File For Wholesaler Transfer
Parsing, Validating and Result States
Outcomes
External distributor files are validated before they touch inventory. Zero reconciliation leakage between Excel supplier data and the Odoo database.
It is not done yet after validating IMEI and creating retail shop in "Shop Management".
As wholesaler stock items are sold to retailer shops, the uploaded Excel data should automatically deduct the sold quantity from the wholesaler’s stock balance. At the same time, the deducted quantity must match and be added to the incoming stock quantity of the retailer shop.
Validating and Transferring Flow
Logic thinking and design approach
KPI setting decoupled from shop/counter assignment.
First Idea Design Approach
Originally, KPI was set when assigning a promoter to a shop counter. This seemed logical until testing revealed: when a promoter moves to a different counter, the KPI breaks and it stays tied to the old counter.
Second Iteration Design Approach
Moving KPI configuration to the role section fixed this. Admin can check any role's KPI directly without hunting through shop assignments.
Outcomes
KPI data stays accurate across reassignments. Admin can access any role's KPI in one click without browsing shop lists.
Logic thinking and design approach
Merged stock analysis into shop management, removed the separate tab view.
First Idea Design Approach
Initial design had three separate menu tabs: Shop Level, Counter Level, and IMEI Tracking. In testing, a shop with many counters filled the entire table with one shop's data. Admins couldn't scan across all shops quickly.
Second Iteration Design Approach
I merged shop-level and counter-level stock analysis directly under each shop in shop management.
Shop Level Stock Analysis
Counter Level Stock Analysis
IMEI Tracking
Outcomes
Admins can scan all shops at a glance. IMEI tracking and stock checks now happen in one place, not three tabs. Processing speed increased noticeably.
Since the items are more than one qty, admin can check all imei lists by clicking on "View IMEI".
Logic thinking and design approach
Shop management options: Create counters or No counters
Admin can assign promoters to shops that have counters. Shops that don't have counters are assigned to sale supervisors and one sale supervisors can be assigned more than one shops.
Counter Assignment
No Counter Assignment
Takeaways
What I've learned
Logic first
In high-stakes operational systems, the interface logic of who sees what, what inputs are valid, and what happens on failure, matters more than visual design. Get it right before touching a screen, and everything built on top is structurally sound.
Error as feature
When one bad IMEI cascades through an ERP, a clear failure response is what makes the system trustworthy, not just functional. Designing error states with the same care as success states changed how I think about every input field.
Constraint is design
The most effective UX decisions in this project were constraints: scoped selection menus, whitelisted inputs, and boundary validation. Preventing wrong actions through design is more reliable than expecting users to catch their own errors.
What I'd do differently
Most user validation happened during client review sessions, not with actual field Promoters. I'd push for structured field testing earlier, even informal walkthroughs with Supervisors in real store conditions to catch friction that only surfaces under actual working pressure.
What comes next
Version 2 would include a good automation report system to admin device, without needing to open admin portal everytime they want to check the overall sale performance and inventory tracking.
Say hello!
I love discussing product ideas from different perspectives.