Design System and Visual Direction

Design System and Visual Direction

This is the durable visual specification for humans and AI coding assistants. It synthesizes the two supplied Figma files while preserving their two distinct design modes:

1. Austonian product UI — compact, high-contrast, priority-driven mobile interface.
2. Portfolio/case-study system — playful editorial storytelling with large modular compositions.

Do not blend these modes indiscriminately. Product screens optimize scanning and action; portfolio pages optimize personality and narrative.

Two additional Myanmar product references extend the product mode:

1. ShweNote learning experience — localized, content-first discovery and consumption for short Burmese book summaries.
2. Lwal Chat cooking assistant — an AI-assisted kitchen journey built around ingredients, hands-free execution, food-waste reduction, and culturally relevant wellness context.

Core design philosophy

• Clarity before decoration. Every screen answers: what happened, why it matters, and what action comes next?
• Priority is visible. Use position, contrast, labels, and status—not color alone—to express urgency.
• Structure before style. Establish information architecture and low-fidelity flow before high-fidelity polish.
• One connected day. Home, identity, jobs, classes/calendar, feed, and settings feel like parts of one student system.
• Cards are semantic groups. A card represents one coherent topic, decision, or action cluster.
• Friendly, not childish. Rounded geometry and bold color make the experience approachable while typography and spacing retain discipline.
• Evidence over gimmicks. Product and portfolio designs should explain real problems, research, flows, decisions, and outcomes.

1. Austonian Product UI

Product purpose

A unified student hub that reduces fragmented information across schedules, announcements, identity, opportunities, activities, and services. The primary UX promise is: important information is visible, prioritized, and actionable in one place.

Reference viewport

• Primary mobile frame: 402 × 874 px in the Auston file.
• A parallel portfolio prototype uses 400 × 870 px.
• Design mobile-first, but do not hard-code the interface to one device height.
• Respect safe areas and allow content scrolling above a stable/fixed navigation region.

Product color system

Use semantic tokens instead of scattering raw values. Values below are inferred from repeated Figma fills and representative screens.

| Token | Approximate value | Purpose |

|---|---:|---|

| --product-navy | #001E57 | Primary surfaces, headings, primary buttons, icons |

| --product-navy-deep | #000D27 | Maximum-contrast text or deep surface |

| --product-yellow | #FFCC03 | Brand background, emphasis, active navigation, CTA accent |

| --product-yellow-dark | #E5B300 | Pressed/hover emphasis where needed |

| --product-white | #FFFFFF | Cards and text on navy |

| --product-ink | #0E1627 | Primary body text on light surfaces |

| --product-muted | #636E82 | Secondary descriptions and metadata |

| --product-border | #CCD9F5 | Quiet dividers, outlines, inactive controls |

| --product-info-soft | #E8F2FF | Informational chips and subdued panels |

| --product-success | #1F8C57 | Positive completion/status marker |

| --product-success-soft | #E5F7ED | Success background |

| --product-danger | #B81F1F | Urgent/error text |

| --product-danger-soft | #FFE5E5 | Urgent/error chip background |

| --product-warning-soft | #FFF2DB | Warning or library notice surfaces |

Color rules

• Navy and yellow are the identity pair. Use navy for authority/action and yellow for energy/attention.
• Large product backgrounds may be yellow, but content should sit in navy or white grouped surfaces.
• Do not place small yellow text on white; contrast is insufficient.
• Status always includes a word, icon, or timeline position. Never depend on red/green alone.
• Reserve red for genuine urgency or error, not routine decoration.

Product typography

The source primarily uses Open Sans for the product UI, with some Inter in supporting/system elements.

--font-product: "Open Sans", system-ui, sans-serif;
--font-system: "Inter", system-ui, sans-serif;

Recommended implementation scale, normalized from the compact Figma frames:

| Role | Size/line height | Weight | Notes |

|---|---|---|---|

| Screen title | 24/32 | 700 | Main outcome or page identity |

| Section title | 18/25 | 700 | Classes, Due soon, Library |

| Card title | 16/22 | 700 | Course, task, job, activity |

| Strong label | 14/19 | 700 | Prominent action/field label |

| Body | 14/20 | 400 | Minimum comfortable production body size |

| Supporting text | 12/17 | 400–600 | Metadata and captions |

| Eyebrow/status | 11/15 | 700 | Uppercase sparingly |

| Navigation label | 11/14 | 600–700 | Always paired with an icon |

The Figma source contains many 8–10 px labels because of its compact mockup scale. For production accessibility, default to at least 12 px for auxiliary text and 14 px for body copy unless a tested platform convention justifies otherwise.

Product spacing

Base unit: 4 px. Favor an 8-point rhythm for structural spacing.

| Token | Value | Typical use |

|---|---:|---|

| space-1 | 4 | Icon/text micro-gap |

| space-2 | 8 | Related label gap |

| space-3 | 12 | Compact card internals |

| space-4 | 16 | Default card padding/gap |

| space-5 | 20 | Screen side padding, generous card padding |

| space-6 | 24 | Section separation |

| space-8 | 32 | Major outcome separation |

Rules:

• Default screen side inset: 20 px.
• Related label and value: 4–8 px.
• Items inside one card: 8–16 px.
• Separate major content sections with 20–24 px and a clear heading.
• Avoid equal gaps everywhere; proximity should explain relationships.

Product shape language

• Primary cards: 20 px radius.
• Compact cards/fields: 12–16 px radius.
• Buttons and status chips: pill radius (999px) or approximately half the control height.
• Large success/identity marks: circular.
• Cards are mostly flat. Prefer border/contrast and spacing over heavy shadows.
• Use a consistent 1 px quiet border for pale interactive surfaces when required.

Product layout anatomy

Safe-area inset
┌──────────────────────────────────┐
│ Header / greeting / page title   │
│ Context or notification action   │
├──────────────────────────────────┤
│ Priority summary card            │
├──────────────────────────────────┤
│ Section heading                  │
│ Primary actionable card          │
│ Secondary grouped cards          │
├──────────────────────────────────┤
│ Persistent 6-item bottom nav     │
└──────────────────────────────────┘

Navigation

Primary destinations inferred from the designs:

1. Home
2. Card / student identity
3. Jobs
4. Class or calendar
5. Feed
6. Settings

Rules:

• Use icon + visible label for every destination.
• Active destination receives a yellow filled container and navy foreground.
• Inactive destinations remain navy on white.
• Minimum touch target: 44 × 44 px.
• Preserve scroll position/state when switching primary destinations where appropriate.
• Badges need accessible text and must not rely solely on a colored dot.

Core product components

Priority summary

Shows date/context, a strong status headline such as “You’re on track,” and compact count chips. Counts communicate type as well as number.

Feature card

Navy surface, white title/details, yellow eyebrow or CTA. Use for the next or most important action—not every item.

Task list card

White surface with rows containing title, due metadata, semantic status chip, and optional trailing action/icon. Keep row alignment consistent.

Notice card

Warm soft background, prominent yellow icon tile, short title, and one supporting sentence. Use for contextual information rather than critical errors.

Status chip

Short label inside a soft semantic background. Examples: URGENT, 3 DAYS, IN REVIEW. Use uppercase only for very short labels.

Progress timeline

Vertical ordered states with completed/current/upcoming markers and human-readable dates or descriptions. Current status is emphasized with text and fill, not only marker color.

Primary action

Full-width navy pill with white semibold/bold label. Yellow CTA may be used inside navy feature cards. Use one dominant action per decision region.

Success state

Large circular navy mark with green check, direct outcome heading, concise explanation, status/progress card, then a clear next action. Celebration must not hide operational status.

Product content voice

• Direct and calm: “Application sent,” “You’re on track,” “Due soon.”
• Prefer useful specifics: course, room, lecturer, time, status, next step.
• Avoid corporate filler, excessive exclamation marks, or ambiguous buttons such as “Continue” when “Back to jobs” is clearer.
• Use sentence case for most text; uppercase only compact categories/statuses.

Product interaction states

Every actionable component requires:

• Default
• Hover where pointer input exists
• Pressed/active
• Keyboard focus-visible
• Disabled
• Loading
• Success
• Validation/error when applicable

Every data screen requires:

• Loading/skeleton
• Empty state with next action
• Partial data
• Failure with retry or recovery
• Offline/stale-data communication when relevant
• Permission-denied state

Product accessibility

• WCAG AA contrast for text and essential controls.
• Do not copy the smallest mockup text sizes directly into production.
• Keyboard order follows visual order.
• Visible focus ring must contrast with both yellow and navy surfaces.
• Icons have accessible names when meaningful and are hidden when decorative.
• Forms use persistent labels, instructions, inline validation, and error summary where useful.
• Motion respects reduced-motion preference.
• Dynamic status changes are announced appropriately to assistive technology.

