TL;DR
The outcome:
Proposed and defined the Rule Setup system from scratch. No spec existed; I identified the need for a configurable alert engine and designed the logic layer that combined metrics, statistical functions, and thresholds.
Defined the Device Setup flow, translating dense infrastructure metadata (protocols, signal loss, tracked metrics, accuracy tolerances) into a multi-step form navigable by a non-specialist admin.
What went wrong: The product never shipped. "Korwatch" was targeting two industries simultaneously with one engineer on infrastructure. The company pivoted before reaching production.
What I learned:
Indirect context is still context, but it needs to be named as a risk.
Learning the domain before designing isn't optional in technical B2B products.
Without explicit user definitions, I was designing for an average that probably didn't exist.
Main challenge
Context:
The platform needed one configuration system that could handle fundamentally different device types: pressure loggers in pump houses and routers in telecom networks, used by operators with different technical backgrounds, built on infrastructure that was still being defined.
My hypothesis:
A flexible, step-based configuration model with plain-language labels and inline guidance could make complex device setup accessible to non-specialist admins, without sacrificing the technical precision operators would need.
The constraints that shaped everything:
No direct access to users — all context came filtered through the design lead, who channeled the CTO who was building infrastructure in parallel
Two client types with different vocabularies and different mental models sharing the same interface
Product scope was undefined enough that I couldn't confirm whether the forms I was designing would translate to both industries or would need to fork
Phase 1: Domain immersion Phase 2: Making technical fields navigable Phase 3: Proposing the alert logic layer Phase 4: Event center as final operational loop
Key decisions:
Separated metric from statistical function in the Rule Setup — a pressure reading of 90 PSI once is different from an average of 90 PSI over 6 hours. Keeping them as one field would have forced redundant rules.
Used tooltips and placeholder copy as onboarding within the form — not documentation, not a separate help section, but inline guidance at the moment of confusion.
Placed Collaborators in both Device Setup and Rule Setup as separate defaults — device-level defaults for ongoing monitoring, rule-level assignment for specific alert logic.
Difficulties:
The hardest part wasn't any single design decision, it was the structural ambiguity. Designing a system that might serve two completely different industries, with unstable technical requirements, no user validation available, and a scope that kept shifting made it difficult to know when a design was done versus when it was just good enough for the next conversation.
What went wrong?
I accepted the constraint of no user access without pushing back on it.
About assumption visibility:
In ambiguous projects, naming your assumptions is a design deliverable. I made many bets that went unchallenged simply because they were never made explicit. A one-page assumption log would have surfaced disagreements earlier and made the design more defensible.
About research:
I didn't have user interviews, but I had a CTO who understood the operators. I could have structured those conversations more intentionally — asking about real configuration errors, common device types, what operators call things — instead of just waiting for requirements to come through.
About user types:
Designing one system for two different user types creates invisible compromises in every decision. The sooner you name the tension explicitly: either we fork the experience, or we accept that one group will struggle, the better the eventual design.
For next time:
Run a domain interview with the CTO early — not as user research, but as vocabulary alignment. What do operators actually call these things? What errors do they make during setup?
Create an assumption log at project start. For every major design decision made without user validation, document the assumption, the risk level, and what would need to be true for it to hold.
When designing for multiple user types, force an explicit decision: shared interface with compromises, or forked experience? Don't let the question stay implicit — it shapes everything.
