handbook gudeline: reuse existing design patterns

[corywatilo]

• avoid one-offs

[github-actions]

Deploy preview

Status	Details	Updated (UTC)
🔴 Failed	View logs	Mar 02, 2026 08:53PM

Push a fix or re-run the workflow to try again.

Common culprits

• MDX issues - unescaped </> characters, unclosed tags, or malformed JSX
• External API timeouts - GitHub, Strapi, or Ashby occasionally hiccup

[github-actions]

Vale prose linter → found 1 errors, 7 warnings, 0 suggestions in your markdown

Full report → Copy the linter results into an LLM to batch-fix issues.

Linter being weird? Update the rules!

contents/handbook/engineering/product-design.md — 1 errors, 7 warnings, 0 suggestions

Line	Severity	Message	Rule
11:4	warning	'v0.1 or v2?' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
17:5	warning	'v0.1' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
19:232	warning	Use American English. Use 'judgment' instead of 'judgement'.	PostHogBase.AmericanEnglish
21:5	warning	'MVP' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
27:5	warning	'v2' heading should be in sentence case, and product names should be capitalized.	PostHogBase.SentenceCase
39:107	error	Hi, Andy here... use an en dash ( – ) with spaces. On Mac, holding down the Option and hyphen key will give you an en dash.	PostHogBase.EnDash
57:226	warning	'UIs' is a possible misspelling.	PostHogBase.Spelling
69:40	warning	'commonon' is a possible misspelling.	PostHogBase.Spelling

[pauldambra]

suggestion on wording but 👍

[pauldambra]

Suggested change

	Avoid cramming in custom elements into commonon existing patterns just because there's space for something else. Creating one-offs leads to an inconsistent experience and confusion for end users. There are rare cases where you should deviate from this pattern. Before you do, always check in with the <SmallTeam name="platform-ux" /> to see if there's a better pattern to follow.
	Avoid cramming in custom elements into common existing patterns just because there's space for something else. Creating one-offs leads to an inconsistent experience and confusion for end users. There are rare cases where you should deviate from this pattern. Before you do, always check in with the <SmallTeam name="platform-ux" /> to see if there's a better pattern to follow.

[pauldambra]

Suggested change

	In any case, always copy existing UI patterns instead of creating new ones. Don't create a new version of something just because it's more convenient for your product. Take a few moments to look around how other products handle using the same component and copy the existing paradigm. This includes things like placement, sizing, and colors.
	In any case, prefer copying existing UI patterns instead of creating new ones. This means users' muscle memory will work for your scene when they first come to it.
	Don't create a new version of something just because it's more convenient for your product. Take a few moments to look around how other products handle using the same component and copy the existing paradigm. This includes things like placement, sizing, and colors.