Venue.sh AI
2025 - 2026
Designing trustworthy AI inside an Internal Developer Platform
As Senior UX Designer on Venue.sh, I led the end-to-end design of the in-portal AI Assistant - from framing the problem through research, concept exploration, and shipped UI. The work centred on a single design challenge: how do developers get fast, actionable answers about ownership, services, and docs without leaving the portal - and how do we earn enough trust for them to act on what the Assistant says?
Overview
Designing for answers, not another chat window
I approached the Assistant as a layer on top of existing IDP mental models - catalog, TechDocs, templates - not a standalone AI product. My design goal was to make complex org knowledge feel immediate and verifiable: one conversational entry point, responses grounded in real entities, and clear paths back to source material. The experience had to serve Developer Don as daily champion while reducing repetitive discovery work that platform teams were still fielding manually.
Problem
The portal wasn’t winning against Slack
Research and testing showed the IDP wasn’t yet the fastest path to truth. Developers still context-switched to Slack, old repos, or colleagues to answer basic questions - ownership, APIs, “do we already have this?” - despite catalog and search existing elsewhere in the product. For me, that wasn’t a feature gap alone; it was a findability and trust problem. In competitive evaluations, AI narrative was also outpacing perception of what Venue could demonstrate in a live session — so the design had to work in-product and in a five-minute demo arc.
Research
What “useful” and “trustworthy” actually meant
I synthesised persona pain points across Software Developer, DevOps, and Platform Engineer research: time lost hunting ownership, fragmented docs, and repeated platform interruptions. Internal usability testing gave me the sharpest signal - where people looked for AI unprompted, whether answers to ownership questions felt actionable, and what made them hesitate. The insight that shaped the design: speed without provenance doesn’t convert to trust. Users didn’t need more fluency; they needed to see why they should believe the answer.
Ideation
Grounding AI in org context, not generic chat
I explored concepts beyond a simple chat panel — cite-backed responses, repo-aware summaries, org-scoped agents, and MCP access so the same intelligence could meet developers in their IDE. Conceptually, I anchored everything to one job story: find the service, the spec, and the owner in one flow. Governance and indexing surfaced early in ideation because UX couldn’t treat AI as magic; admins needed control over what the Assistant could see, and users needed transparency about what it was drawing from.
Designs
Citations as interface, discoverability as adoption
My key design decisions were: make source attribution visible in the response pattern (not buried in a tooltip), align the Assistant with Venue’s design system so it felt native to the portal, and treat discoverability as a first-class UX problem — not an afterthought once the model worked. I designed for a trust gradient: quick answers for simple lookups, deeper entity context and summaries when users needed more confidence before acting. The result was an experience that read as Venue intelligence, not a bolted-on chatbot.
Lessons
Trust is the feature; proof is part of the design
The biggest lesson: in a developer tool, citation UX is as important as answer quality — without it, even good responses get ignored. I also learned that shipping strong in-product UX doesn’t automatically close a competitive narrative; demo clarity and message alignment (“Ask Venue”) are design deliverables too. Finally, scope discipline mattered — the win wasn’t “AI everywhere,” it was reducing Slack loops with org-grounded answers. Designing for production decisions means knowing when not to over-promise.
