feat: strengthen design skill and refresh all showcases
Some checks failed
ci / build (push) Has been cancelled
Some checks failed
ci / build (push) Has been cancelled
This commit is contained in:
parent
69e5cc1efd
commit
e09d4efb1c
257 changed files with 8196 additions and 2374 deletions
|
|
@ -54,6 +54,8 @@ description: "웹 디자인 전 과정을 끌고 가는 파이프라인 스킬.
|
|||
|
||||
| 판단 질문 | 읽을 문서 | 꺼내 쓸 항목 / 남길 결정 |
|
||||
|---|---|---|
|
||||
| 바우하우스·타이포그래피 대가의 관점을 이 화면에 어떻게 적용하는가? | `references/visual-design-lineage.md` | 원전·기관 해설의 확인 범위, 서로 다른 관점, 현재 매체·언어에 맞는 적용 질문 |
|
||||
| 미적 호감·복잡성·읽기·정보표현에 실험 근거가 있는가? | `references/visual-perception-research.md` | 논문의 과업·측정 대상·표본 한계, 선호와 실제 성능의 구분 |
|
||||
| 무엇을 먼저 보이게 하고, 어떤 구도·이미지·크롭이 과업을 돕는가? | `references/art-direction.md` | 콘텐츠 우선순위, 시선·여백·이미지 역할, 크롭 비교와 선택 이유 |
|
||||
| 이 원칙이 보편 규범인가, 특정 사례·실무 지침인가? | `references/design-foundations.md` + `references/evidence-ledger.md` | 주장 종류(원론·규범·실무·사례·전망·서지), 출처의 조건과 적용 여부 |
|
||||
| 이 브리프에 맞는 시각 언어와 피해야 할 관습은 무엇인가? | `references/style-playbook.md` | 스타일의 표현 수단·주의점, 브리프에 맞춘 변형 |
|
||||
|
|
@ -228,6 +230,8 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
|
|||
|
||||
이 단계에서 `references/style-playbook.md`를 읽어 선택한 스타일의 표현 수단·주의점·적용 조건을 검토한다. 이론이나 스타일 이름은 결론이 아니므로, `design.md` 또는 프로젝트 evidence 기록에 출처 ID → 원칙/조건 → 관찰 → 결정 → 검증 계획을 남긴다.
|
||||
|
||||
새 방향이면 [art-direction.md](references/art-direction.md) §3의 **구도·타입·색 결정표**를 실제 재료로 세 축 모두 채운다. 국소 변경이면 영향받는 축만 채운다. 표의 관찰 → 가능한 원리 → 작은 대안 → 채택 근거/기각 조건 → 역할 토큰 기록을 이 단계의 결정 근거로 쓴다.
|
||||
|
||||
정해야 할 것:
|
||||
- **한 문장 컨셉** — 이 사이트가 주는 인상을 한 문장으로. ("고급 잡지의 여백", "계기판처럼 정확한", "밤의 스튜디오")
|
||||
- **미학 프리셋** — 아래에서 고르거나, 브리프가 요구하면 새로 정의한다
|
||||
|
|
@ -257,6 +261,8 @@ headed 브라우저가 있으면 스크린샷과 실측값을 바로 받는다
|
|||
- **폰트를 고르고 싣는 법** → `references/typography.md`. 폰트는 값이 아니라 결정이다. 로딩·폴백 메트릭·라이선스가 여기 있다
|
||||
- 한글이 들어가면 → `references/antipatterns.md` 의 한글 조판 섹션을 **반드시** 읽어라. 서구 레퍼런스에는 이 정보가 없다
|
||||
|
||||
2단계에서 비교한 실제 렌더를 초기값으로 삼아 역할 토큰을 확정한다. 숫자·색상값·서체 이름만 모으지 말고, 각 토큰이 어떤 정보 역할과 좁은 폭·상태에서의 관찰을 해결하는지 기록한다.
|
||||
|
||||
**성능 예산도 여기서 정한다.** 나중에 정하면 이미 늦는다. 전체 표는 `references/tokens.md` §5 하나뿐이다 — 다른 문서에 예산 표를 만들지 마라.
|
||||
|
||||
기본선: 히어로까지 JS **150KB(gzip)** / 첫 인터랙션 **3초**. `transform`·`opacity`는 저비용 기본 선택이다. 다른 속성 또는 스크롤 기반 로직은 자동 금지가 아니라, 측정한 비용·입력 간섭·감소 모션 경로·프로젝트 예산을 기록하고 실제 기기/브라우저에서 검증한다.
|
||||
|
|
@ -321,6 +327,8 @@ HTML-in-Canvas(`drawElementImage`)는 **폴백을 완성한 뒤에만** 얹는
|
|||
5. **상태 완결성 스윕** — 입력·파괴·열림이 있는 화면은 실제로 조작해 본다: 수치 입력에 범위 밖 값을 넣고, 파괴적 행동을 되돌려보고, 열린 메뉴를 Esc 로 닫는다. 기준은 `references/preflight.md` §4-1. 통과 못 하면 4단계로
|
||||
6. **상태별 시각 E2E** — URL별 390·1440 기본 화면과 결과·오류·모달 같은 핵심 상태를 캡처한다. 하니스는 개수·규격·0바이트·중복 해시를 단언하고, 캡처를 실제로 열어 목표 시장 적합성·시선 위계·이미지 크롭·반복을 눈으로 판정한다. 구조 PASS를 시각 PASS로 바꾸어 말하지 않는다
|
||||
|
||||
전후 증거는 같은 viewport·상태·카피·자산으로 보존한다. [art-direction.md](references/art-direction.md) §7처럼 질서·표현성·완성도를 각각 강점·문제·스크린샷 근거로 판정하고, 대표 실제 과업 시나리오로 회귀를 확인한다. 참여자 측정이 없으면 사용자 속도·이해도·전환은 미측정으로 남긴다.
|
||||
|
||||
> 게이트가 잡은 실제 사고 목록과 7계층 설계 근거는 `references/audit-gate.md` 다. 자기 검사 스크립트를 매번 새로 쓰지 마라 — 이 게이트를 심고 확장해라.
|
||||
|
||||
#### 규범·기능 하드 게이트 — 전부 충족해야 한다
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue