on this page

01

The Real Problem

02

My Role

03

Domain Challenge

04

Design System

05

How it Works

06

Key Decision

07

Battle Story

08

Landing Page

09

Outcomes

10

Reflection

BACK TO ALL WORKS

01 - THE Real PROBLEM

The spreadsheet was not the problem. The thinking behind it was.

When Krenovator first engaged with the client, the brief sounded familiar: replace manual Excel and Google Sheets processes with a proper web system. But within the first few client meetings, it became clear that the problem was more layered than that.
The client, a food and beverage group operating across multiple outlets in Malaysia, was not just managing ingredients. They were managing a network of relationships between suppliers, recipes, departments, brands, and outlets which all of them had to stay synchronized across a rolling month of purchasing, receiving, cooking, wasting, and counting.
The existing spreadsheets were not accidental. They were the product of years of operational refinement. Every formula, every tab, every naming convention encoded a decision someone had made for a reason. The real challenge was not building a system. It was understanding what that system needed to think.

the trigger

The client's inventory manager had already mapped out the logical flows before the first meeting. She knew what Actual COGS meant. She knew why yield mattered for every deduction. She knew that the same ingredient purchased from two different suppliers at different weights needed to appear as one item during stocktake. That level of domain precision meant the design had to keep up with the user, not the other way around.

The client's inventory manager had already mapped out the logical flows before the first meeting. She knew what Actual COGS meant. She knew why yield mattered for every deduction. She knew that the same ingredient purchased from two different suppliers at different weights needed to appear as one item during stocktake. That level of domain precision meant the design had to keep up with the user, not the other way around.

Agenticas dahcboard preview mockup

Client brief meeting, participants: 3 clients, CEO, CTO, Lead Dev, Full-Stack, Designer.

On that meeting, we discussed about the actual COGS must follow a specific formula: Opening Stock plus Total Purchases plus Transfer In minus Transfer Out minus Wastage minus Closing Stock. Every screen in the system had to respect that equation without exposing its complexity unnecessarily to operational staff who simply needed to act.

Before Agenticas - The Spreadsheet Reality

This is what managing inventory across multiple F&B outlets actually looked like. The client maintained a single Google Sheets file of IMS Sample Information with separate tabs for every operational module, such as: Item, Catalogue, Recipe, POS Code, Stock Count, Purchase Order, Item Received, Wastage, and more. Every data entry, every filter, every cross-reference between tabs was done manually. With hundreds of items, dozens of suppliers, and multiple outlets, the margin for error was enormous and the time cost was invisible until you tried to scale.

The scale problem

The spreadsheet had more than 1,000 rows of item data alone and that was before factoring in the Catalogue, Recipe, POS Code, Stock Count, and Purchase Order tabs. Each tab had to be cross-referenced manually. Each outlet had its own version. There was no single source of truth, no audit trail, and no way to run a report without building it from scratch in the spreadsheet itself.

The spreadsheet had more than 1,000 rows of item data alone and that was before factoring in the Catalogue, Recipe, POS Code, Stock Count, and Purchase Order tabs. Each tab had to be cross-referenced manually. Each outlet had its own version. There was no single source of truth, no audit trail, and no way to run a report without building it from scratch in the spreadsheet itself.

02 - My Role

I was not a UI executor. I was the only designer who had to understand everything.

My formal title was UI Designer. In practice, I was the sole design representative sitting in every client meeting alongside the CEO, PM, and Lead Developer. I was responsible for converting operational decisions made in those meetings into design direction that a UI designer could execute without confusion.

But, In Fact:

"Two UI designers rotated through the project over three months. Each transition meant rebuilding context from scratch. I was the constant."

Before any screen was designed, designers must understand the ERD!

Sprint 1 did not begin with a wireframe. It began with an Entity Relationship Diagram. Before handing off to the UI designer (me & abqary), I sat down with them to read and understand the ERD together, mapping out how Brand connects to Outlet, how Outlet connects to Department and Storage, how Item connects to Catalogue and Recipe, and how Recipe connects to POS Code and production stock. Without understanding those relationships at the database level, it would be impossible to know why the sidebar navigation needed to be in a specific hierarchy, why Catalogue is structurally different from Item, or why Production Recipe has a unique relationship to inventory stock.

Entity Relationship Diagram (ERD) : This is what I read with the first UI designer before Sprint 1 began. From this diagram came the sidebar navigation hierarchy, the module grouping logic, and the understanding of why certain screens needed to show data from multiple entities simultaneously. Domain translation from database schema to interaction logic that was the real starting point of the design work.

What I designed directly vs what I directed

The landing page at www.agenticas.ai was designed and built entirely by me from zero reference, through three CEO review rounds, to live deployment in Framer. That is the work I own end to end.
For the dashboard system, my contribution operated at two levels. In client meetings, I was the one extracting product decisions and translating them into design direction. In Figma, I briefed the UI designer verbally and through direct annotation, reviewed their output, dropped comments when something was not aligned, and designed specific screens myself when the case was too complex to delegate. The UI designer handled execution under my direction with the lead developer available for deep technical clarification on system behavior.

Parallel project context

Throughout the Agenticas project, I was simultaneously leading design for a Quran learning mobile app which is a separate client under the same company, Krenovator. My approach to managing both: that is to prioritize the primary project, delegate Agenticas execution to the UI designer I was assisting, remain the checkpoint for quality and direction via Figma reviews, and cross-check outputs regularly. When the UI designer encountered cases they could not resolve, I stepped in directly. When cases required deep system understanding, the lead developer joined the discussion. That trust-based delegation structure is what kept both projects moving.

Throughout the Agenticas project, I was simultaneously leading design for a Quran learning mobile app which is a separate client under the same company, Krenovator. My approach to managing both: that is to prioritize the primary project, delegate Agenticas execution to the UI designer I was assisting, remain the checkpoint for quality and direction via Figma reviews, and cross-check outputs regularly. When the UI designer encountered cases they could not resolve, I stepped in directly. When cases required deep system understanding, the lead developer joined the discussion. That trust-based delegation structure is what kept both projects moving.

03 - Domain Challenge

Explaining a production recipe to someone who has never worked in a kitchen is harder than it sounds.

The most difficult feature to translate into design was Production Recipe. In a standard inventory system, a recipe is a list of ingredients with quantities. You sell a dish, the system deducts those ingredients. Simple.
In an F&B operation like the client's, a recipe is more complex. Some dishes require a half-produce which a batch item made in advance, like sambal, pork lard, or waffle batter that is itself made from raw ingredients. That half-produce is both a product of the kitchen and an ingredient in other dishes. It needs to be tracked as stock, costed accurately, and deducted correctly when used.

Recipe Setup : Expandable rows reveal the full ingredient breakdown inline without leaving the list view. The Production toggle marks recipes that generate a half-produce item for stock tracking. One toggle, significant backend logic, three characters on screen.

On top of that, every ingredient has a yield percentage. If you buy 1 kilogram of lemongrass but only 700 grams is usable after trimming, every calculation in the system such as recipe cost, stock deduction, variance report, has to account for that 30% loss. One yield field in the catalogue, multiplying out across hundreds of ingredients and recipes.

Recipe full column view : Final UOM, Final Quantity, Recipe Cost, Cost Per Unit, and Inventory Name all visible at the parent row level. The cost per serving is surfaced immediately — no expansion required for the most commonly needed number.

Recipe full column view : Final UOM, Final Quantity, Recipe Cost, Cost Per Unit, and Inventory Name all visible at the parent row level. The cost per serving is surfaced immediately — no expansion required for the most commonly needed number.

How I briefed the designers

I briefed each module by first explaining the business logic in plain language, then describing what the user needed to accomplish, and only then discussing how the screen should look. Logic first, task second, visual third that sequence kept the design grounded throughout the project.
I briefed each module by first explaining the business logic in plain language, then describing what the user needed to accomplish, and only then discussing how the screen should look. Logic first, task second, visual third that sequence kept the design grounded throughout the project.

04 - Design System Decision

Choosing UntitledUI and shadcn was a product decision, not just a design preference

Before any screen was designed, the team made a foundational choice about which design system to use because we just have 2 month and maximum 3 months to complete all mockups. We don't have much time since the project was extremely complex, so this was not a decision made by the design team in isolation, but I brought this direction to the UI designer as part of the very first briefing, before Sprint 1 began. The reasoning was deliberately cross-functional, and the goal was to make sure every design decision from day one could be implemented by the dev team without negotiation.

First, we used UntitledUI

Untitledui gave the team a mature, enterprise-grade component library with consistent spacing, typography, and interaction patterns that matched the visual expectations of B2B software. It removed the cost of designing basic components from scratch and let the UI designer focus on the product-specific patterns that actually required original thinking rather than reinventing buttons, tables, and modals. But in fact, we still create our own components that matched with the goals instead of using full library from untitled UI.
Untitledui gave the team a mature, enterprise-grade component library with consistent spacing, typography, and interaction patterns that matched the visual expectations of B2B software. It removed the cost of designing basic components from scratch and let the UI designer focus on the product-specific patterns that actually required original thinking rather than reinventing buttons, tables, and modals. But in fact, we still create our own components that matched with the goals instead of using full library from untitled UI.

Next, we make it sure that our designs matched with shadcn ui components

Shadcn was the developer-facing counterpart. Because the system is built in Next.js, shadcn components map directly to what the development team would implement. The design to development handoff became significantly cleaner because the components the designer placed in Figma corresponded to components the engineer could drop into the codebase. No back-and forth about whether a component was buildable. No redesign after handoff. What was designed was what got built.
Shadcn was the developer-facing counterpart. Because the system is built in Next.js, shadcn components map directly to what the development team would implement. The design to development handoff became significantly cleaner because the components the designer placed in Figma corresponded to components the engineer could drop into the codebase. No back-and forth about whether a component was buildable. No redesign after handoff. What was designed was what got built.
Directing the UI designer to work within this paired system from the start meant that when the UI phase ended and the development team took over, they could continue building new screens in the same visual language independently, without a designer in the loop.

What I gave up

✕

Fully custom visual identity for the dashboard

✕

Unique component patterns exclusive to Agenticas

✕

Full creative control over every interaction state

What I protected

✓

Fast, clean design to dev handoff via shadcn

✓

Visual consistency developers could maintain after the design phase ended

✓

Time to focus on domain specific patterns that actually mattered

05 - How the System Works

Fourteen modules. One consistent interaction language. Every screen built to scale.

The Agenticas dashboard covers the full operational lifecycle of an F&B inventory operation across four sprint cycles. These are the screens that best illustrate the design thinking behind the system.

Sprint 1 - Foundation and Setup

  • Category Setup : The first setup screen establishes the table layout pattern used across every subsequent module in the system.

  • My Storages : Brand and department columns create a cross-outlet view without additional navigation layers.

  • UOM Setup : Base UOM per category, MUG for beverage, SERVING for food. Ensures consistent calculation across all modules.

  • My Brands : Brand grouping enables shared recipes across multiple outlets under the same brand umbrella.

  • Stock List : Item code, three level category hierarchy, brand, and supplier visible in a single row before expanding.

  • Supliers : Registration code and PIC contact visible in the list, critical for staff placing daily orders.

  • My Outlets : Outlet code, brand, company name, and address in one row. Country flag signals region for multi-country expansion.

  • My Outlets : Outlet code, brand, company name, and address in one row. Country flag signals region for multi-country expansion.

  • Category Setup : The first setup screen establishes the table layout pattern used across every subsequent module in the system.

  • My Storages : Brand and department columns create a cross-outlet view without additional navigation layers.

  • UOM Setup : Base UOM per category, MUG for beverage, SERVING for food. Ensures consistent calculation across all modules.

  • My Brands : Brand grouping enables shared recipes across multiple outlets under the same brand umbrella.

  • Stock List : Item code, three level category hierarchy, brand, and supplier visible in a single row before expanding.

  • Supliers : Registration code and PIC contact visible in the list, critical for staff placing daily orders.

  • My Outlets : Outlet code, brand, company name, and address in one row. Country flag signals region for multi-country expansion.

  • My Outlets : Outlet code, brand, company name, and address in one row. Country flag signals region for multi-country expansion.

Sprint 2 - Recipes and Catalogue

  • Catalogue Setup : The one exception to the table pattern across the entire system. Supplier selection is a decision-making task, not a data scanning task so card grid was the right choice. One deliberate deviation that proves the consistency rule was thought through, not applied mechanically.

  • Stock Monitoring : Three state badge system In Stock (green), Low Stock (amber), No Stock (red) gives operational staff instant visual clarity without reading individual numbers.

  • Catalogue Setup : The one exception to the table pattern across the entire system. Supplier selection is a decision-making task, not a data scanning task so card grid was the right choice. One deliberate deviation that proves the consistency rule was thought through, not applied mechanically.

  • Stock Monitoring : Three state badge system In Stock (green), Low Stock (amber), No Stock (red) gives operational staff instant visual clarity without reading individual numbers.

Sprint 3 - Daily Operations

  • Purchase Order : Expandable rows surface line items inline. PO number, supplier code, item code, and category visible at the parent level before expanding. The same pattern from Recipe Setup carries through every operational module.

  • Item Received : The PO Status column that Fully Received vs Partially Received is the key addition over the Purchase Order view. Same data, different operational context, one additional column that answers the most important question: has everything arrived?

  • Stock Count : Each batch expands to show department breakdown with PIC assigned per department. Status shows Pending (red) or Completed (green). The contextual action menu adapts based on status: Begin Stocktake, View, or Mark Completed.

  • Begin Stocktake : The most complex screen in the system. Items grouped by Storage Area with count badges. Actual Count and Draft Count displayed side by side in different colors such as red for actual entries already saved, black for draft still editable.

  • Purchase Order : Expandable rows surface line items inline. PO number, supplier code, item code, and category visible at the parent level before expanding. The same pattern from Recipe Setup carries through every operational module.

  • Item Received : The PO Status column that Fully Received vs Partially Received is the key addition over the Purchase Order view. Same data, different operational context, one additional column that answers the most important question: has everything arrived?

  • Stock Count : Each batch expands to show department breakdown with PIC assigned per department. Status shows Pending (red) or Completed (green). The contextual action menu adapts based on status: Begin Stocktake, View, or Mark Completed.

  • Begin Stocktake : The most complex screen in the system. Items grouped by Storage Area with count badges. Actual Count and Draft Count displayed side by side in different colors such as red for actual entries already saved, black for draft still editable.

The feedback loop - client directly in Figma

The client did not wait for scheduled reviews to give feedback. Cindy, the inventory manager, dropped comments directly inside the Figma file whenever she spotted something that did not match operational reality. This is one of those moments.
The client did not wait for scheduled reviews to give feedback. Cindy, the inventory manager, dropped comments directly inside the Figma file whenever she spotted something that did not match operational reality. This is one of those moments.