2. Portfolio and Case-Study System

Visual personality

Playful editorial modernism: rounded geometric type, muted academic colors, dotted-paper texture, oversized statements, modular cards, and alternating full-width color fields. The system should feel authored and memorable, not like a generic SaaS template.

Portfolio color system

| Token | Approximate value | Purpose |

|---|---:|---|

| --portfolio-mint | #B9D9CE | Main canvas/background |

| --portfolio-green | #203F35 | Deep sections, text, footer, route card |

| --portfolio-green-2 | #5C8F7F | Supporting blocks and accents |

| --portfolio-cream | #F7F3EC | Primary light surface |

| --portfolio-sand | #F1E3BE | Warm accent/card |

| --portfolio-blue | #8EA8C2 | Graphic-design route and research sections |

| --portfolio-yellow | #F8C900 | Links, annotations, decisive accent |

| --portfolio-ink | #1E4045 | Dark text on light fields |

The palette is intentionally muted except for yellow. Do not introduce bright gradients, glassmorphism, or neon effects.

Portfolio typography

Primary display family: Fredoka, especially Bold and Medium. Supporting/system data may use Inter.

--font-display: "Fredoka", "Arial Rounded MT Bold", system-ui, sans-serif;
--font-support: "Inter", system-ui, sans-serif;

• Hero display: roughly 64–68 px desktop, bold, compact line height.
• Major case-study section heading: 36–46 px desktop.
• Card/route title: 24–32 px.
• Body: 18–23 px with comfortable line height.
• Labels/annotations: 12–16 px, bold or medium.
• Use rounded typography for personality, but keep long research/body passages in a highly readable size and measure.

Responsive type should use clamp() and preserve hierarchy rather than scaling every size proportionally.

Portfolio composition

• Desktop reference frame: 1280 px wide.
• Use generous outer margins around 48 px and large sectional padding.
• Hero is an asymmetric two-column composition: message/identity left, geometric capability panel right.
• Route chooser is one large cream container holding two contrasting route cards.
• Sticky/footer-like navigation anchors the composition at the bottom.
• Case studies alternate full-width cream, blue, mint, and deep-green sections.
• Modular evidence cards use 2–5 column arrangements depending on meaning.
• Use the dotted grid texture sparingly as a canvas cue; maintain contrast and avoid visual noise behind body text.

Portfolio route model

• Graphic Design: blue field, brand/UI/artwork emphasis.
• Computer Science: deep-green field, web/AI/open-source emphasis.
• Shared geometry makes both routes feel related; distinct fill creates immediate orientation.
• Route CTAs are contrasting rounded blocks with directional arrows.

Case-study narrative

Use this sequence:

1. Project title, one-sentence definition, role/context, and artifact preview
2. Problem statement and why it matters
3. Research method and evidence
4. User insights/personas
5. Design system and principles
6. User flow/information architecture
7. Low-fidelity structure
8. High-fidelity screens with rationale
9. Final product showcase
10. Outcome, limits, and next steps

The Austonian case study specifically demonstrates:

• Fragmented information as the central problem
• Research before pixels
• Student interviews and quantified findings
• Different habits but a shared trust problem
• Clear hierarchy for headings, labels, body copy, and navigation
• Color tokens with semantic roles
• Components such as status pills, action pills, content cards, and navigation items
• Priority flow: user app → scan today → open priority → view context → take action
• Low fidelity to settle structure, then high fidelity to signal priority with color

Portfolio component language

• Large rounded panels with 24–40 px radius
• Capability tiles mixing rounded rectangles and a circle
• Cream annotation strips with compact colored labels
• Alternating research cards in green, blue, and cream
• Numeric evidence blocks with large bold percentages
• Device mockups presented as evidence, not decorative floating glass cards
• Thin rules and small metadata for editorial rhythm

Portfolio motion

If implemented:

• Keep transitions short and purposeful, approximately 150–250 ms.
• Capability tiles may shift slightly on hover; never compromise readability.
• Route cards can reveal arrow movement or modest fill changes.
• Case-study sections may enter with subtle opacity/translation only.
• Respect reduced motion and avoid scroll-jacking.

3. Myanmar Content and AI Assistant Patterns

These patterns synthesize the supplied ShweNote v4.3 and Lwal Chat case studies. Reuse their product logic and user-centered flow principles; do not reproduce their branding, illustrations, screen compositions, or proprietary assets.

Shared product principles

