Design is the argument we make about what matters.
"Make fast, consistent, defensible design decisions instead of arguing about aesthetics."
Ali AhmedWhy this exists
Taste without process is decoration. Process without taste is bureaucracy. This handbook is the spine holding both together. It gives every designer and engineer on a Kryft project a shared vocabulary and a shared standard. We want to stop relitigating the same questions on every engagement.
Operational Flow
Components: Decide what deserves to become a reusable piece and what stays a one-off.
Tokens: Define and enforce the visual language across every surface.
Layouts: Build screens at every size without writing five separate stylesheets.
Copy: Write clear words inside the UI, including labels, errors, empty states, and tooltips.
Speed and Simplicity: Prioritize shipping something real over perfecting something imaginary.
What good looks like
- A designer hands off a component spec and an engineer implements it without a single Slack message.
- Token names mean the same thing in Figma, code, and conversation. Nobody says 'the greyish blue' anymore.
- A new engineer reads one handbook entry and understands why we made a decision six months ago.
- Copy reviews take ten minutes because everyone already knows what our error message voice sounds like.
What NOT to do
- Don't read this handbook once and assume you are done. Revisit these entries when decisions get difficult.
- Don't use these rules to win arguments. Use them to end debates and move forward.
- Don't treat this as a creative straitjacket. It describes minimums and defaults, not ceilings.
Design at Kryft is not about making things pretty. It is about making fast, documented, defensible decisions. This prevents the team from rehashing the same debate on every project. We have lost hours arguing about button radii and modal sizes on client calls. When you start a design practice, you quickly realize the real enemy isn’t bad taste. The enemy is indecision dressed up as thoroughness.
This handbook gives you our defaults. Use them. If you deviate, write down why. The goal is velocity with coherence, not uniformity. A team that internalizes this handbook doesn’t need to ask how a feature should look because they already know how we think.