- SignalDesk1小时前
Original Summary
I f****ing hate building landing pages. Absolutely despise it. For this product this must be version 10+. Maybe even 15+. It's been getting better everytime - but this time it really feels like a high level design that represents my product more than ever before, and it was the easiest to deliver so far, so I wanted to share the process. The reason I decided to yet again re-design was becasue I saw a website from some other company which I liked and I suddenly felt like mine wasn't really that great. They're not a competitor, completely different product, simply same kind of audience: developers. So my only real brief to Claude at the start was "I like how ___'s homepage feels." and then basically asked it how we can we build a process that when done would have a similar vibe website for my product. I'm happy with how it turned out, and the process is what made the difference, so here are the main steps. 1. Teardown first, no code. Before building anything, I had Claude take the reference homepage apart: screenshots at several widths, how the motion behaves, spacing, typography, how sections hand off to each other. Then it wrote down which principles were worth borrowing. It also did an inventory of my existing site (every page, link, claim and asset) so nothing would get lost in the rebuild. This part is importent - it really helps if it already has context about your project - the more the merrier. I've ran this in the same directory which I have for all repos of my project, so it had ALL thhe context it's needed. I'd recommend you do the same. Open the directory wherever claude can also see all other files relevant for your project. Make things easier if it sees everything rather than you having to tell it everything. The most useful rule came out of this step: the reference is a reference, not a template. At first it kept forcing my content into their structure: their number of sections, their kind of demos. Once I said "copy the feel and the craft, not the layout", the work got much better. 2. PRD → plan → task list. Next came a short PRD (what the site must do, the positioning, hard requirements like "the hero must be clear on mobile"), then a technical plan, then a task list split into phases. I didn't really review each document before moving on because I'm using these skills a lot and trust them. These are specific ones I wrote a few months ago, but if you're not familiar with prd -> plan -> tasks flow, look at Matt Pocock skills. 3. Guardrails before pages. The first phases weren't pages at all: Design tokens for every color, plus a lint rule that fails the build on any raw color. I just made it dark mode for this v1 and potentially will also keep it as such, but I wanted to make sure that everything is tokenized from the start so if I DO want a light mode later - it will jsut be creating light mode tokens. One "facts" folder holding every pric
- 情报分类:技术学习与提效
- 分类依据:内容涉及技术、AI、软件工具或工程实践
- 信息来源:Reddit · SideProject
- 发布时间:2026/10/5 01:15:00
- 暂无回复