• Local context is part of usability. Burmese language, culturally familiar categories, readable text shaping, and local mental models are product requirements—not a translation pass at the end.
• Lead with a user job. ShweNote starts from finding and completing useful learning; Lwal Chat starts from deciding and cooking with what is available.
• Content and action must connect. A card should lead to the next meaningful step, not a decorative detail page.
• Progress should survive interruption. Reading, listening, scanning, and cooking are resumable journeys with visible state.
• AI needs a visible contract. Explain what the assistant inferred, which inputs it used, and what the user can change.
• One strong action per state. Discovery, detail, preparation, active use, and completion each need a distinct primary CTA.
• Reduce cognitive load progressively. Show a small decision first, then reveal detail when it becomes relevant.

Burmese localization rules

• Design with real Myanmar strings from the first wireframe; translated labels often occupy more vertical space than English labels.
• Prefer clear everyday Burmese over literal technical translation.
• Keep line height generous enough for Myanmar stacked marks and test clipping on Android and web renderers.
• Never truncate a critical title, action, health label, quantity, or instruction without an accessible expansion.
• Pair unfamiliar icons with text until testing proves the meaning is understood.
• Support mixed Burmese/English titles, numbers, units, author names, and product terms without breaking alignment.
• Test text scaling, narrow devices, offline/stale content, and low-bandwidth media behavior.

ShweNote content experience

ShweNote is a mobile book-summary product focused on helping Myanmar readers gain key ideas in roughly 15–30 minutes. The reusable design lesson is a calm, content-led hierarchy that makes discovery, evaluation, and continued consumption effortless.

Information architecture

Home / Discover
├── Continue learning
├── Recommended and new summaries
├── Topics / categories
├── Search
├── Library / saved
└── Profile / subscription / settings

Book summary
├── Cover, title, author, topic
├── Value proposition and duration
├── Read / listen primary action
├── Summary structure or chapters
├── Save / download
└── Related learning

Primary learning flow

Screen priorities

Home

1. Continue the most recent item.
2. Surface a small number of relevant recommendations.
3. Expose topic navigation and search.
4. Keep promotional content secondary to learning continuity.

Summary detail

• Establish trust quickly: title, author, source/book context, estimated time, format availability.
• Use one dominant Start, Continue reading, or Continue listening action based on state.
• Separate the product's summary from the original author's work and make provenance clear.
• Let users save/download without competing with the primary consumption action.

Reader and audio player

• Remember position automatically and show remaining time/progress.
• Keep typography controls, playback speed, chapter navigation, and download state easy to reach but visually quiet.
• Avoid card-heavy layouts inside focused reading; use a stable content column and restrained chrome.
• Synchronize read/listen progress when both formats represent the same structure.

ShweNote components

ContinueLearningCard
BookCover
SummaryCard
TopicChip
DurationBadge
FormatToggle (Read / Listen)
ReadingProgress
ChapterList
AudioMiniPlayer / FullPlayer
SaveButton / DownloadState
SubscriptionGate

ShweNote states and metrics

• States: new, started, downloaded, completed, locked/subscriber-only, unavailable/offline.
• Empty library: recommend how to save the first summary.
• Interrupted playback: provide an obvious resume action and last-known position.
• Measure discovery-to-start, completion rate, resume rate, read/listen switching, saves, and unsuccessful searches.

Lwal Chat kitchen assistant

Lwal Chat turns daily kitchen uncertainty into an assisted cooking flow. Its distinguishing capabilities are an AI Fridge Scanner to reduce waste, hands-free voice cooking for multitasking, and a culturally grounded Dat-Sar Status for traditional body-balance context.

Information architecture

Home
├── Scan ingredients
├── Ask what to cook
├── Saved / recent recipes
├── Dat-Sar status
└── Profile, preferences, safety settings

Recipe journey
├── Suggested recipes and reasons
├── Ingredient match / missing items
├── Dietary and Dat-Sar context
├── Preparation
├── Hands-free cooking mode
└── Completion / leftovers / save

Fridge-to-meal flow

The ingredient-review step is mandatory. Computer vision is uncertain; users need editable detections and a clear way to add missed items before recommendations are generated.

Conversational flow

Chat should produce structured, tappable recipe results rather than long prose. Preserve conversation context, but keep active constraints—diet, allergies, available time, servings, disliked ingredients—visible and editable outside the message stream.

Hands-free cooking mode

