Webcraft direction

Choose a visual language using real site content. Produce rendered concepts and 05-direction.md; a palette description or moodboard alone is insufficient.

Use upstream domain guidance when the relevant UI work begins. Fetch only the needed domain and its supporting references. For motion work, follow Emil Kowalski’s upstream guidance for this stage.

Start or resume

Read 00-project.md, the brief, relevant plan/copy, and view the current wireframes. Accept equivalent inspected inputs. If the project setup or usable wireframes are missing, identify the missing input and recommend the appropriate earlier Webcraft stage; do not silently create it.

Create concepts, resume incomplete exploration, or revise the requested visual choices. If the direction is complete and no changes were supplied, ask what to reconsider. Preserve constraints and confirmed choices. If the user already supplied a visual system, demonstrate and refine its application rather than inventing competing identities.

An explicit restart may rework this stage; preserve its prior milestone through existing history or a scoped snapshot. Approval belongs to a specific revision and does not automatically carry over to substantive edits.

Explore with comparable content

Use available frontend-design guidance for aesthetic judgment, bounded by the brief and this stage. Ground choices in the audience, subject, and supplied brand. Select representative content that tests the direction: an opening section, content with realistic density, and a conversion or interaction section. Keep content comparable between alternatives.

When the direction is open, render a small set of meaningfully different concepts, usually two or three. Different font/color swaps on an otherwise identical generic layout are weak alternatives. Compare hierarchy, typography, imagery, composition, and how the direction serves the brief. Do not force alternatives when a direction is already established.