Understand the job and the constraint.
Users, evidence, business goal, technical limits and the current behavior that is creating friction.
Design systems + handoff
A design system should remove repeated decisions without flattening the product.
I build practical Figma systems around the decisions a product repeats: typography, spacing, components, states, responsive behavior and interaction rules. The goal is not a larger library. It is a shared language design and engineering can actually use.
When this is useful
Useful when screens drift, teams rebuild the same component repeatedly or implementation depends on designers explaining the file from memory.
Typical scope
- Foundations and semantic tokens
- Component variants and interaction states
- Responsive behavior and content rules
- Usage guidance and contribution conventions
- Developer handoff and UI QA
A concrete handoff example from this portfolio
The screenshot component on this site has an implementation contract, not just a visual appearance. Each approved capture has a stable source record, original-image hash, capture date, alt text, caption and responsive variants.
- The selected frame or component stays intact; a complete original view remains available when a focused excerpt is used.
- Width and height are declared; WebP variants at 640, 960 and 1440 pixels let the browser choose a suitable download.
- A source link and complete original remain available for inspection, while the caption separates the current public demo from earlier project work.
This is an example of this portfolio’s implemented component contract, not a claim about a client’s private Figma library. A useful design-system handoff should make similarly concrete decisions about states, content, responsive behavior and implementation checks.
Inspect the implemented capture and its original or read the developer-handoff notes.
Make the product decision explicit before making the screen look finished.
Resolve flow, hierarchy and states.
Turn the problem into reviewable decisions before high-fidelity design makes ambiguity expensive.
Design for the implementation.
Responsive rules, components, interaction notes and QA make the work useful after handoff.
See the decisions in real project context.
Orkest HQ
A shared product grammar for CRM, Sales, Inventory and Finance, designed so the modules feel related without pretending their operational jobs are identical.
Read case study
Masteriyo
Product-design work inside an established LMS, covering course authoring, quizzes, learner states and reusable patterns that had to fit an existing system and a larger design team.
Read case study
Hamro Idea
A software-studio rebrand and multi-page website designed and built as one system, from positioning and service architecture to responsive implementation and search structure.
Read case study