frontend-design: 입장이 있고 템플릿처럼 보이지 않는 화면을 만든다

누구에게 맞나

새 화면을 만들거나 기존 화면을 고칠 때, 의식적이고 알아볼 수 있는 시각 방향이 필요하면 frontend-design을 사용한다. 미학 방향, 서체, 템플릿 기본값처럼 보이지 않는 선택을 정하도록 돕는다.

더 잘 맞는 전제는 이번 일을 디자인 스튜디오의 디자인 책임자로 다루는 것이다. 고객은 이미 상투적이거나 템플릿 같은 안을 거절했고, 분명한 관점에 대가를 낼 의사가 있다. 이번 브리프의 배색, 서체, 레이아웃에 입장이 있는 선택을 해야 하며, 이유가 충분하면 미적 위험을 감수해도 된다. 자료에는 에이전트 제품 목록이나 설치 프로그램이 없으니, 특정 소프트웨어만의 기능으로 이해하지 마라. 공식 설명 페이지는

https://raw.githubusercontent.com/anthropics/skills/main/skills/frontend-design/SKILL.md

3분 만에 첫 시도 끝내기

이 설명에는 설치 명령이 없다. 첫 시도에서 저장소 경로나 패키지 관리자 명령을 지어내지 마라. 권장 경로는 자료에 있는 과정 그대로다. 먼저 plan, 그다음 브리프와 대조해 확인하고, 이어서 build, 마지막으로 critique.

전제: 화면 작업이 이미 있으며, 브리프가 짧아도 된다. 낮은 위험의 첫 동작은 위치 잡기만 하는 것이며, 코드를 바꾸지 않고 파일도 쓰지 않는다. 브리프에 제품이나 주제가 없으면, 구체적인 주제, 대상, 이 디자인의 주 과제를 먼저 정하고 제안으로 적어 요청한 사람과 확인한다. 확인 전에는 배색이나 화면 작성으로 들어가지 마라.

성공 신호: 세 문장으로 「누구를 위한 것인지, 무엇을 푸는지, 주제가 무엇인지」를 말할 수 있고, 상대가 끄덕이거나 분명히 반대한 뒤에야 고친다. 먼저 #F4F1EA에 가까운 따뜻한 크림 바탕을 깔고 고대비 세리프 제목과 테라코타 악센트를 더하지 마라. 자료는 이를 지금 생성 원고가 몰리는 특징으로 적는다.

사용 사례

사례 1: 브리프에 제품 정보가 없으면 먼저 맞춘 다음 디자인한다. 자료대로 구체적인 주제, 대상, 주 과제를 먼저 내고 제안으로 확인한다. 완료 기준은 이 세 항목이 확인된 것이며, 완전한 UI 한 판이 나온 것이 아니다. 확인에 어떤 도구를 쓸지는 자료에 없고, 구두나 글 모두 된다. 확인 전에 화면을 그리면 이 경로를 벗어난다.

사례 2: 이미 맞춘 브리프에서 서체를 결정한다. 자료는 제목과 본문이 각각 완전히 다른 서체일 필요는 없다고 한다. 한 가족을 쓰거나, 두 가족이면 분명히 구분되어야 한다. 의도적으로 고르고, 「어떤 프로젝트에나 쓰는 기본 서체」를 아무렇게나 집어 쓰지 마라. 요약은 행 길이를 80자 이내로 유지하라고도 하지만, 발췌에는 행 길이 검사 절차가 없다. 따라서 이 사례의 완료 기준은 서체 가족 수와 차이가 정해진 것이며, 조판 검사를 이미 끝낸 것이 아니다. 배색과 레이아웃도 이번 브리프에 맞춰야 하며, 크림 바탕에 테라코타 강조라는 흔한 조합을 재사용하지 마라.

사용 경계

과정은 plan, 브리프 대조, build, 그다음 critique다. 주제, 대상, 주 과제가 먼저이고 시각은 그다음이다. 서체는 한 세트 또는 두 세트, 만능 기본 서체는 거절한다. 자료가 지목한 생성 원고 몰림을 피한다: 따뜻한 크림 배경(#F4F1EA에 가까움), 고대비 세리프 제목, 테라코타 또는 따뜻한 점토 강조.

설치 프로그램이나 저장소 안 경로를 지어내지 마라. 자료에는 컴포넌트 라이브러리 목록, 기본 스와치 파일, 클라이언트 목록이 없다. 코드를 쓰거나 기존 스타일을 덮기 전에 제안이 받아들여졌는지 확인한다. 여기에 적힌 위치 잡기, 서체, 함정 밖은 이 설명이 다루지 않는다. 기성 템플릿만 씌우고 이번 브리프에 맞춰 고르지 않는다면 이 경로를 타지 말아야 한다. 먼저 브리프를 맞춘 다음, 이유가 있는 미적 위험을 감수한다.