About | James Dishman

The Short Version

I research how people make decisions inside complicated tools, then build systems that make those decisions easier to understand and control. 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. I want to study how people develop creative capacity and how AI systems support or hinder that process. Clarence, thirty years inside music-production tools, and the curatorial knowledge encoded in a 50,000-track collection all give me a different view of that question. If you are working on it too, I would like to hear from you.

Practical Links

The main site hierarchy is Work, Lab, Writing, and About. The practical pages live here.

Building This Site

I built the first version in late March 2026 and have kept rebuilding it as the evidence changed. The stack is Next.js, TypeScript, and CSS Modules, deployed to GitHub Pages with Cloudflare in front of it. No templates or themes.

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 and from systems I use in public. The words came first, but they no longer carry the proof alone. Case studies now pair the argument with research artifacts, process records, public graphs, and verified build evidence. Some projects still need stronger visual documentation, and those gaps remain visible.

The git historytracks 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.