Skip to content
HAv5.0
Docs

Principles

A few things I’ve learned from designing products, building systems, and staying close to the build.

  1. Be specific enough to check.

    “Prominent” leaves room for interpretation. A useful rule says what to do and gives people a way to check it.

    In practice
    At ecoPortal, I rewrote component documentation as structured, machine-readable rules.
    The cost
    It takes longer to write the rule and explain why it exists.

  2. Build systems with the people who use them.

    People route around rules they did not help shape. Systems work when the people using them can influence how they evolve.

    In practice
    At ecoPortal, each rule went through designer sign-off, with a review queue for primitives and regular pulse checks.
    The cost
    Publishing takes longer. Adoption comes easier.

  3. The data model shapes the experience.

    The experience is limited by the information a product can capture. Change the data model and you change what users can understand.

    In practice
    At Spotta, I changed reviews from one overall rating to category ratings, so street pages could show what was actually wrong. Review forms
    The cost
    Rebuilding a form that was already live.

  4. Constraints force the important choices.

    Constraints expose the decision that matters. When time and money are tight, focus becomes part of the product.

    In practice
    With one month of runway, I focused Trainest on a daily checklist and a score. That work holds 4.5 stars from 74 ratings.
    The cost
    Social features, ML-driven plans, and advanced analytics had to wait.

  5. Keep the whole product in view.

    Leading product design means connecting the user’s needs, the business goal, and the technical reality from the first decision through what ships.

    In practice
    At Trainest, I narrowed a broad fitness experience into a daily plan and Action Score, then stayed involved through the product, trainer platform, and supporting storefront.
    The cost
    It means working across unclear boundaries and being accountable for decisions beyond the interface.

  6. Stay close to the build.

    The build is where a design meets its real constraints. Staying close lets me catch what gets lost between intent and implementation.

    In practice
    At Trainest, I prototyped key interactions in code for developers. At ecoPortal, React components ship alongside their Figma source. Career changelog
    The cost
    More time in code and review, fewer new screens.

  7. Move faster. Keep the bar.

    AI helps me move through the work faster. It does not replace the judgment required to decide whether something belongs in the product.

    In practice
    At ecoPortal, I run audit tooling through adversarial review against the live system before trusting the results. Writing
    The cost
    Checking the output takes time. So does knowing when not to use it.