Most product designers came up through tech. I came up through seven years of print — layouts that had to work perfectly the first time, with no ability to push a fix later. That background shows up in everything I build.
I spent seven years as a designer at Living Magazine — laying out feature spreads, managing print production, and building visual systems under real deadline pressure. Print doesn’t iterate. You get it right before it goes to press, or it’s wrong in 30,000 copies. That builds a different kind of eye.
When I moved into product design, I didn’t leave that behind. The typography rigor, the layout instincts, the care about spacing and hierarchy — those things transferred directly. I just learned to pair them with user research and systems thinking.
I have a BFA in Graphic Design from the Art Institute of Dallas and a UI/UX certification from Springboard — but most of what I know came from doing it. Currently I’m Lead Designer at 834 Labs (full-time) and co-founder at InnoGEV on the side. The two roles together have taught me more about product design in two years than anything else.
I start with the permission model, the data architecture, the user’s mental model of what they’re actually trying to do. For MyAdmin360, I spent weeks mapping the information architecture across three user tiers before I designed a single component. The visual work comes later — and it only lands because the structural work is solid.
The problems I find most interesting are the ones where the complexity is real — multi-role platforms where the same data needs to look completely different depending on who’s logged in, or legacy systems where users have built years of workarounds you have to respect while still improving things. Those constraints make the design problem interesting.
I use AI heavily — for research synthesis, rapid prototyping, and proof-of-concept builds. I built the MyAdmin360 interactive prototype solo using Claude, deployed it live at app.myadmin360.com, and presented it to stakeholders. It’s become my default way of validating ideas fast before committing to full design.
Navigation, permissions, and data hierarchy come before the first frame. Get the structure wrong and every screen that follows it will also be wrong.
User interviews, workflow shadowing, heuristic audits — every major decision needs a reason that isn't "I think." That's how I push back on bad ideas without making it personal.
One polished screen is a deliverable. A design system that lets engineers build new features without coming back to design every time — that's the real output.
Enterprise products carry a lot of data. The job isn't to remove it — it's to build visual patterns so consistent that users navigate the complexity without having to think about it.
If design only enters the room after engineering has scoped the work, you’re paying for a skin, not a solution. The conversations I care about are the early ones — where tradeoffs are still being weighed and the right design question can change what gets built entirely.
I work closely with engineers and try to make handoff as painless as possible. I build component-based designs, document states and edge cases, and I’ve co-developed and deployed production code at 834 Labs. I’d rather spend an extra hour in handoff than have the team build the wrong thing.
I push back when I need to — but always with something to back it up. On AgilityFMO, stakeholders kept wanting to add content to the homepage. I used agent research to show exactly which actions were getting buried and how many clicks it added to the contracting flow. That kind of conversation is easier when the data is doing the talking.
Senior IC or lead — somewhere the design problem is genuinely complex and the team takes design seriously. I’m in Dallas and open to remote. B2B SaaS is where I’ve done my strongest work, but I’m interested in any domain where the UX problem requires real systems thinking.
Multi-role platforms, complex data, high-stakes workflows. The harder the IA problem, the more useful I am.
Starting from nothing, or inheriting something broken. Both are interesting. Both require the same thing: actually understanding the problem before touching a frame.
I want to work alongside product and engineering, not get requirements thrown over a wall. The best work happens when those conversations happen together.
Currently open to senior IC and lead roles in B2B SaaS. I work best where the problem is genuinely hard — complex hierarchies, legacy-to-modern transitions, or 0→1 product builds.
