Designing with Hypotheses: How AI and Systems Thinking Redefine the Creative Playground

A conversation with Will Kesling, Head of Design, US Servicing at TD.

By Louise Servoin · 2026-07-15 · 5 min read

The design field is in the middle of a structural pivot. As generative tools learn to draft polished interfaces in seconds, the job is shifting from arranging screens to architecting the cognitive systems behind them. To understand what that means for the next generation of designers, we spoke with Will Kesling, Head of Design, US Servicing at TD; a leader whose philosophy was forged in two unlikely worlds: the discipline of the U.S. Marine Corps and the rigor of design education, where he taught responsive web systems as an Associate Professor at Cleveland State University.

## A layout is just a hypothesis

Years ago, Kesling wrote a now-cited critique arguing that "a website is not an outcome" — a takedown of the idea that design can be sold from a fixed price list like a commodity. The point, he says, was never about the artifact. "Clients who want a thing designed really want that thing to help with a business outcome. How it looks, how it works — all of it should support getting to that outcome. And understanding the outcome requires close collaboration with the client."

In the age of generative AI, he argues, that logic only sharpens. Products and services, in his view, are all experiments until they succeed or fail in the market — and AI doesn't change that contract. "A polished interface generated from a prompt is still just a hypothesis," he says. What AI does change is the speed of iteration. He reaches for a gladiatorial metaphor: AI lets teams run far more cycles in the Ludus Magnus — the training school — before a product ever steps into the actual arena.

But faster drafting comes with a warning. The fact that anyone can now prompt an interface into existence doesn't make them an expert in the disciplines underneath it. "If you lack the fundamentals of each discipline you just used AI for, how will you evaluate the quality, the stability, the vulnerabilities?" In low-risk situations, he says, that may be fine. In others it can carry serious consequences for a business. His baseline recommendation is unglamorous and firm: depending on the level of risk, have whatever AI built evaluated by human subject-matter experts.

## Co-pilot, not crutch

That skepticism carries into how he thinks about training designers. When Kesling taught ART 347, the goal was never just clean HTML5 and CSS3; it was empathy for the end user and fluency in the interdisciplinary exchange with engineers, programmers, and marketers. His first question about any "learning co-pilot" is a technical one: what kind of model, and for what? He's wary of reaching for general-purpose GPT-style models in the classroom, leaning instead toward more constrained setups — standard models, or retrieval-augmented systems with a model acting as the brain. The deeper concern is pedagogical. "Learning happens when new concepts are put into action — testing, failing, and getting slight nudges along the way," he says. "My fear is that students skip the action part. It's often the act of making mistakes and struggling where we learn the most."

He's not convinced an answer handed over by a model counts as learning at all. "Getting an answer that may or may not be accurate, without your own point of view on the why behind it — is that learning?" You could, he concedes, design prompts that demand quotes and reference pages. The harder problem is human: "Will the student actually look up the reference and trust-but-verify? Do professionals who use these tools even do that?" His bottom line: AI can hand you answers or code, but you can only judge whether they're right if you once learned how to find out for yourself.

Even his enthusiasm for AI as a coaching layer comes with a caveat he's careful to flag. He's still testing the idea in his own practice — and he's not ready to make AI the only well he draws water from.

## From craftsman to system architect

Kesling's interest in game design isn't a hobbyist's detour; in a Medium series, Why Every UX Practitioner Should Build a Game, he argues that building a game forces rigorous thinking about system boundaries, mechanics, and feedback loops. "Game design leaves little room for error. You have to think through all the scenarios, test the edge cases, understand the limits of the engine," he says. "That's like a gym for your brain. It's food for us."

He's deliberately modest about extending that straight into instructing AI. "I view AI as a tool that humans choose to wield," he says. Before bolting AI onto any system, he wants to understand the whole thing end to end — every piece, every step — and only then ask where a tool might genuinely enhance the humans moving through that journey. Sometimes the honest answer is that the broken piece doesn't need AI at all. "What's the saying — when all you have is a hammer..." The game-design fluency, in other words, isn't about confident AI orchestration; it's about the discipline to map a system before deciding whether a tool belongs in it.

## Scaling without losing the human

At enterprise scale, the same discipline holds. At TD, the iD8 ideation program has crowdsourced more than 100,000 colleague ideas under the TD Invent umbrella. But Kesling is clear that scaling AI isn't about deploying a tool and hoping for the best. "It starts with the fundamentals," he says. "Before the tools are even through the gauntlet of procurement, we need to upskill every employee."

Just as important is knowing your baseline. "We need good pre-AI measurements in place so we can run meaningful experiments — how do our people do their jobs today, with what tools, in what conditions, with what results?" Without that, there's nothing to compare against. And he returns, repeatedly, to the part of any system that doesn't show up in the data: the people. "Often it's humans and their invisible work that keep a system from failing. Models are trained on data, but they don't have lived, real-world experience or specific domain context." The goal, he says, is to have human experts use the tools — not be used by them.

Which is, in the end, his whole thesis in one line: AI as a co-pilot only works if the human in the seat actually knows how to fly.

Tags: design, generative ai, systems thinking, ux, design education, enterprise ai