Sprint 4 - Financial Management and Dashboard

  • Cash Purchase : Grocery purchases recorded with receipt number and purchase source. Enters inventory without a PO flow.

  • Transfers : In Process vs Accepted status. Reason field captures COGS, R&D, Staff, and Event transfers. Each treated differently in financial calculation.

  • Sales Report : The "Missing Sales Report" banner appears in context above the table and not as a pop-up, or not as a system notification, but visible, actionable, and non-disruptive. This is how an operational alert should work.

  • Cash Purchase : Grocery purchases recorded with receipt number and purchase source. Enters inventory without a PO flow.

  • Transfers : In Process vs Accepted status. Reason field captures COGS, R&D, Staff, and Event transfers. Each treated differently in financial calculation.

  • Sales Report : The "Missing Sales Report" banner appears in context above the table and not as a pop-up, or not as a system notification, but visible, actionable, and non-disruptive. This is how an operational alert should work.

Inventory - Outlet Dashboard : Six KPI cards with embedded micro-trend charts, stacked bar chart for monthly sales by category, COGS vs Sales line chart with hover tooltip, Price Differences table with min and max per supplier, and Top 10 Fastest and Slowest Selling items. Those all can be filterable by Date, Brand, Outlet, Department, and Category.

Inventory - Outlet Dashboard : Six KPI cards with embedded micro-trend charts, stacked bar chart for monthly sales by category, COGS vs Sales line chart with hover tooltip, Price Differences table with min and max per supplier, and Top 10 Fastest and Slowest Selling items. Those all can be filterable by Date, Brand, Outlet, Department, and Category.

06 - KEY DESIGN DECISIONS

Every real design decision has something you gave up. Here are the three that defined this product.

“These were not obvious choices. Each one involved competing stakeholder goals, real constraints, and a trade-off I had to be willing to defend with evidence rather than preference.”

Decision 1

Expandable rows instead of detail pages

Navigation Pattern

Situation

The standard enterprise pattern for data heavy systems is to click a row and open a detail page. Every module had enough data to justify that approach.

Decision

Expandable rows throughout the system. Context preservation: an outlet manager checking recipes while planning tomorrow's order does not want to lose their place in the list every time they need ingredient detail.

Trade-Off

A dedicated detail page with more room for additional fields. Worth giving up because the primary use case was scanning and referencing, not deep editing.

Decision 2

Consistent table patterns across all 14 modules

System Design

Situation

With 14 modules, each could have been designed with its own visual logic. Some stakeholders expected each section to feel distinct.

Decision

Every module uses the same layout pattern. Heading with description, Import and Export, primary Add button, Filters and Search, paginated table, action menus in the last column. One exception: Catalogue's Select Supplier uses a card grid because selecting a supplier is a decision making task, not a data scanning task.

Trade-Off

The first time a user encounters any new module, they already know where everything is. The one exception proves the rule was thought through, not applied mechanically.

Decision 2

Semantic color as functional signal only

Visual System

Situation

Status states across multiple modules, brand color, and data visualization all needed to coexist without creating visual noise.

Decision

Three status colors used consistently: green for healthy states, amber for warnings, red for critical states. The violet brand color is reserved exclusively for primary CTA buttons. When something is purple, it means act here.

Trade-Off

The interface is faster to scan for experienced users and more learnable for new staff. Color discipline at this level is rare in B2B products and most systems use color inconsistently by module fourteen.

07 - Battle Story

Designing a landing page with no brief, no handover, and two other projects running in parallel.

Three months into the project, the UI designer's contract ended. A set of outstanding QA issues remained, and I stepped in alongside the QA team to review and resolve design related bugs in the dashboard. This was not a passive review it was a structured process. The QA team maintained a UAT Feedback tracker that categorised every issue by menu, type (Bug vs Enhancement), component affected (UI, Functionality, or both), and urgency level. Some items were marked Urgent. Some had dependency chains across modules.

UAT Feedback Overall : Every issue logged with menu, description, type of feedback, type of enhancement, urgency, and dependency. This is the document I worked through with the QA team, not a casual list, but a structured review covering Add Item Wizard, Purchase Order, Receiving, Stock Monitoring, Global Recipe, and more. Some cases required re-understanding the business logic from first principles before the design fix could be determined.

