Niki
Hey, I'm Niki
I untangle complicated
problems for a living.
8+ years designing and building B2B tools, mobile apps, and warehouse software — the kind where the wrong call has real consequences.
I'm a designer who builds. Not "I dabble in code" — I write React components and ship production features alongside the engineering team. That changes how I design. Before I finalize anything, I'm already thinking about what I'm setting the engineers up for. My best work happens when the problem is genuinely messy and the stakes are real.
Selected work
More work ↗Ops UX · Tablet · React · Trinity Apparel
Final Shipments Manager
"Warehouse workers were shipping packages wrong. The interface let them."
Redesigned a warehouse shipping UI for workers wearing gloves on mounted tablets. Reduced a shipment from 8+ taps to 2–3. Added address mismatch detection that hard-blocks bad shipments before they leave. Gave workers a debug console so they could self-diagnose errors instead of calling IT.
Mobile · React Native · Product strategy · Trinity Apparel
Trinity Pocket
"An app so generic it could have been anyone's. Now it belongs to Trinity."
Audited the existing third-party app screen by screen. Found 22 missing screens. Designed a native B2B mobile app from scratch — biometric login, Styleflow garment configurator, order tracking, client management — and sequenced five production sprints before a line of code was written.
Web app · Configurator · React · Trinity Apparel
Styleflow
"Dealers were choosing from thousands of fabrics using static PDFs. I gave them a live preview."
Designed and built a garment visualizer inside Trinity's dealer portal. Dealers select a base garment, filter a fabric catalog, pick trims, and watch a Picario-rendered preview update in real time. The final configuration generates a production-ready order summary — structured data, not a description.
Client Work — Hamburger Creative
Five responsive websites across four years. Brand identity, CMS, React builds, and front-end code delivered as a solo designer-developer.
How I work
Every project starts the same way: figuring out what the actual problem is. Not the stated problem — the actual one. I follow a loop, not a waterfall. The work doesn't stop when something ships.
01 · Understand
Read the room — and the codebase.
Talk to the people who do the job. Map the constraints before opening Figma. The best design decisions come from understanding what's actually hard, not what looks like a problem from the outside.
02 · Simplify
Cut until what's left is essential.
The first wireframe should answer: what's the smallest version of this that's worth building? Scope that can't be defended against a user need gets removed. Complexity hidden in the UI has a way of reappearing in the code.
03 · Prototype
Build something clickable before writing the spec.
A prototype surfaces every assumption the brief made. I prefer interactive over static — the right thing to argue about is how it feels, not how it looks in a mockup.
04 · Build
I write the front-end. Not redlines.
React components, production CSS, real edge cases. Working alongside engineers rather than handing off to them means the design survives contact with the real codebase.
05 · Validate
Ship, then watch.
I want to watch the people who actually depend on it. Not a structured test — just real usage. The edge cases you didn't think of always show up in the first week.
06 · Iterate
The first version is a hypothesis.
Everything after launch is evidence. The goal isn't to be right the first time — it's to be right quickly, and to build systems flexible enough to absorb what you learn.
Outside the work
I'm based in Birmingham, AL. For the past 8 years I've split my work between two places: Trinity Apparel, where I design and help build the internal tools that run the business, and Hamburger Creative, where I worked with clients across the country on everything from brand identity to React builds.
I got into design through photography. What that taught me — that a single framing decision changes everything — turns out to apply pretty well to software. The constraint isn't the enemy. It's usually the most interesting part of the problem.
I'm at a point where I want harder problems and a stronger team around me. I read the codebase before I open Figma. I ask a lot of questions early. And I'll tell you when I think something's going in the wrong direction — always respectfully, but honestly.
Designer + developer — I write production React. Not a portfolio skill; it's how I think about design problems.
8 years at one company — which sounds like a red flag until you see what got built. Multiple shipped production apps, real organizational complexity, and tools people depend on every day.
Started with photography — constraint-based thinking before product design had a name for it.
Comfortable in the details — I read API responses before wireframing. I write the component, not the spec for someone else's component.
Looking for harder problems — teams moving fast, stakes that matter, and room to own the work end-to-end.
Get in touch
Got a complicated problem to untangle?
I'm open to senior IC roles, contract work, and conversations about interesting problems. If you're building something hard and want a designer who can read the code, I'd love to hear about it.