What Changes with AI … and What Keeps Us Grounded

The following are simple guidelines that I use as a reference (and to help the team) understand user needs, clarify outcomes, and measure quality.

Design critique tends to fail when it has no frame of reference. So I give it one.

Ground the Team Before Design Begins

Seven steps from problem to measured impact, then back around

I take into account the objective , the system around it , its constraints and tradeoffs , and a scalable, incremental path forward — grounded in evidence and shared context, so we solve the right problem.

The PM heard "I want mobile" from customers, worked with engineers to make the desktop app responsive to mobile, checked the box, and moved on.

I requested that we touch base with customers to dig into the “why“ behind this - which was related to receiving network alerts on mobile.

So, I had the team play out the scenario. With a mobile site , customers would never hear the alert coming in (no bell ringing in their pocket).

A native app would accomplish this, but timing was a factor.

So, I recommended a trade-off of allowing users to leverage existing native apps (Outlook, Slack, etc.) for notifications. That will free up real estate on the desktop experience - to improve patterns and interactions there - where most users spend most of their time.

We can make a dedicated native app a future goal in the roadmap.

Solving one problem (with design thinking) solved several.

I nudged the team toward a change in product strategy to fit what large enterprise customers actually wanted for GDPR workflows - full automation - based on a series of user research sessions.

PMs were wanting to take the "sticky app" approach.

Going down the wrong path would have meant low adoption (lost opportunities) and turning back from the path of a complex new feature would have been very difficult later.

Helping PMs see this from another perspective (giving customers what they actually want and need and improving adoption) would present a major value ad to the cloud platform - and the team's contribution could be SMEs for data privacy.

Secondary value-ads could have been offered, such as ServiceNow templates.

AI-Assisted Research, Discovery and Measurement

Agents Change the Paradigm

Assistants and Agents Working Together

Ground the AI with Deterministic Data

The current process of managing design system implementation and updates, handling designer-developer handoffs with multiple questions and reviews, and guideline creation has always been time-consuming.

We labeled it as a ‘means to an end‘ and repeated the same laborious process for years. We now have an opportunity to improve several processes at once - with one new simple format.

The Source of Truth

If we could leverage the power of AI design tools like Claude and a MCP server (acting as the governance and design system management layer) we could go from completely probabilistic AI to AI that’s more grounded in deterministic rules.

Designers and developers would be working off of the same source of truth.

If the process were redesigned with 3 core parts, we may be able to implement multiple improvements at once.

The team would review on a real, production-ready page, instead of a Figma simulation.

Managing the design system would be done directly on the MCP Server, instead of the traditional Figma > Storybook > Production flow. Figma won't disappear. Its role will shrink from "where the product is designed" to "where humans resolve ambiguity that agents can't efficiently resolve."

The time saved could be spent creating reusable design patterns at a higher level than components only. Guidelines at the component (atom or molecule) level are typically designer-created documentation for other designers.

Patterns become much more valuable when they’re created in a format that matches the way we all think.

Higher-level patterns match the way we all think and work.

• Product (Thinking in features and flows)
• Engineers (Thinking in pages, flows, and seeing components as a means)
• End Users (Thinking in terms of tasks and flows)
• Designers (Matching the mindset of the user with tasks and flows)

An example of a use case (or platform-level) pattern would be a simple wizard that the design team wants to present in a modal. That one pattern is not a component. It’s a collection of pages and components, organized into a flow.

If patterns were approached from this perspective, they would be much more understandable, practical in terms of how we think about solutions, could provide more deterministic data for the MCP Server, and may help the team move faster without compromising quality.

If there are enough skills to set up a pilot MCP Server - teams can partner at least one designer and developer to run a pilot project for one project for one release.

Review accuracy - and the additional work on the Engineers side. Despite the potential need to start slow, I believe teams will see immediate productivity enhancements.

For the embedded MCP design system, start with a pre-existing design system (eg. AirTable, Material Design, etc.) to test with. These frameworks are fully featured, vetted in many ways, will simplify setup, and - with needed branding additions - could become the production design system (post pilot).