James Dishman
Youngstown, OH. Still building things.
The Short Version
I design things at the intersection of AI, creativity, and human decision-making. My background is unusual: a BA in English Writing from the University of Pittsburgh, with related studies in Philosophy, Political Science, and a certificate in Latin American Studies, which turns out to be a surprisingly good foundation for thinking about how people actually use things.
I produce electronic music. I have for thirty years. I co-founded the Pittsburgh Ableton User Group with Paul Miller and Steve Knots and serve as the direct liaison to Ableton's international community team. I maintain a personal collection of over 50,000 tracks, curated across 25 years. That collection is not a hobby detail. It is an artifact of how I think: curation as an intellectual method, applied to sound, community, and now research. I am finishing an MS in User Experience at Kent State with a 3.95 GPA, where the formal training meets the instinct I have been building for years.
The Compression Path
This is the clearest way to see how the pieces connect: music, community work, UX, and AI systems design.
Four domains, one line of work
Pattern recognition became teaching. Teaching became UX. UX became AI systems design.
Music taught pattern recognition. Community work taught me where people get stuck. UX gave me a way to see that clearly. AI systems design is where those threads meet.
§Interactive map
Tap a ring or node to explore
What I Actually Believe
Technology should make people more capable, more creative, or more connected to the thing they care about. That is how I decide what is worth building.
If a system does not help the person using it do better work, think more clearly, or stay closer to the reason they came to the tool in the first place, I am not interested in it.
I see design through Don Norman's frameworks as a default lens. Affordances, signifiers, mapping, feedback, conceptual models. Not because they are trendy (they are decades old), but because they work. They are the vocabulary for asking whether something actually serves the person in front of it.
I am influenced by Hunter S. Thompson's radical honesty, not his substance abuse: the part where you look at the thing clearly and say what you see, even when it is uncomfortable. That matters more in design than people want to admit.
The Differentiator
I do my best work when I know the subject deeply. The Ableton evaluations in my portfolio are credible because I have lived inside that ecosystem for years. The Oblique Oracle exists because I cherish the I Ching, not because I saw a market opportunity. Clarence is not a demo project. It is a system I use every day, built through repeated correction, daily use, and overnight pipeline runs.
That depth is what I bring to a team. I learn the domain, I learn the users, and I build things that reflect both.
What is Next
I graduate from Kent State in December 2026. After that, I am pursuing doctoral research in Human-Computer Interaction. The research questions I care about sit at the intersection of HCI, learning sciences, and creativity support tools: how do people develop creative capacity, and how do AI systems support or hinder that process? My work on Clarence, my years inside music production tools, and the curatorial knowledge encoded in a 50,000-track collection are not separate interests. They are the same question approached from different angles. If you are working on problems in this space, I would like to talk.
Practical Links
The main site hierarchy is Work, Lab, Writing, and About. The practical pages live here.
Building This Site
This site was built over about three days in late March 2026. The stack is Next.js, TypeScript, CSS Modules, deployed to GitHub Pages with Cloudflare in front of it. No templates. No themes. Built from scratch.
It was a collaboration between Clarence and me, but the hierarchy was clear. I reviewed the site on my iPad and phone between stops on my meter route, sent corrections through Telegram, and made the decisions about design, voice, layout, and information architecture. Clarence handled code generation, build management, and deployment.
How It Actually Worked
I would review the site on my iPad and phone between stops on my meter route, then send corrections via Telegram. Clarence would pick them up and push changes. Sometimes this worked beautifully. Sometimes the build broke at 5am and I would wake up to error logs.
The process was messy. There were em dash hunts across every page because I kept finding them in body text. Cached pages that would not update no matter what we tried. Fights about delegation when Clarence tried to make decisions I had not approved. At one point, Clarence ran on the wrong runtime configuration for an entire day because a settings file could not be edited from the interface we were using. The output quality dropped noticeably and we did not figure out why until that evening.
The portfolio content was not generated from a generic prompt. It came out of repeated correction and daily use. Clarence could move quickly because it had already learned my standards, but the calls about what stayed, what got cut, and how the work should sound were mine.
What is Honest About This
The portfolio content comes directly from my graduate research at Kent State. Every case study is grounded in real work, not made up for a portfolio site. The images are still missing. It is text-only right now. That is honest, not a failure. The words came first because the words are the work.
The git history tracks every commit and who made it. This is not a "look how amazing AI is" story. It is a "we built something real with a lot of friction and it works" story. The friction is the interesting part. It is where the design questions live.