UAT Feedback Overall : Every issue logged with menu, description, type of feedback, type of enhancement, urgency, and dependency. This is the document I worked through with the QA team, not a casual list, but a structured review covering Add Item Wizard, Purchase Order, Receiving, Stock Monitoring, Global Recipe, and more. Some cases required re-understanding the business logic from first principles before the design fix could be determined.

QA session via Google Meet, 22 October 2025 : Working through the UAT items directly inside the live system here reviewing the Create New Item flow with the QA lead. This is where design decisions met implementation reality: some issues required a visual fix, some required a rethink of the interaction, and some revealed that the original brief had not accounted for an edge case.

QA session via Google Meet, 22 October 2025 : Working through the UAT items directly inside the live system here reviewing the Create New Item flow with the QA lead. This is where design decisions met implementation reality: some issues required a visual fix, some required a rethink of the interaction, and some revealed that the original brief had not accounted for an edge case.

CEO Direction

At the same time, the CEO came to me directly. The landing page designed by the UI designer was not approved. No feedback document, no clear direction on what needed to change. Just a request to start from scratch. I was also carrying active design work on a separate project for a different client inside Krenovator.

What I DId

I treated the landing page as a standalone product brief. I identified the target audience independently for enterprise decision makers in the F&B industry who would only reach the page through a sales referral, not organic discovery. I designed the full page, built it in Framer, and iterated through three rounds of CEO review. Approved on the third. Shipped within one month, responsive across desktop, tablet, and mobile.

3

3

CEO, CTO, Tech Lead review rounds before landing page approval

CEO, CTO, Tech Lead review rounds before landing page approval

1mo

1mo

From blank canvas to live in Framer and its responsive

From blank canvas to live in Framer and its responsive

200+

200+

Dashboard screens across 4 sprints in 3 months with teamates

Dashboard screens across 4 sprints in 3 months with teamates

08 - Landing Page

Everything on this page was designed to earn the attention of someone who was already half-convinced.

Enterprise B2B landing pages serve a different purpose than direct-response pages. The visitor arrived because someone referred them. They are not browsing, they are evaluating. That changed every decision I made about structure, copy, and conversion.

Three highlights info that focus on the landing page

1

Headline leads with the operational problem, not the product name

Target users already know they have the problem. Leading with the pain point signals immediately that this product was built for them.

2

Feature section uses specific operational language

Purchase Order, FIFO costing, AI Invoice Scanning the target audience responds to precision over marketing copy.

3

Three-step flow explains the adoption path before the ask

Enterprise buyers need to understand how they would use the product before committing to a conversation. "Contact Us" is the only conversion action because the real sales process happens off-page.

First Landing Page (Rejected)

Second Improvement (Rejected)

Final Approved ✅

Landing Page

09 - Outcomes

The system is live. The design system is still in use. The landing page shipped and stayed.

The dashboard system is deployed and actively used by the client across multiple outlets. Development continues as new operational cases emerge which is itself a signal that the system is being taken seriously as infrastructure, not just a tool.
The shadcn-based design system established during the three months UI phase has been carried forward by the development team without a designer in the loop. New screens are being built in the same visual language. That is the clearest measure of a design system's durability: it works when the designer is no longer there.

Observed changes in how the operation runs

Stocktake went from multi-file manual to one coordinated session

→ Previously, each department counted stock into separate spreadsheet tabs with no shared visibility. With the system, a single Stock Count batch covers all departments simultaneously.

COGS and variance went from manual formula to auto-calculation

→ The Actual COGS formula, Opening Stock plus Purchases plus Transfer In minus Transfer Out minus Wastage minus Closing Stock, was previously built and maintained manually in spreadsheet cells. Any entry error propagated silently. With the system, every transaction feeds the calculation automatically using FIFO costing and yield percentage, eliminating the largest source of silent error in the operation.

Purchasing decisions went from tab switching to one expandable row

