Public Trail

A public trail is the connected public artifacts that replaced the static portfolio for design hiring in 2026. It consists of one shipped product with a live URL and real users, three short decision logs that expose your thinking, one piece of writing that demonstrates judgment, a GitHub repository with actual code or Claude Skills, an Are.na channel annotated with your taste signals, and a consistent presence on Threads, Twitter, or Instagram that shows you can ship thinking weekly. This trail lets hiring managers assess taste, velocity, and clarity in ninety seconds instead of wasting time on polished fiction. The good teams no longer open twelve page case studies. They click the live product, read the log, scan the writing, check the GitHub history, and decide. The trail lives outside any single template. It spreads across platforms but connects through a central Read.cv page that acts as the hub. Designers who maintain one build compounding evidence that AI cannot replicate. Speed to ship becomes visible. Range across disciplines appears. Judgment shows up in plain text. The trail turns shipping into signal and doubt into documented learning.

A public trail is not the old portfolio format. It is not a forty hour Behance deck stuffed with hero images, fake problem statements, invented personas, journey maps that no one followed, wireframe galleries, mood boards pulled from Pinterest, and perfectly lit mockups. It is not a collection of six Dribbble shots that look good in isolation but connect to no real product or decision. It is not concept redesigns for Uber or Apple or Nike that never saw production code or a single user test. It is not a beautiful resume website with zero links to shipped work or public thinking. It is not generic interfaces built on shadcn or Material UI with only color swaps and no original systems thinking. It is not process theater that pretends every decision was clean and inevitable from the first sketch. Those artifacts cost serious time and deliver the opposite of signal to hiring managers at Linear, Vercel, and Anthropic. They tell the hiring manager you optimized for school critique instead of real shipping pressure in an AI first world.

Take the trail built by the designer who created a Figma to Tailwind plugin shipped in March 2025. The live product sits at figmatotailwind.com with twelve hundred active users, public Stripe receipts, and usage analytics posted without spin. The decision log on her Read.cv runs exactly three tight paragraphs. She explains why she chose to limit scope to Tailwind only instead of every framework, how she cut the AI suggestion feature after it hallucinated bad code three times in beta, what data changed her mind on dark mode defaults, and what she would rebuild today using Claude 3.5 Sonnet artifacts. Her writing piece, a six hundred word essay posted to Threads that dissected why most handoff tools fail product teams at scale, racked up two hundred reposts, replies from engineers at Vercel, and sparked real conversations that led to two job interviews. Her GitHub shows the actual repo with 89 stars, fourteen pull requests from users, and regular commits dated week by week over six months. The Are.na channel maps her research with one line notes like this pattern works because it respects developer constraints attached to specific examples from Linear and Vercel interfaces. Her Twitter posts weekly breakdowns of product launches from companies like Stripe, Ramp, and Perplexity with clear opinions on what they got right and wrong. This entire trail took her twelve hours to assemble after the product shipped. Compare it to Pieter Levels who treats every product as its own trail. Nomad List shows user numbers, revenue, the stack choices, the failures when he pivoted from paid to freemium. Brian Lovin logs every project on his site with the same brutal honesty. Linear hires read these trails first because they hit every deep review criterion: process clarity in the logs, taste range in the writing and Are.na, speed visible in fresh commits.

Deploy a public trail when you target forward leaning teams in 2026. Roll it out for product design roles at Linear where the job post literally asks for writing samples, shipped code, and public logs. Use it when interviewing with Vercel because they built v0 and they respect designers who ship at similar speed. Build the trail for Anthropic and Anysphere openings since those teams run on engineering fluent designers who document their Claude workflow publicly. Use the trail if you want to run a solo design studio and turn the artifacts into an inbound funnel that attracts clients who already get your taste. Start the trail as a junior by shipping one small tool this weekend with Cursor or v0 or Claude Code then logging the ugly compromises you made under real deadlines. The trail fits when you need to prove range from SaaS dashboard to brand identity system to motion prototype without losing coherence. It works when velocity matters more than perfection and when you have the receipts to prove you move fast.

Avoid the public trail when the company still uses traditional hiring funnels with ATS systems that only accept PDFs or when the creative director demands a printed leave behind. Skip it for freelance pitches to marketing agencies that demand full case studies with journey maps and competitor analysis slides. Do not publish a trail if it contains only school projects with no production evidence or real users. Never lead with the trail if you cannot point to at least one live URL with users who actually used the thing. In those cases ship the product first then document the decisions honestly. The trail amplifies real work. It does not substitute for it. Two weekends of shipping and writing beats two months of polishing pixels no one will open. The designers who ship the trail while everyone else polishes invisible case studies are the ones getting the calls from the teams that matter in 2026.