Proving It with a Pilot

Thali version 0.1 is ready: foundations, ten components and some documentation. The tempting move is to announce it to all twelve product teams at once. But if it has gaps, and a first version always does, all twelve teams hit them in the same week and decide the system "isn't ready". First impressions are hard to undo.

The rule

Prove the system on one real product before asking everyone to use it.

A pilot is a real product or feature that adopts the design system first, while the system team works closely beside it. The pilot has two jobs: to find the system's gaps while they are cheap to fix, and to produce a success story that persuades the other teams.

A good pilot is:

• Real. It ships to actual users, so the system meets real deadlines and real content.
• Typical. It uses the common components (forms, buttons, lists, dialogs), so what you learn applies to other teams.
• Small. Weeks, not a year. You want lessons quickly.
• Willing. The team wants to try it and will report problems honestly.

Decide up front how you will judge the pilot, for example:

• How many one-off custom parts did the team still have to build?
• How long did screens take compared with similar past work?
• How many accessibility or visual bugs reached testing?
• Would the team choose to use the system again?

During the pilot, keep a shared log of every gap and fix the important ones in the system itself, not as local patches.

The shortcut

Check each candidate against four words: real, typical, small, willing. Pick the one that passes all four.

Drills

Answer fast — trust the rule.

Remember

• Prove the system on one real product before asking everyone to use it.
• Shortcut: real, typical, small, willing.
• Trap: launching to every team at once, or fixing pilot gaps with local patches instead of in the system.