→ An outlet manager previously needed to cross-reference the Item tab, Catalogue tab, Purchase Order tab, and Item Received tab to make a single restocking decision. With the system, the same information lives in one expandable row from current stock balance to supplier options to last received price that accessible without leaving the screen.

The landing page was approved after three iterations and is currently live at agenticas.ai. It replaced a version that was rejected at the client level. The design and the Framer build were both handled entirely by me.

14

14

Modules shipped and used across client outlets

Modules shipped and used across client outlets

200+

200+

Screens across 4 sprint cycles in 3 months with teamates

Screens across 4 sprint cycles in 3 months with teamates

Live

Live

System still in production with ongoing development

System still in production with ongoing development

10 - Reflection

What I would do differently. What worked. What I now carry forward.

What I’d change

  1. Brief in writing, not just verbally

The briefing process was almost entirely verbal. Written briefs, even short ones, would have reduced dependency on my availability and made each designer transition significantly smoother.

  1. Domain onboarding before day one

I came into the project without a formal onboarding to the F&B domain. A structured domain review at the start of any enterprise project is now something I treat as non-negotiable.

What worked better that expected

  1. Design system as dev handoff strategy

Pairing UntitledUI and shadcn paid off more than anticipated. The development team adopted the system natively and continued without a designer that only happens when the system is built with implementation in mind from the start.

  1. Treating the landing page as a product brief

Treating the landing page as a standalone product brief rather than a visual exercise was what got it approved. Audience clarity drives design clarity.

Principles I carry forward

Don't simplify the domain, make it navigable

Find patterns that make complexity manageable without hiding it from expert users. Oversimplifying breaks trust.

Honest complexity beats comfortable ambiguity

Recipe Setup, Begin Stocktake, the Consolidated Dashboard not simple, but organized well enough that complexity does not become confusion.

A design system's durability is tested after the designer leaves

If the dev team builds in the same visual language without a designer, the system worked. That is the standard I design toward.

DESIGNER

Muhammad Abqary Nasution | Raffialdo Bayu | Hazrul Aswad

timeline

3 Months UI Phase, 6 Months Development Completion

timeline

3 - 4 Months

Scope

Dashboard System, Landing Page, Design Direction

Scope

Dashboard System, Landing Page, Design Direction

Collaboration

CEO, 1 PM, 1 Lead Dev, 4 Full-Stack Dev, 1 QA

Ownership

Owned UX end-to-end for the AI assignment flow

Let’s build something meaningful!

Available for freelance, collaboration, or full-time opportunities.

Contact Me

Or send me an email to:

azrulspace@gmail.com

Find me where I build and share

Product Segment Capabilities

Product Design

Product Thinking

AI Integrated Workflow

Design System

UI Design

Figma MCP

Framer

Webflow

Wix

Branding & Illustration

Motion

Let’s build something meaningful!

Available for freelance, collaboration, or full-time opportunities.

Contact Me

Or send me an email to:

azrulspace@gmail.com

Find me where I build and share

Product Segment Capabilities

Product Design

Product Thinking

AI Integrated Workflow

Design System

UI Design

Figma MCP

Framer

Webflow

Wix

Branding & Illustration

Motion

Let’s build something meaningful!

Available for freelance, collaboration, or full-time opportunities.

Contact Me

Or send me an email to:

azrulspace@gmail.com

Find me where I build and share

Product Segment Capabilities

Product Design

Product Thinking

AI Integrated Workflow

Design System

UI Design

Figma MCP

Framer

Webflow

Wix

Branding & Illustration

Motion

Let’s Connect

Book a call

Let’s Connect

Book a call

on this page

01

The Problem

02

My Role

03

The Challenge

04

Design System

05

How it Works

06

Key Decision

07

Battle Story

08

Landing Page

09

Outcomes

10

Reflection

BACK TO ALL WORKS

ON THIS PAGE

ON THIS PAGE

Go to top