How i work
Good design sits at the intersection of creativity, information, and outcomes.
I believe design is a function of business. It should look good, but it also needs to make sense for the people using it, support the people running it, and accomplish what the organization actually needs it to accomplish.
I also believe information is currency. The more we know about the problem, the people, the business, and what's already happening, the better decisions we can make.
So I don't like designing in a vacuum. I ask questions, look at the evidence, and try to understand what's actually going on before jumping into the pixels.
ORGANIZATIONS I'VE WORKED WITH
A few of the teams I've had the chance to work with.
START WITH THE PROBLEM
Before we solve it, let's make sure we're solving the right thing.
I want to understand what's actually happening before deciding what should happen next. That means asking questions, looking at the existing experience, understanding the constraints, and talking to the people involved. Sometimes the problem is exactly what everyone thought it was. Sometimes it's hiding somewhere else.
USE THE INFORMATION
Good ideas are better when they have something to back them up.
I believe information is currency. Analytics, research, user behavior, content, SEO, business requirements, and stakeholder feedback all give us pieces of the picture. I use that information to challenge assumptions, make better decisions, and figure out where there's actually an opportunity to improve.
MAKE, TEST, REPEAT
The best way to find out if an idea works is usually to make it.
Once there's a clear direction, I like to get things on the screen. I explore, test, refine, and learn as I go. I don't need every answer before I start—trying to figure everything out upfront is a pretty good way to spend a lot of time solving the wrong problem.
DESIGN FOR REAL LIFE
Because the perfect solution usually has a deadline.
There are budgets. Technology. Content. Stakeholders. Organizational politics. The occasional impossible request. That's just part of the job. Good design has to work within those realities. I'm willing to push when something can be better, compromise when it needs to be, and recognize when the simplest solution is actually the right one.
And once something launches, I want to know what happened. Did it work? Did people use it? Did we solve the problem?
If the answer is yes, great. If it isn't, that's useful too.
Make something better. Learn from it. Do it again.