TEAM
Time
3 months
My role
Product Designer
KEY SKILLS
Adoption & Retention
UX Research
AI Prototyping
Overview
I led the end-to-end redesign of Arda’s no-code MVP into a custom SaaS platform built to scale toward $1M ARR
Arda helps manufacturers replenish inventory using QR-enabled Kanban cards. While the MVP validated the concept, customers still relied heavily on hands-on support to configure the system and complete routine orders due to cognitive overload on the existing MVP. As the founding designer, I partnered with leadership and engineering to simplify the core experience and establish a stronger foundation for growth. Due to the complexity of the no code MVP, every client needed high-touch service, these were bottle necks to scale.
1. Founder's time was 90% occupied in customer service
2. Every client had a different product, they all customized their own features. buut the features became more convuluted as they built
As the complexity grew on the no-code platform - Eng personnel decdicated more time to maintaining the backend.
SOLUTION
I redesigned Arda around one clear path to value—identify what needs replenishment, review the order, and place it.
The recurring value was not printing Kanban cards or configuring the system. It was helping teams recognize what needed attention and complete an order without assistance. Ordering was Arda’s recurring moment of value, so I optimized the product and rollout around protecting it.
who i designed for
Built for the floor, not the dashboard
Through user interviews and stakeholder interviews these personas surfaced. I mapped the most likely engagement loops for each persona.
01 Product Decisioin
I designed the experience around the actions customers repeated every week
Everything was designed to prioritize ordering
I used consistent ordering behavior as the product’s primary adoption signal. Every major decision was evaluated against one question:
Does this make it easier for a shop-floor user to place the next order?
That principle shaped three areas of the experience:
Make ordering visible
The primary order action remained directly on each item row, where users were already reviewing inventory.
Keep users in context
Users could add an item to an order without opening another page, menu or workflow.
Organize around the next decision
Statuses, item groupings and reorder information helped users understand what required action without searching through the product.
Place the reorder worklist or item-table artifact here.
VALIDATION
Testing confirmed that speed mattered more than visual simplicity
I tested both ordering approaches with four users. Participants consistently favored the inline workflow and described the button-based version as unnecessarily complex for an action they performed repeatedly.
The findings validated three product requirements:
The order action needed to remain visible
Users should not have to remember where ordering was located.
Ordering needed to happen in context
Users wanted to act directly from the item they were reviewing.
The core workflow could not absorb unnecessary steps
Small interaction costs became significant when repeated across many parts and orders.
Then use metric cards:
4 of 4
Users favored inline ordering
19 → 3
Steps in the simplified end-to-end flow
1 critical risk addressed
Prevented added friction in the product’s primary workflow
I would not say “churn reduced by 75%.” Four usability participants preferring a design does not prove a 75% reduction in customer churn.
A stronger and more defensible line is:
Validation prevented a high-risk ordering workflow from being released to existing customers.
Or:
Testing addressed a critical adoption risk before rollout.
The North Star Metric was 7 orders a week.
02 Product Decisioin
I kept the order action inline instead of hiding it behind a menu
One proposed design moved ordering behind a button and dropdown.
Button and dropdown
Select an item → Open the action menu → Find “Order” → Configure the order
This reduced visual density, but introduced extra decisions into the product’s most frequent workflow.
Inline ordering
Review the item → Enter the quantity → Add it to the order
The inline version kept the action visible at the moment users recognized that a part needed replenishment.
Place the two designs side by side here:
Proposed workflowResearch-backed workflowOrder hidden behind a button or menuOrder controls visible on the item rowFewer controls shown initiallyFewer steps required to actCleaner visual surfaceFaster recurring workflowBetter for infrequent actionsBetter for the product’s core action
Your visual should make the extra interaction obvious. Show a simple numbered flow above each version:
Dropdown: 1. Select item → 2. Open menu → 3. Choose order → 4. Complete order
Inline: 1. Enter quantity → 2. Add to order
You do not need to attack the dropdown version. Present it as a legitimate tradeoff that was wrong for this specific workflow.
TRADEOFF
We delayed migration rather than disrupt a proven workflow
The new SaaS platform improved the product’s structure and scalability, but the initial build did not yet support the validated inline ordering experience.
Rather than migrate existing customers to a slower workflow, we chose to preserve their current experience until inline ordering could be implemented in the new platform.
Prioritized
Protecting the workflow customers already relied on
Deferred
Migrating existing customers to the new SaaS product
Required before rollout
A production-ready inline ordering experience
This is an excellent product-design tradeoff because it shows that you did not treat shipping the redesign as the goal. Protecting user value was the goal.
PRODUCT THINKING
The rollout decision treated ordering as infrastructure, not a feature
Ordering was not one capability among many. It was the behavior that made the rest of Arda valuable.
A more scalable technical platform would not represent progress if it added friction to that behavior. By staging the rollout, I balanced two competing needs:
Build for future scale
Move beyond the limitations of the no-code MVP.
Protect current adoption
Avoid disrupting the workflow existing customers had already learned.
This is where you demonstrate that product design is not just interface production. You influenced which version should ship, to whom and under what conditions.
03 Product Decisioin
From placing the order to predicting it
One proposed design moved ordering behind a button and dropdown.
key product decisions
A few examples of how research changed the proudct
CLEAR HERO AND VALUE
Proactively communicate MLC mission and value, clear NSM as primary action.
focused discovery
Discovery mapped to user goals making projects, events, and researchers easy to find.
Streamlined actions
Simplifies how users take action and get involved. 1 click actions from the homepage.
validation
Outcomes
Validation tested on the same six users, I measured the before and after for — time spent on page, how confident they felt in achieving their goal, and seven different tasks. Results validated behavioral change and optimization for growth.
Increased Time on Page
+92%
User Confidence Score
+99%
Task completion rate
+6x