• One instruction per step with large type and high contrast.
• Voice commands: next, back, repeat, set timer, how much, and stop.
• Always provide equivalent touch controls; voice is an enhancement, not the only path.
• Keep the screen awake while active, show timers persistently, and allow recovery after interruption.
• Confirm risky interpretations and distinguish listening, processing, success, and failure states visually and audibly.
• Avoid chat bubbles during active cooking; use a step player optimized for distance and messy hands.

Dat-Sar status

• Present Dat-Sar as cultural wellness guidance, not medical diagnosis.
• Explain why a recipe is marked supportive, neutral, or potentially unsuitable.
• Let users override preferences and see the ingredients driving the status.
• Do not claim treatment, prevention, or clinical certainty.
• Allergies, medical restrictions, and food-safety rules take priority over traditional guidance.

Lwal Chat components

ScanCapture
IngredientDetectionList
ConfidenceFlag / EditIngredient
ConstraintBar
RecipeMatchCard
IngredientMatchMeter
MissingIngredientList
DatSarStatusChip / ExplanationSheet
CookingStepPlayer
VoiceStateIndicator
MultiTimerTray
LeftoverActionCard

AI states and recovery

• Scanning: permission request, camera unavailable, low light, uncertain item, duplicate detection, no ingredients found.
• Chat: thinking, partial result, clarification, offline, safety refusal, retry.
• Voice: idle, listening, processing, command understood, command ambiguous, microphone denied.
• Recipes: full match, substitutions available, essential ingredients missing, dietary conflict, Dat-Sar caution.
• Never discard user corrections when the model or scan is rerun.

Cross-product flow rules

| Moment | ShweNote | Lwal Chat | Design rule |

|---|---|---|---|

| Entry | Continue or discover | Scan or ask | Lead with the highest-frequency job |

| Context | Title, topic, duration | Ingredients, time, diet, servings | Make decision inputs visible |

| Choice | Read or listen | Select recipe | Offer few meaningful alternatives |

| Active mode | Reader/player | Cooking step player | Remove unrelated navigation and noise |

| Resume | Position and progress | Step and timer state | Persist state automatically |

| Completion | Key insight / next summary | Save recipe / leftovers | Close the loop with a useful next action |

| Trust | Provenance and format | Detection confidence and explanation | Show why the system recommends something |

Visual translation

Use the established product tokens in this document as the vault's implementation baseline. When adapting these references:

• Give content imagery and food photography a supporting role; text and actions must remain legible without the image.
• Use rounded cards for summaries, recipes, and editable ingredient groups—not for every paragraph.
• Use compact chips only for short, scannable metadata such as duration, topic, match, diet, or status.
• Reserve a strong accent for primary action, current progress, and active voice/scan state.
• Use bottom navigation for peer-level destinations; use a focused full-screen mode for reading, listening, scanning, and cooking.
• Do not infer or copy exact brand colors from compressed portfolio imagery. Create semantic, accessible tokens for the implementation context.

UX validation tasks

Test with real Burmese content and representative devices:

1. Find a specific book and begin listening in under one minute.
2. Resume an interrupted summary without searching for it again.
3. Scan five ingredients, correct one false detection, and add one missed item.
4. Find a recipe that respects an allergy and a 30-minute limit.
5. Complete three cooking steps using only voice, then recover using touch.
6. Explain what a Dat-Sar label means and change the preference.
7. Recover from denied camera/microphone permission and from offline mode.

Success measures include task completion, time on task, correction rate, comprehension of AI confidence, unsafe-recommendation rate, resume success, and perceived trust.

4. Responsive Translation

Product UI

• Keep the one-column mobile hierarchy through tablet unless content genuinely benefits from columns.
• On wider screens, center the product shell or evolve into a sidebar layout while preserving destination order and semantics.
• Never stretch cards to unreadable line lengths.
• Bottom navigation may become a left rail on desktop, with labels still visible.

Portfolio

• Desktop two-column hero becomes a single column below approximately 800 px.
• Route cards stack vertically on narrow screens.
• Research grids reduce from 3–5 columns to 1–2 based on content.
• Maintain large typographic drama with clamp(), but prevent orphaned single words where possible.
• Reorder by narrative meaning, not merely original x/y coordinates.

5. Implementation Guidance for AI Assistants

When asked to implement these designs:

