Blind Matrix
Manufacturing rules turned into a fail-safe configurator.
Web
B2B
Manufacturing
Role
Product Designer
Phase
Discovery & feasibility study
Methods
Client Workshops · Logic Mapping · Lo-fi Prototype
Overview
Sometimes success is preventing the client from building the wrong thing.
My prototypes and logic maps validated that the technical requirements exceeded the client’s resources — saving them from a stalled development cycle. The deliverable wasn’t a shipped feature. It was strategic clarity: the first complete map of how their product logic actually works.
Problem
The logic lived in tribal knowledge, not in any system.
Small manufacturers relied on manual Excel calculations to configure orders. The rules were hidden in tribal knowledge: motor power depends on blind size, fabric width dictates rolling constraints, striped patterns cannot be rotated. Building a tool without mapping this first would lead to impossible orders reaching the factory floor.
Key decisions
Map the logic first — then let it drive the flow.
Decision 01 · Ordering
The “fail-safe” ordering flow: ask for control type first
Workshops revealed that control type (manual vs. electric) dictates all physical dimensions. Restructuring the flow to ask for control type first immediately filters out invalid dimensions downstream — the user can no longer configure a product that physically cannot be built.
Why
Workshops with the client surfaced the dependency hierarchy: control type sits at the top.
Trade-off
The flow opens with a technical question instead of the visual choices customers care about (fabric, colour). Correctness was priced above first-screen appeal: an engaging flow that produces unbuildable orders helps nobody.
Decision 02 · Rules
A visual logic tree instead of code
The client needed to update rules (e.g. “if surface mount → hide accessories”) but had no IT staff. Instead of asking them to write code or Excel formulas, I prototyped a visual logic tree — non-technical staff build if/then dependencies with a simple select component.
Why
Rules change with the product range, and the people who know them are production staff, not developers. A rule system its owners can’t edit would recreate the original problem.
Trade-off
A select-based tree handles single if/then chains, not complex multi-condition rules — those would still need a developer. Accepted: the ceiling covers the rules that actually change day-to-day.
Decision 03 · Data
Bulk import: 1,000+ SKUs in minutes, not weeks
Every fabric in every colour is its own SKU — a stock keeping unit, one distinct line in the catalogue — and this client had more than a thousand. Entering them by hand would take weeks, which makes the tool unusable for a small team before they have even started. The bulk import maps the client’s own CSV files onto system parameters and auto-matches them with product images, so onboarding drops from weeks to minutes.
Why
For an SME, weeks of manual data entry before first use is a dealbreaker — the import is what makes adoption realistic at all.
Trade-off
Auto-matching is only as good as the client’s spreadsheets. Messy columns import messy data, so the design assumed a review step after import rather than blind trust in the mapping.
Outcome
Strategic clarity beat shipped features.
Reflection
Design is often about uncovering the unknown.
By visualizing complex dependencies early, we identified the true scope of the product before a single line of code was written. Sometimes a successful design phase is one that clarifies the business is not yet ready to build.