Iterative logo and brand design

Work with the user as a design collaborator. Produce visible artifacts at each meaningful stage. Make decisions from the brief and observed legibility, not from the cleverness of a hidden symbol. Keep selected work intact while exploring alternatives; feedback on one part of a mark does not reopen every approved choice.

This is an independent, reusable workflow informed by common professional identity practice and by Allan Peters' publicly shared emphasis on exploration and refinement. It is not his official process, a transcription of his videos, or an affiliated skill. See Peters Design Co's book page for his own work.

Choose the scope

Infer the mode from the request and existing assets; ask only if the distinction would change the work:

• Exploration: establish the brief, compare distinct concepts, and help select a direction. Rough concepts are a valid stopping point when that is the requested deliverable.
• Refinement: preserve the chosen direction and approved elements, revise the requested features, and recheck affected sizes and applications.
• Production: use the selected artwork to prepare and verify the requested variants and exports. Resolve missing decisions without reopening concept exploration by default.

Use only the stages and deliverables relevant to the request. A favicon adjustment does not require a new wordmark, palette, or full brand system. Follow an explicit request to choose autonomously; otherwise pause at choices that materially determine the design direction.

1. Frame the brief

Ask only for missing decisions that would materially change the work. Establish:

• Exact brand name and what it does; audience and key use cases.
• A few desired traits and associations to avoid, when exploring or changing the identity.
• Existing mark, colors, typography, assets, and constraints to preserve.
• Required surfaces: app icon, favicon, docs, product UI, social avatar, print, signage.
• Whether the user wants exploration, refinement of an existing mark, or final production assets.

Summarize the brief in a sentence and note any assumptions. Inspect supplied visuals before proposing changes. If asked to emulate a named designer, study relevant primary sources before attributing any specific method, and create original work rather than a near copy.

2. Build a concept vocabulary

List concrete nouns, actions, shapes, and tensions from the product story. Translate each into possible visual operations: overlap, cutout, alignment, repetition, enclosure, motion, scale, or negative space. Pair ideas only when the combination improves immediate recognition. Avoid forcing a symbol to narrate every aspect of the business.

Set two or three criteria before drawing, such as distinctiveness, category fit, small-size clarity, and ease of one-color reproduction.

3. Explore broadly, then curate

Create a contact sheet of meaningfully different rough directions, not many cosmetic edits of one idea. Use short IDs and one-line rationales so feedback can refer to a specific concept. Show the image inline and provide editable vectors when practical. Do not imply that a mockup is editable in Figma unless it has actually been placed there.

Favor fast monochrome sketches early. Explore distinct visual strategies justified by the brief; literal, abstract, typographic, and negative-space approaches are options, not a required checklist. Present shortlisted marks at comparable visual sizes on the same background, in monochrome before using persuasive mockups. State each direction's main advantage and tradeoff against the criteria, then recommend a choice.

Label generated raster images and application mockups as concept previews. Use them to judge direction, not to promise editable geometry or exact typography. If vector or rendering tools are unavailable, state the deliverable limitation and provide the useful work that is possible.

4. Refine the chosen mark

Turn the selected idea into deliberate vector geometry. Check contours, curve consistency, visual center, stroke weight, spacing, optical alignment, and negative-space openings. Change one major variable at a time when responding to feedback. Show the before/after when a subtle change matters.

Build and inspect final vector artwork separately from concept previews. An SVG containing an embedded bitmap is not an editable vector mark. Inspect traced geometry for excess nodes, irregular contours, and filled-in openings. Where exact lettering matters, verify the actual text and preserve an editable source alongside any outlined delivery version.

Treat hidden details as a bonus: the primary silhouette must work before the viewer discovers them. If an inner figure, letter, or metaphor disappears at small size, simplify it or create a designated micro variant. Do not declare a mark finished on a large presentation board alone.

5. Build the identity around it

Test a wordmark and any tagline in a compatible type family. Adjust actual proportions and tracking; do not assign a typeface by visual guess. Make a restrained palette with named usage roles. Check contrast on the intended background, particularly for small text. Create light and dark lockups deliberately instead of blindly inverting colors.

Use realistic applications to reveal problems: a docs header, favicon, social avatar, light/dark product UI, or one-color print. Keep implementation details out of the user-facing mockup unless they aid a design decision.

6. Verify before delivery

Verify the exported files, not only the working canvas, at the sizes and on the surfaces required by the brief. For digital icons, include actual 16, 24, 32, and 64 px previews. Inspect both native pixels and enlarged pixels; record where details close, alias, or disappear. Check one-color ink and reversed versions where needed. Verify clear space, clipping, live-text font fallbacks, and output on the intended light and dark surfaces. Use an optical variant at small sizes if necessary and state its threshold.

Keep a compact verification record: file or variant, size and background, check performed, observed result, and any unresolved issue. Distinguish visually inspected results from automated checks and checks not performed. A simulated print mockup does not establish physical print quality. After a revision, repeat checks affected by that change.

Deliver a compact handoff limited to the requested scope, drawing from:

• Approved primary mark, horizontal lockups, small-size mark, and monochrome variants as editable SVG where appropriate.
• PNG previews and target-size raster assets when needed.
• Color values, typography choices or fallback caveats, spacing and size rules, and do/don't guidance.
• A concise decision log: chosen direction, what was rejected, and unresolved limitations.

Separate user approval from technical verification. Report work as explored, refined, or verified for named uses according to what actually happened. Claim production readiness only for specified uses with completed checks and reviewed choices; identify remaining limitations. Never invent approval or successful checks. If the user wants implementation in a repository, inspect that repository and its instructions before editing. If they want a prompt for another coding agent, link to the final assets and explicitly warn when conversation-scoped links may require attaching the files in the new session.

Conversation rhythm

Show one meaningful decision point at a time. Interpret critique as a request to revise the artifact. State what changed and why, then present the visual. After the mark is selected, complete the size, color, and asset checks before calling the brand finished.

For work spanning multiple rounds or sessions, maintain a short project decision log in the working folder, such as design-decisions.md. Record the selected concept, approved elements, rejected directions and reasons, current asset paths, unresolved questions, and next step. Update it at meaningful decisions and read it before resuming; distinguish the user's decisions from your recommendations. For a small one-off edit, a concise handoff in the conversation is sufficient.