1. Inspect the target screen and existing code before writing components.
2. Identify whether the task uses product mode or portfolio mode.
3. Create semantic tokens for colors, typography, spacing, radii, borders, and states.
4. Build reusable primitives before assembling pages.
5. Use CSS Grid/Flexbox or platform-native layout—not absolute positioning copied from Figma.
6. Preserve content hierarchy and interaction states before polishing decoration.
7. Implement responsive behavior from relationships, not fixed coordinates.
8. Test keyboard, contrast, text scaling, loading/error/empty states, and mobile widths.
9. Compare the running UI with Figma using screenshots at representative viewports.
10. Report visual deviations and accessibility-driven changes explicitly.

Suggested component inventory

ProductShell
ProductHeader
PrioritySummary
FeatureCard
TaskList / TaskRow
NoticeCard
StatusChip
ProgressTimeline
PrimaryButton / SecondaryButton
BottomNavigation / NavigationItem
EmptyState / ErrorState / Skeleton

PortfolioShell
PortfolioHero
CapabilityPanel / CapabilityTile
RouteChooser / RouteCard
CaseStudySection
ResearchMetric
InsightCard
ProcessStep
DeviceShowcase
PortfolioFooter

ContentHome
ContinueLearningCard / SummaryCard
SummaryDetail
Reader / AudioPlayer
ScanCapture / IngredientDetectionList
RecipeMatchCard
CookingStepPlayer / VoiceStateIndicator
DatSarStatus / ExplanationSheet

Do not

• Do not apply portfolio Fredoka typography inside operational product screens.
• Do not turn every product surface navy or every portfolio surface mint.
• Do not copy hundreds of unique Figma radii and font sizes literally; normalize them into tokens.
• Do not treat the Figma frames' absolute positioning as production layout.
• Do not introduce generic purple gradients, glass cards, excessive shadows, or stock dashboard styling.
• Do not shrink production body text to 8–10 px because the mockup uses compact labels.
• Do not use color as the only status or navigation signal.
• Do not invent desktop product behavior without preserving the product hierarchy.
• Do not present AI detections as facts when confidence is uncertain.
• Do not place allergies, food safety, or medical restrictions below personalization preferences.
• Do not force voice-only interaction in the kitchen or hide essential controls inside chat.
• Do not treat Burmese localization as English UI with translated labels.

6. Source Audit

Auston file

• Pages: Case Study, LF, HF, Draft
• Inspected target: HF / Application Submitted through node 181:63
• High-fidelity product frames: approximately 402 × 874 px
• Dominant product colors: white, navy, yellow, ink, muted blue-gray
• Dominant product family: Open Sans
• Local assets: blue paint-style scale; no reusable variables detected
• Many elements are positioned absolutely; translate relationships into responsive layout in code

Untitled portfolio file

• Page: Website
• Contains a 1280 × 920 landing page, two long portfolio routes, a 1280 × 7500 Austonian case study, and 400 × 870 product screens
• Dominant portfolio colors: mint, deep green, cream, blue-gray, sand, yellow
• Dominant portfolio family: Fredoka, with Inter supporting UI/system text
• Paint styles include blue, yellow, gray, green scales and interaction-state naming
• No local variables or formal Figma components detected in the inspected file

Design-system maturity recommendation

The visual language is strong, but the source files rely on repeated raw styles and frames rather than a mature token/component library. For production work:

• Consolidate colors into semantic variables.
• Normalize the typography scale.
• Normalize repeated radii and spacing.
• Turn navigation items, buttons, chips, cards, fields, and status rows into components with variants.
• Define hover, active, focus, disabled, loading, success, and error states.
• Bind tokens to components and align names with implementation code.

Behance references

• ShweNote v4.3: book-summary mobile product by Ye Win Aung, published 21 July 2026. The supporting portfolio material identifies content hierarchy, Burmese localization, and mobile learning experience as core product-design concerns.
• Lwal Chat: culinary assistant case study by Min Thway Nge and Ye Win Aung, published 28 July 2026. Its stated core features are AI fridge scanning, hands-free voice cooking, and culturally contextual Dat-Sar status.
• Behance exposed project descriptions and metadata during inspection, while some long-form image panels were not available as semantic page content. Exact colors, typefaces, and pixel measurements from those image panels are therefore deliberately not asserted here.

Sources

• Auston Figma file
• Portfolio and Austonian case-study Figma file
• ShweNote v4.3 Behance case study
• Lwal Chat Behance case study
• Inspected and synthesized on 2026-08-12.

Knowledge connections

• Vault Knowledge Graph
• All Here
• Prompt
• System Design