# Questions Each story starts with the product question, not an internal project name. ## Making Complex Systems Accessible How do you make complex systems accessible? Designing visual programming systems that help domain experts create complex behavior without writing code. Why it mattered: Domain experts often need to create complex behaviors, but traditional tools force them to either write code or depend on engineers for every change. What I built: A visual programming experience for authoring, inspecting, and evolving complex behavior. What changed: The work reduced barriers to creation and made complex systems easier to understand and discuss. What I learned: The right abstraction matters more than the surface UI. ## Building Trust in Digital Commerce How do you help creators earn money and customers buy with confidence? Designing commerce experiences for digital goods where customers need confidence and creators need clear value communication. Why it mattered: Digital goods are harder to evaluate than physical products, so both creator value and customer confidence have to be designed into the experience. What I built: External-facing product and purchase patterns that made digital goods easier to understand before purchase. What changed: The experience helped connect creator expression, product clarity, and buyer trust. What I learned: Trust is part of the product, especially when the thing being sold is intangible. ## Prototypes as Strategy How can prototypes drive strategy? Using functional prototypes to make ambiguous futures tangible and turn product debate into evidence. Why it mattered: In ambiguous product spaces, discussion alone is too slow. Teams need something concrete to react to. What I built: Functional prototypes and reusable workflows that helped product, design, and engineering evaluate direction together. What changed: The prototypes created shared evidence for strategy, roadmap thinking, and team alignment. What I learned: Slides create opinions. Prototypes create evidence. ## Building the Designer's AI Workbench What should a designer's AI workbench look like? Creating environments for designers to work with real components, real interaction logic, and AI-assisted local workflows. Why it mattered: As AI changes how software is made, designers need better environments than static mockups alone. What I built: Local prototyping and design sandbox workflows for experimenting with production-like components and AI assistance. What changed: The work helped designers move faster from concept to working product evidence. What I learned: Designers need working materials, not only static canvases. ## Designing AI Behavior How should AI agents behave? Designing when AI should speak, suggest, act, wait, explain, or stay silent. Why it mattered: As AI systems become more agentic, the design problem shifts from screens to behavior. What I built: Principles and interaction patterns for AI systems that need to collaborate with people. What changed: The work framed AI product design around trust, initiative, uncertainty, and timing. What I learned: For AI products, the interface is often adaptive. The deeper design work is behavior.