what i think about design (engineering)
design has changed a lot this past year. i talk to designers every week and i'm also trying to build out a product design team, so i wanted to write down how i think about ai-generated products, speed winning over craft, and where design ends and engineering begins.
understand before i make
i start with the actual problem, the outcome we're after, and the real constraints, not whatever solution i already like.
- question my own assumptions and check direction early, before i'm deep in it.
- understand the code and the product before i touch either.
- use ai to move faster, not to think for me.
- if i can't explain how something works and why it's right, i don't own it yet.
own the experience, not the handoff
i take responsibility from framing the problem through to production and what happens after it ships.
- work across product, design, and engineering, not just my lane.
- prototype in whatever medium answers the question best.
- code, interaction, content, docs, and support are all part of the same experience.
- stay involved until what ships matches what i intended.
make trust effortless
privacy, clarity, accessibility, and reliability have to be there from the start, not bolted on later.
- hide complexity people don't need, never the consequences that matter.
- make the safe choice the easy choice.
- design for different abilities, skill levels, devices, and circumstances.
- i won't trade someone's trust for engagement or convenience.
move fast by making less, better
when time's tight, i cut scope before i cut quality.
- ship the smallest thing that's complete and coherent.
- know what has to be excellent now versus what can genuinely wait.
- i'd rather make real progress on one thing than leave five unfinished.
- the quality floor doesn't move; scope above it is what's negotiable.
finish the work
a happy path that works isn't the finish line.
- every state, edge case, word, transition, and response time matters.
- accessibility, performance, and polish are the product, not extras.
- i plan time for the final pass, not just the build.
- i'll push back if a deadline would leave something visibly unfinished.
make quality repeatable
craft should compound over time, not depend on heroics.
- turn the decisions i keep making into shared components, defaults, tools, and checks.
- help engineers get better at design and designers get better at code.
- share work early and explain my reasoning, not just hand over the result.
- leave people better equipped to do great work without me.
these are meant to be practical. i use them when i'm planning projects, reviewing work, hiring, and deciding what to cut when priorities collide.
the one i expect to lean on most is moving fast by making less, better. i need to move quickly to compete with companies that have far more people and resources than i do. but if every deadline chips away at the quality bar, i'll never build the practice or product i actually want.
these will probably keep changing as tech evolves and i grow. for now, this is how i want to work and what i want to hold myself to.