Ben Howard

I build high-performance digital environments where business strategy and technical feasibility meet. With a d.MBA lens, I don't just design interfaces — I orchestrate the systems that make them scalable. From modernizing 20-year-old legacy records for the U.S. Air Force to navigating the high-stakes regulatory landscape of Pfizer's Gen AI tools, my work is defined by bridging the gap between design vision and engineering reality.

When I'm not auditing data models, you'll find me in Houston with my wife, Dakota, and our dog, Darcy. I'm a fan of technical apparel, intentional craft, and a perfectly executed “Howdy.”

Why the d.MBA

I pursued the Design MBA (d.MBA) because I kept running into the same ceiling: I could design a strong solution but couldn't always make the business case for why it was the right solution. That's a credibility gap that matters at the table where resourcing and roadmap decisions get made.

The program is specifically about operating at the intersection of design and business strategy — not to become an MBA, but to stop being the designer who gets cut from the room when the P&L conversation starts. It changed how I frame problems, how I write case studies, and how I communicate with stakeholders who don't care about design but very much care about outcomes.

The immediate effect: I started leading with business outcomes instead of design rationale. That one shift changed the reception of my work with executive stakeholders more than any other single change I've made in how I communicate.

How I Work

Start with the organizational problem

Most design briefs describe a UI problem. The real problem is usually upstream — in a workflow, a data model, a stakeholder misalignment, or a business model constraint. I spend disproportionate time in the first two weeks of any engagement trying to locate that upstream problem before committing to a design direction.

Design the handoff as carefully as the product

A design that doesn't survive the designer's departure isn't finished. That means documentation a future team can actually maintain, a governance model that specifies who owns what decisions, and engineering partners who understand the intent behind components well enough to make good tradeoffs on their own.

Translate fluently in both directions

Between users and business stakeholders. Between design and engineering. Between what exists today and what's possible to build. My d.MBA was specifically about developing business-language fluency — not to become a businessperson, but to be a designer who can operate credibly at the table where strategy gets made.

Bring constraints in early

Technical, regulatory, procurement, organizational — these aren't blockers to good design. They're design inputs. The best work I've shipped has been designed with constraints at the center, not around them.

Currently

Open to Staff / Principal Designer roles at enterprise SaaS companies and top-tier consulting practices where design operates at the strategic level — particularly teams building AI-native products in complex, regulated, or mission-critical environments.

Get in touch →