The Interface Roadmap: Beyond the Chat Box

Way back in the year 2000, I built my first commercial website for DirecTV’s intranet. I was proud of the expertly sliced PSD file from ImageReady wrangled into a table, the clever JavaScript that animated the navigation, and just the sheer technological sophistication and mastery I was exhibiting by creating a website. Shortly afterward, my dad handed me a book called “Web Pages That Suck” by Vincent Flanders and Michael Willis and I was never the same.

“Web Pages that Suck” was the first of many great books to tell the story of how a website was essentially useless unless someone valued the content and could actually use it solve a problem. In short, they had to want to come there and use it in the first place. It was a message I needed to hear and internalize, the fact that the “Field of Dreams” strategy doesn’t work in the real world.

Twenty-five years later, I feel I’m watching a re-run of the early 2000’s. Now the hot new tech is Gen AI and teams are designing for their fascination with all things LLMs, forgetting that people still need to use it to get something done (and that’s why they came there in the first place).

This time around, I’m trying to learn from that lesson faster. Teams building effective AI interfaces are working systematically across three layers: making business logic explicit, preserving meaning across systems, and designing interfaces that put that intelligence where people actually need it. The Interface Roadmap is that final piece, where the foundational work becomes something users can actually put to work.

The Pattern: Three Layers That Need Each Other

The three roadmaps work like the old three-tier architecture we used to build enterprise applications, and the parallel gets stronger the more I work with teams implementing AI.

Those systems had business logic layers containing all the rules about how your organization actually worked. Data layers managed information consistently so every part of the system could trust what it was getting. Presentation layers translated all of that into something useful for people trying to get work done.

The Platform Roadmap functions as that business logic layer. When teams define explicit rules about what “deals needing attention” actually means, like “contract value exceeds $50k AND no contact in 14 days OR support escalation in last 7 days”, they create logic that any system component can use. The implicit knowledge living in people’s heads becomes something both humans and AI can access.

The Context Roadmap operates like that data layer, but it goes beyond just managing information. When sales talks about “contract value,” they mean annual recurring revenue. When finance uses the same term, they mean total contract value including one-time fees. When customer success says it, they’re thinking about expansion potential. The Context Roadmap establishes shared definitions and preserves why each team needs different aspects of the same underlying data.

It also captures the why behind interactions, not just the what. Instead of logging “customer called about billing,” the system records that the customer called because their auto-renewal failed due to an expired credit card, and they’re frustrated because this is their third billing issue in six months. When sales follows up, they understand the full situation and can address the real problem, not just schedule another billing conversation.

The separation is intentional. Your Context Roadmap work becomes the foundation for multiple platform implementations. The customer health data model you build for renewal risk prediction also supports your support ticketing system, your product analytics, and your sales forecasting. Your Platform Roadmap business logic about what constitutes an ‘at-risk’ customer can power dashboards, automated alerts, email campaigns, and API endpoints. Each layer builds capabilities that get leveraged across multiple applications rather than being locked into single-purpose solutions.

Why We Can All Do Better Than a Blank Chatbox

Even when teams have done solid work on Platform and Context roadmaps, it sure looks like most are punting when it comes to interface design. Maybe they’ve built explicit business logic and preserved meaningful context across their systems, but then they default to what everyone else is doing thinking (incorrectly) that it’s established convention: a chat interface or a magic wand button that says ‘Ask AI.’

The team has probably done a tremendous amount of work getting the data or the platform to be incredibly intelligent and useful, but they haven’t thought through how to present that intelligence effectively. Someone types “show me customer problems” and the system has all the business logic to distinguish between different problem types and all the context to understand this person is a customer success manager preparing for a quarterly business review. But it doesn’t use this (at least not at first) instead expecting the user to engineer their prompt better.

The team built the intelligence but now expects the users to adapt to the AI rather than the AI adapting to users. They assumed that because their system can have conversations, conversations must be the best way to deliver intelligence. The chat box becomes a lazy shortcut that wastes the sophisticated understanding they worked hard to build into their platform and context layers.

Bringing Intelligence to Work

Take a customer success team trying to predict renewal risk. The obvious move would be building a separate AI dashboard where CSMs could ask ‘Which accounts are at risk?’ But teams that have done the foundational work often make a different choice.

The Context Roadmap unified product usage data, support sentiment, and billing history into a single view of customer health. The Platform Roadmap defined explicit business logic for what ‘at-risk’ actually means. During Interface Roadmap planning, they realized their CSMs live in their CRM account list all day. Forcing them to switch to a chat window would break their workflow.

So they embedded the intelligence directly. A color-coded health icon appears next to each account. When a CSM clicks on a high-risk account, the page proactively explains why it’s at risk and suggests next actions. No questions required. The intelligence meets them where they work. That’s the difference between building a feature and building for an outcome.

When This Actually Works

Teams that have implemented all three roadmaps create experiences that feel effortless because the underlying system understands both the work and the person doing it.

Their sales dashboard knows that “show me deals needing attention” should surface different information for different users based on role, territory, and current priorities. Their support system recognizes that “urgent customer issues” means different things to support reps, customer success managers, and product managers. The interface adapts because the system has both the business logic and contextual understanding to make those adaptations meaningful.

When this works, people stop needing to become prompt engineers for their own jobs. Instead of learning how to craft queries that will get useful results from their AI tools (figuring out the right keywords, providing the right context, engineering better prompts) they can describe what they’re trying to accomplish in plain language. The computer figures out how to deliver it in whatever format makes the most sense for their work. The cognitive burden shifts from the user to the system.

The Interface Roadmap is how you build that capability with language-enabled technology, but only when you’ve done the foundational work first. Twenty-five years after ‘Web Pages That Suck,’ the core lesson hasn’t changed: an interface has one job, to help people accomplish their work. The rest is just showing off.