About · Grant Wilkins
I’m interested in how things hold together.
I see products, organizations, games, and stories as systems: people making decisions with incomplete information, operating within constraints, and affecting what happens next. My work begins with the relationships underneath the surface—and often continues until an idea is concrete enough to test.
Approach
How I approach problems.
Understand the system before simplifying it.
I learn how people actually work, then map where decisions happen, what information they need, which constraints matter, and where changes create downstream effects. Interviews, observation, workflow models, and system relationships help make the structure understandable without pretending the complexity does not exist.
Make the thinking visible.
I externalize difficult problems through workflow maps, experience models, relationship diagrams, prototypes, rules, or documented assumptions—making the thinking concrete enough to discuss, test, challenge, and improve across design, product, engineering, and the business.
Turn assumptions into evidence.
I treat first solutions as hypotheses. Research, experimentation, prototyping, analytics, playtesting, and AI-assisted development shorten the distance between an idea and useful evidence. When it helps answer the question faster, I’m comfortable getting close enough to implementation to build a proof rather than waiting for a handoff.
Work as close to the build as the problem requires.
I don’t see research, design, systems thinking, and implementation as isolated stages. I move between them when doing so reduces uncertainty, exposes constraints earlier, or helps a team get to a working result faster. The goal is not to replace engineering. It is to reduce the distance between intent and outcome.
How I like to work
I’m most useful before the shape of the solution is obvious.
I like working where human behavior, system constraints, product decisions, and implementation meet. I’ll interview users when the uncertainty is human, model the workflow when it is structural, prototype when it is experiential or technical, and measure what happens when the question becomes behavioral.
Evidence has been a recurring part of how I work. At a national omnichannel retailer, I helped run more than 200 controlled experiments across the ecommerce experience. That volume changed how I think about testing: the goal is not to prove an idea was right, but to learn enough to make the next decision better. Some of the most useful results contradicted our assumptions, exposing overlooked customer needs and generating better hypotheses.
I value people who can challenge an idea without turning disagreement into territory. I care more about getting to a better answer than protecting the boundaries between disciplines or defending the first solution.
Principles
A few standards I return to.
Craft in service of meaning
Polish matters when it improves understanding, usability, emotion, or experience—not simply because something can be polished.
Systems built for stewardship
The best solutions can continue to evolve after their original designer steps away. They leave behind structure, reasoning, evidence, and tools that other people can work with.
Make uncertainty explicit
Hidden assumptions create false confidence. I’d rather name what we know, what we think we know, and what still needs to be learned so teams can make better decisions before uncertainty hardens into commitment.