# Design Phase
Source: https://docs.designbase.studio/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.
# Development Phase
Source: https://docs.designbase.studio/development-phase
**Implementation of the approved, content-populated design in Webflow with a structured review round.**
## **General Principle**
All feedback during the development phase is captured exclusively via HuddleKit. Feedback submitted via email, chat, or other channels cannot be considered. This is the only way to ensure a clear reference to the exact page, location, screen size, and browser.
Deviations from the approved Figma design and technical bugs are fixed at no charge. Change requests beyond that are billed at the agreed hourly rate or quoted separately.
## **Development Process**
We build the site within our internal Webflow workspace. This ensures technical integrity and prevents accidental edits during the build. We implement the exact content provided in Figma, delivering a fully populated site that is ready for launch.
## **Review Round**
Once development is complete, the client receives a staging link and, for transparency, read-only access to the Webflow backend. The basis for the review is exclusively the approved and populated Figma file. The client submits all collected feedback in HuddleKit and actively signals when the review is complete.
At that point, we pause the comment function and sort all feedback into two categories: bugs and change requests. We communicate clearly which items will be implemented within the project price and which fall outside the agreed scope, each with a brief explanation.
We address all identified bugs first to reach full design and content parity. Once this is verified and the client provides final sign-off, the original project scope is complete.
## **Post-Approval: Change Requests**
Change requests identified during the review are addressed after the original scope is signed off. They can be implemented before launch or after the site goes live, depending on the client's preference. Each change request is quoted separately and billed at the agreed hourly rate.
This separation prevents open-ended feedback loops and ensures the project is delivered and settled on schedule, while still allowing for late-stage enhancements.
## **Pre-Launch Content Support**
Because content is delivered and audited in Figma before the build, the need for reactive content support during or after development is significantly reduced. Where it does arise, it is typically related to secondary language content in multilingual projects or questions that come up after the team onboarding when the client begins managing content independently.
We are available for reactive support in these cases. This is billed at the agreed hourly rate and is not included in the project price. Scope and cost depend on the client and cannot be estimated as a flat fee.
## **Definition: Bug vs. Content Error vs. Change Request**
### **Bug**
A technical issue where the website does not match the approved Figma design. Examples include a CMS field that cannot be edited, a button that is not clickable, or an animation that does not behave as designed. Bugs are fixed at no charge.
### **Content Error**
An issue caused by content that was not correctly prepared or entered. Common examples include formatting artifacts from copy-pasting out of Word or other external tools, text that breaks the layout due to incorrect length, inconsistent image sizes, or unsupported file formats. Content errors are not part of our development scope and are not covered under bug fixes, regardless of how they appear visually.
### **Change Request**
Any deviation from the content or layout finalized in Figma prior to development. This includes structural changes, new features, updated copy, or image swaps that were not part of the locked Figma file. Change requests are processed as a separate work package after the main project scope is approved and billed at the agreed hourly rate.
These distinctions are communicated to the client before the project begins.
## **Refactoring- and Extensions-Projects**
For refactoring projects and website extensions without a complete design reference, the following applies: inconsistencies, minor oversights, and UI/UX issues we encounter during our work will be cleaned up. This is part of our quality standards, not a separate coordination item for every individual case.
For more significant changes, such as structural interventions in existing components, we give a brief heads-up in advance.
Clients who want an exact copy of the current state will get that. In this case, we explicitly document which issues we have intentionally left untouched.
# Intro
Source: https://docs.designbase.studio/intro
**How we work**
# **Our Project Process**
Transparency matters to us. Here you can find how we structure projects, how feedback works, and what you can expect from us.
Every project runs through three clearly defined phases. Each phase has its own deliverable, its own feedback process, and clear rules about what is still possible in that phase and what is not.
Content foundation, sitemap, and page structure.
Visual direction, design of all pages, and content structure.
Implementation of the approved design in Webflow.
## Interesting articles
Definitions of bugs, content errors, and change requests.
When and how we accept content during our process.
# Strategy Phase
Source: https://docs.designbase.studio/strategy-phase
**The sitemap as the central deliverable. Content foundation for all subsequent phases.**
The sitemap is the central deliverable of the strategy phase. It forms the content foundation for all subsequent phases and is often already included as part of the proposal. It may evolve throughout the strategy phase and will be finalized at the latest before transitioning into the wireframe phase. Adjustments after the wireframes are still possible, provided the conceptual scope remains comparable.
Pages with their own messaging, user journey, or specific conversion goals are always evaluated individually and quoted separately if needed.
Feedback during the strategy phase is only accepted as comments directly within the shared Figma file, not via email, lists, or any other channel. This is the only way to ensure a clear contextual reference to the planning.
## **Scope Changes**
Any changes to the agreed page scope, whether initiated by the client or by us, are explicitly evaluated against the existing scope. The client receives a clear response: either the change is within scope, or it will be assessed and quoted separately as an extension. We do not start implementing changes before this classification has been communicated.
## **Improvement Suggestions from Our Side**
If we identify a better solution during planning that would serve the project goals more effectively, we communicate this proactively. Such insights are part of the planning work. We make it transparent whether the suggestion can be implemented