Design Phase

Visual direction, page design, structured feedback, and content preparation for development.

​

Design Briefing

Before starting the visual design work, we collaboratively define the strategic design direction. Target audience, competitive landscape, and project goals feed directly into the design decisions. The briefing creates the foundation for qualified feedback in all subsequent steps. Feedback is evaluated against strategic goals, not personal preferences.

​

Design Discovery

We develop two visual style directions based on navigation, hero section, and one content section. Both variants are presented and discussed in a call. There is one feedback round. The outcome is a final approved design direction that serves as the binding foundation for all remaining pages.

​

Remaining Pages

All desktop designs are delivered at once. Mobile designs are created for the homepage as well as for sections where the implementation approach is not self-evident. There are two structured feedback rounds following the window model: the client receives a defined time window, submits all collected feedback, and actively signals when they are done. Feedback is only accepted as comments directly within Figma, not via email, lists, or other channels. This is the only way to maintain a clear visual reference to the design. We review the feedback and communicate what will be implemented, what falls outside the agreed scope, and what we have resolved differently for design or technical reasons, each with a brief explanation.

​

Content Delivery

Before development begins, all page content must be finalized and placed directly within the approved Figma design files. This is the exclusive delivery format for static pages. We do not accept content via email, Word documents, PDFs, or any other external channel. For repeated page structures, such as product or solution templates used across multiple individual pages, the client duplicates the relevant frame in Figma for each instance and fills it with the final text and assets. Each frame represents one page, fully populated and ready for build. Once all content is in place, we perform a pre-development audit to verify that text lengths, image formats, and asset dimensions are layout-compatible. Development does not begin until this audit is passed.

​

CMS Content

For CMS-driven content types such as blog posts, case studies, or press releases, delivery via Figma is not required. Instead, we provide a Webflow-compatible CSV template that the client fills with their content and returns to us before the build begins. We then import the entries into Webflow. Post-import cleanup, such as internal links, tables, or embedded elements, is the client’s responsibility and is not included in the project price. If content is not available in a CSV-importable format, an alternative approach is to transfer content manually from an existing website, including any required cleanup work. This option must be scoped and agreed separately before work begins.

​

Multilingual Projects

For multilingual projects, Figma content is delivered in the primary language only. Secondary language content is entered directly into Webflow Localization by the client, independently of the Figma file. This applies as the standard approach, not an exception.

​

Content Lock

Before development begins, the client is given a defined window to finalize all content directly within the approved Figma file. Once the client confirms that all frames are fully populated and ready, we perform a pre-development audit and formally close the content for that stage. This is the content lock. From this point forward, the locked content is treated as binding. Text changes, asset swaps, or structural additions are no longer part of the current scope and will be handled as change requests at the agreed hourly rate.

​

Projects with master templates

For projects with master templates, the content lock occurs after the design is approved. The client populates all template instances in Figma, confirms completion, and the audit is passed before development begins.

​

Projects without master templates

For projects without master templates, the content lock occurs after the wireframes are approved and before the visual design begins. The client fills in all content directly within the wireframe frames, confirms completion, and that content serves as the structural and editorial baseline for the entire design phase. In both cases, the client receives explicit confirmation from us when the content lock is in place. The next phase does not begin until this confirmation has been issued.

​

Capacity and Project Delays

We plan our capacities across projects and align on this transparently during the kickoff, including vacation periods on both sides. Client-side delays in providing feedback result in the project being rescheduled in our planning. We cannot guarantee continuity in such cases. Concretely: if a delay runs into our vacation periods or capacity constraints, the project is paused until it can be resumed. This is not a penalty. It is the logical consequence of cross-project capacity planning.