Years of working screen-level UI
Fragments, XML, MVP and several visual generations still delivered accounting and tax behaviour.
Design System · at ANNA Money
Design decisions that ship as code.
Tiger turned recurring product UI into a governed Compose system that teams could adopt while legacy XML screens remained in production.
SpecialtyDesign System
Formal role or capacityContractor · offer title: Android Developer
Personal scopeAndroid implementation patterns, templates, reviews, and adoption guidance
SystemTokens · components · versioned families
01 · context
Compose alone would not create consistency.
Changing the rendering toolkit without shared semantics would let every feature recreate states, spacing and behaviour differently.
A reusable delivery layer
New and changing features needed stable component APIs without waiting for a complete rewrite.
02 · ownership
From design semantics to product adoption.
The role combined component implementation, design collaboration and the conventions needed for feature teams to consume the system.
Android-side Tiger work
- Component semantics and variants
- Compose implementation and review
- Feature adoption guidance
- Compatibility conventions
Shared vocabulary
- Semantic intent
- States and accessibility
- Product-specific variants
- Evolution feedback
Real adoption
- Accounting and payments
- Tax and accounting
- Forms and navigation
- Legacy coexistence
03 · system
A layered system turns intent into reusable product behaviour.
Android Tiger and Flutter Barracuda are separate platform implementations aligned by shared design intent.
Semantic tokens
Themes, type, icons, spacing and content-description conventions.
→
Reusable behaviour
Controls, cells, cards, banners, forms, navigation and product variants.
→
Incremental adoption
Compose features consume Tiger while untouched XML screens remain available.
04 · decisions
Adoption before purity.
The system was designed for a mature application where product delivery could not wait for architectural completion.
Encode semantics, not screenshots
Component APIs represent recurring states and intent instead of one screen composition.
Keep legacy compatibility
Fragment-compatible Compose entry points let teams migrate for product reasons, not framework deadlines.
Review usage as part of the system
A component succeeds only when product engineers can apply it consistently.
Protect shared behaviour
Reusable instrumentation and visual coverage reduce cross-feature regressions.
Keep platform implementations honest
Do not present Android Tiger and Flutter Barracuda as one shared codebase.
05 · evidence
One system across different product jobs.
Public visuals show product breadth; they do not claim individual authorship of every displayed screen.
06 · outcome
Shared rules became reusable Android delivery infrastructure.
Android engineers adopted the patterns, templates, and utilities for new work while legacy XML screens remained available.
DESIGN
Shared semantics become stable engineering APIs.
DELIVERY
New work can use Compose/Tiger while legacy screens remain production-safe.
BOUNDARY
Personal implementation, review, and adoption guidance are separated from team-owned product delivery.
Evidence & NDA boundaryThis case uses approved public visuals and a sanitised technical narrative. Private source, endpoints, credentials, configuration, customer data, and proprietary schemas are excluded.
Work together
Explore a role or project
Target role · Staff Mobile Engineer (Android + Flutter)
Worldwide remote · English / Russian
Novi Sad, Serbia · hybrid possible