Product Design for Technical Tools and Decision Support
Product design for complex tools
I am strongest in product design when the users are experts, the domain is dense, and a beautiful screen is not enough. The work I want is the kind where research, information architecture, trust, data flow, implementation constraints, and adoption all have to line up before the tool earns a place in somebody’s day.
Where I fit
I am a technical product designer with a software architecture and delivery background. For hiring managers, the useful point is simple: I can learn from expert users, translate the workflow, prototype the decision, and stay close enough to engineering that the design can actually ship.
What I mean by product design
Good technical-product design starts before pixels and continues after launch. It asks what users are trying to decide, what evidence they trust, what mistakes cost, and what the product has to explain before people can rely on it. The interface matters, but so do the workflow, the data boundary, the handoff to engineering, and the operating habits that keep the product useful after release.
What I bring
Technical-user research
Interviews, workflow mapping, requirement translation, persona framing, and feedback loops for analysts, operators, engineers, executives, compliance teams, and other expert users.
Information architecture
Decision flows, evidence hierarchy, navigation, comparison views, review queues, exception paths, and the content structure users need when the system is dense.
Design-system thinking
Reusable interface patterns, schema-driven UI, component semantics, and product-system rules that help teams ship coherent tools across web, native, desktop, API, CLI, and MCP surfaces.
AI and decision support
Human approval paths, explainable output, trust boundaries, audit trails, deterministic guardrails, model-agnostic orchestration, and product flows where users can review, challenge, and act on generated recommendations.
Prototype to production
Working prototypes, delivery automation, front-end implementation, document generation, CI/CD, telemetry, accessibility-aware structure, and product iteration tied to real operational adoption.
Adoption and rollout
Training paths, executive tradeoff framing, support workflows, governance integration, operating dashboards, and release practices that help tools survive real organizational use.
Work worth discussing
Sports product
Fumaro Sports Predictive Intelligence
Role: Founder and principal architect actively developing Fumaro Sports, a live sports analytics proof of concept at poc.fumaro.pro with a public multi-sport Next.js runtime, strict TypeScript, PostgreSQL-backed routes, Azure Databricks analytics, and MLB-first data surfaces.
Why it matters: The product problem is not only prediction accuracy. Users need to understand what changed, why it matters, where confidence is bounded, and what action a signal supports.
How it transfers: Fumaro is being shaped around research input, product framing, prototype/build loops, instrumentation, user feedback, staged beta practices, and human review instead of opaque model output.
Baseball depth: Fumaro distinguishes direct statistical signals from Second Order context such as venues, weather, umpire crews, rivalry conditions, schedule density, home-road splits, and travel effects. That matters because baseball users need explanation and judgment support, not only raw stat display.
Design systems
Canonical Schema-Driven Front-End Engine
Role: Designed a single canonical JSON-schema front-end engine that deploys cohesive applications across web, native mobile, desktop, APIs, CLIs, and MCP toolkits.
Why it matters: This is product-system work: one interaction and data-contract vocabulary, shared components, reduced interface drift, and a reusable way to keep multiple products coherent.
Outcome: Reduced each interface codebase 25-30% through shared components and enabled one team to manage all interfaces instead of dedicated teams per platform.
Public-sector workflow
Records Digitization and Request Turnaround
Role: Built a microfilm digitization tool that converted more than a century of public records into OCR/ICR-optimized PDF/A assets with metadata in a single 21-hour continuous run.
Why it matters: The work connected legacy media, operator constraints, public-records workflows, metadata quality, and request fulfillment into a tool that changed how users could serve the public.
Outcome: Collapsed an estimated 10-year multi-person effort and reduced pre-digital records-request turnaround from weeks or months to days or hours.
Regulated workflow
Security, GRC, and Change-Management Adoption
Role: Drove ServiceNow GRC and change-management integration while leading a cybersecurity engineering team under a public-pension CISO.
Why it matters: Security controls became usable operating workflows: dashboards, evidence paths, change tickets, remediation loops, and executive review cadence.
Outcome: Legitimate change tickets increased from a handful per month to dozens per week while change delivery cycles dropped from weeks to days or hours.
Baseball operations relevance
Baseball operations product work has a specific audience shape: analysts, scouts, player-development staff, evaluators, coaches, and technical users who need to compare evidence quickly without losing context or trust. The transferable design patterns are workflow mapping, review queues, comparison surfaces, decision logs, model-output explainability, design-system consistency, and fast iteration with domain experts.
For MLB and club roles, the strongest public argument is the combination of active sports-product work through Fumaro Sports, technical-user UX, schema-driven interface systems, AI guardrails, and delivery experience in high-trust environments. This is not a claim of prior club employment. It is a claim that I can make dense sports data, model context, user feedback, and operational constraints legible in working software.
Tooling and craft boundary
Figma is a current advanced collaboration tool in Scoria and Fumaro work, used alongside research input, prototype handoff, design-system decisions, and implementation planning. The broader craft record remains tool-agnostic: Adobe Creative Cloud, Visio, AutoCAD, Vectorworks, schema-driven UI, front-end implementation, generated documents, working prototypes, and production systems. The honest claim is technical product design that connects design intent to shipped systems.
Adjacent craft and human context
Relevant nontechnical skills sit below the primary product-design case but still matter for technical-user work. French and Italian are proficient but rusty; Spanish is intermediate with active daily learning; Japanese is novice with active daily learning. The creative-production record includes University of Michigan Design & Production study plus archival lighting design, sound design, and stage-management work. Adjacent hands-on domains include electrical and non-IT electrical systems, strong culinary craft, California Cattle Dogs LLC, sports analysis through Fumaro Sports, and cross-functional communication with users who do not think like software teams.
What is public and what is not
Some product artifacts, screenshots, diagrams, and prototype details are not public because they involve customer systems, internal tooling, NDA-sensitive workflows, or unfinished venture work. The public summaries here are enough for screening and interview direction; deeper review can happen when confidentiality boundaries and audience are clear.