Ein Webdesign-Angebot kann Strategie, UX, UI und responsive Gestaltung nennen, ohne festzulegen, welche editierbaren Gegenstände das Praxisteam am Ende erhält. Ein Screenshot zeigt eine Oberfläche. Er zeigt aber nicht zwingend Sitemap, Komponentenlogik, Inhaltsstatus, Asset-Herkunft, Breakpoints, Reviewverlauf oder Übergabereife.
DE-145 vergleicht deshalb keine behauptete Wirkung. Der Einkaufsgegenstand ist ein überprüfbarer Designstand. Discovery erzeugt ein bestätigtes Problem- und Nutzeraufgabenregister. Informationsarchitektur erzeugt Seiten- und Navigationsbeziehungen. UI-Arbeit erzeugt Komponenten und Zustände. Review und Export erhalten die Verbindungen zwischen diesen Objekten.
Der neutrale Pilot enthält eine abstrakte Praxisvorstellung, eine organisatorische Informationsseite, eine Ratgeberklasse und eine Kontaktaufgabe. Es gibt keine echte Praxis, keine Person und keine klinische Seite. Leere Content-Felder, synthetische Bilderkennungen und neutrale UI-Zustände machen sichtbar, ob die Agentur Lücken erhält oder erfindet.
Die Scope-Grenzen sind bindend. DE-141 besitzt Sucharchitektur und SEO-Abnahme, DE-144 Portfoliosteuerung, DE-146 Code, Integrationen und Deployment. DE-145 darf diese Nachbarbereiche referenzieren, besitzt aber nur die Designartefakte und ihre kontrollierte Übergabe.
theStacc veröffentlicht DE-145 und bietet zugleich den auf Rang drei genannten Managed-Service mit Website-Erstellung an. Dieser wirtschaftliche Interessenkonflikt beeinflusst Auswahl und Reihenfolge. Das Herausgeberangebot erhält keine bevorzugte Platzierung. Kein Anbieter hat für die Aufnahme bezahlt. Die Darstellung beruht auf vier offiziellen URLs, die am 30. August 2026 erreichbar waren: den Webdesign-Seiten von Bop Design und Lounge Lizard, der Managed-Services-Seite von theStacc sowie den Designtipps der W3C Web Accessibility Initiative. Wir haben keinen Anbieter, Vertrag, Retainer, Account, Zahnarzt, keine Praxis, Website, Sitemap, Wireframe, Grafik, Datei, Inhalt, Freigabe, Entwicklung, Messung, Rechnung, Kündigung, Recovery oder Übergabe praktisch getestet. Preise, Laufzeiten, Teamzuschnitt, deutschsprachige Betreuung, Sicherheit, Vertragsbedingungen, Berechtigungen, Datenqualität, Support und Eignung bleiben offen. Anbieterquellen belegen nur den eigenen beschriebenen Leistungsbereich und keine objektive Überlegenheit. Der Pilot verwendet abstrakte Nutzeraufgaben, neutrale Seitenklassen, leere Content-Felder und synthetische Asset-Kennungen. Er enthält keine realen Praxen, Zahnärzte, Patienten, Websites, Fälle, Testimonials, Bewertungen, Preise, Retainer, Tests, Rankings, Leads, Umsätze, Personen, Prüfer oder Eigentümer. Klinische, diagnostische, therapeutische, sicherheitsbezogene, rechtliche, datenschutzbezogene, patientenbezogene und patientenaktivierende Aussagen bleiben vollständig außerhalb. DE-141 besitzt organische SEO, DE-142 lokale Profile, DE-143 Social Media, DE-144 breite Marketingsteuerung und DE-146 technische Webentwicklung. DE-145 besitzt ausschließlich Discovery, Informationsarchitektur, visuelle und UI-Arbeit, Content-Handoff, Designreviews, Asset-Verwahrung und Designexport. Eine fachkundige Prüfung, eine deutsche Sprachprüfung und ein Wartungsverantwortlicher sind nicht benannt. DE-145 bleibt needs_human_review und ist nicht automatisch zur Veröffentlichung freigegeben.
Die kurze Antwort
Bop Design führt den neutralen Auswahlpilot an, weil die offizielle Seite Discovery, erste Konzepte, Sitemap, Design, Content und SEO, Entwicklung sowie Launch als benannte Prozessstufen aufführt. Lounge Lizard folgt mit Strategie, UI/UX, Content-Struktur, responsive Design, Testing und Launch. theStacc bleibt wegen Herausgeberkonflikt und nicht dokumentiertem Designprozess auf Rang drei. Keine Quelle belegt Dental-Eignung oder Ergebnisse.
- Bop Design: Praxisteams, die Discovery, Sitemap, Design, Content-Handoff und Entwicklungsübergabe als getrennte Artefakte demonstrieren lassen möchten
- Lounge Lizard: Praxisteams, die strategische Gestaltung, UI/UX, Content-Struktur, responsive Zustände und einen klaren Handoff in Entwicklung prüfen wollen
- theStacc: Praxisteams, die einen indirekten Website-Service unabhängig gegen spezialisierte Designprozesse abgrenzen möchten
Der beschaffbare Designprozess für eine Zahnarzt-Website
Der Designauftrag beginnt mit einem Discovery-Register. Darin stehen abstrakte Nutzeraufgaben, Seitenklassen, vorhandene Systeme, offene Inhaltsfelder, Designabhängigkeiten und verbotene Aussageklassen. Im Pilot fehlen reale Praxisangaben. Eine Agentur soll die Lücken ordnen, nicht mit plausibel klingenden Details füllen.
Eine Nutzeraufgabe ist noch keine Zielgruppe mit erfundenen Eigenschaften. DE-145 verwendet neutrale Aufgaben wie organisatorische Information finden, Themenklasse überblicken oder Kontaktweg erkennen. Demografie, Diagnose, Behandlungssituation und Patientenerwartung bleiben ausgeschlossen. Die Agentur kann Struktur testen, ohne eine reale Person zu konstruieren.
Informationsarchitektur verbindet Seitenklasse, Navigationspfad, Inhaltsverantwortung und Übergabestatus. Eine Sitemap ist kein bloßes Kästchenbild. Jede Seite benötigt einen Auftrag, eine Quelle, offene Felder, abhängige Templates und bekannte Nachbarseiten. Suchintention aus DE-141 kann eine Eingabe sein, bleibt aber ein eigener Prüfpfad.
Wireframes trennen Struktur von visueller Oberfläche. Der Pilot nutzt neutrale Flächen für Überschrift, Orientierung, Hauptinhalt, unterstützende Information und nächsten Schritt. Kein medizinischer Text und kein Praxisversprechen wird eingefügt. Bewertet werden Hierarchie, Zustände, Inhaltsbedarf und Übergabefähigkeit.
Das visuelle System beginnt mit Design-Tokens und wiederverwendbaren Komponenten. Farbe, Typografie, Abstand, Raster, Form, Bildbehandlung und Zustandslogik werden als benannte Objekte geführt. DE-145 erfindet kein Praxislogo und keine Markenregel. Eine vorhandene Quelle müsste später jede reale Markenentscheidung tragen.
UI-Komponenten besitzen mehr als einen Idealzustand. Navigation, Schaltfläche, Formularfeld, Akkordeon, Karte und Hinweis benötigen Varianten für Fokus, Fehler, leer, geladen und schmalen Bildschirm, sofern sie im Design vorkommen. Der Pilot setzt neutrale Zustände ein und behauptet keine technische Umsetzung.
Die W3C Web Accessibility Initiative veröffentlicht Designtipps für Webzugänglichkeit. DE-145 verwendet diese Quelle nicht als Zertifikat und erklärt keinen Anbieter für konform. Sie begründet nur Fragen zu Kontrast, Informationsvermittlung, Fokus, Formularen, Alternativwegen und responsiver Gestaltung innerhalb des Designreviews.
Content-Handoff verbindet Feldname, Quelle, erlaubte Aussageklasse, Zeichenrahmen, Status und verantwortliche Rolle. Ein Blindtextfeld verdeckt offene Arbeit und ist im Pilot nicht erlaubt. Stattdessen bleibt ein Inhaltsbedarf als neutraler leerer Zustand sichtbar, bis eine belastbare Quelle und zuständige Prüfung vorliegen.
Bild- und Asset-Verwahrung erhält Herkunft, Dateityp, Bearbeitungsstand, Nutzungsstatus, Zuschnitt und Designverwendung. Der Pilot enthält keine reale Aufnahme. Eine synthetische Kennung reicht, um zu prüfen, ob Rohdatei, bearbeitete Variante, Platzierung und spätere Ersetzung verbunden bleiben.
Reviewstufen folgen dem Artefakt. Discovery, Sitemap, Wireframe, visuelle Richtung, Komponenten, Seitendesign und Übergabepaket erhalten eigene Entscheidungen. Eine genehmigte Sitemap autorisiert kein später geändertes Seitendesign. Eine visuelle Freigabe bestätigt weder Inhalt noch technische Umsetzung.
Änderungsrunden werden nicht nur gezählt, sondern adressiert. Jede Rückmeldung verweist auf Artefakt, Version, Entscheidung, offene Frage und erwarteten nächsten Zustand. Eine Sammelmail ohne Objektbezug kann nicht zuverlässig in eine Designhistorie überführt werden. Der Pilot verlangt einen lesbaren Reviewverlauf.
Responsive Design wird an definierten Layoutzuständen geprüft. Ein Desktopbild wird nicht lediglich verkleinert. Navigation, Textfluss, Bildzuschnitt, Komponentenreihenfolge und Interaktionsfläche brauchen dokumentierte Anpassungen. DE-145 führt keinen Browser- oder Gerätetest aus und behauptet keine technische Performance.
Design und Entwicklung besitzen einen klaren Übergabepunkt. Bop Design und Lounge Lizard beschreiben auf ihren Seiten auch Entwicklung. Diese Quelle belegt, dass beide Bereiche angeboten werden, macht sie aber nicht zu demselben Liefergegenstand. DE-145 endet bei spezifiziertem Design; DE-146 prüft Code und Deployment separat.
Der Handoff an Entwicklung enthält Sitemap, Komponentenregister, Tokens, Layoutzustände, Asset-Verweise, Content-Felder, Interaktionshinweise und bekannte offene Entscheidungen. Ein Link auf eine Designoberfläche allein reicht nicht. Dateizugriff, Version, Exportformat und Abnahmestatus müssen auch nach Projektende verständlich bleiben.
Recovery beginnt vor dem Verlust einer Designplattform. Das Praxisteam fragt nach institutionellem Besitz, Projektzugriff, Bibliotheken, verknüpften Assets, Exporten, Versionshistorie und Entzugsweg. Der Pilot simuliert keinen echten Kontoverlust. Er prüft nur, ob ein neutraler Recovery-Fall eine benannte Grenze und Übergabe besitzt.
Der Designexport umfasst editierbare Quelldateien oder nachvollziehbare Exporte, Asset-Verzeichnis, Komponentenübersicht, Tokens, Seiten- und Zustandsmatrix, Inhaltsstatus, Reviewentscheidungen und offene Fragen. Ein PDF kann die Richtung dokumentieren, ersetzt aber keine bearbeitbare Designgrundlage.
DE-144 kann Webdesign als Kanalabhängigkeit koordinieren, besitzt aber keine Gestaltung. DE-146 kann ein freigegebenes Design implementieren, darf jedoch offene Designentscheidungen nicht stillschweigend lösen. DE-145 hält die Artefaktgrenze sichtbar, damit Design, Entwicklung und Marketing getrennt abgenommen werden.
Branchenspezifische Nachweise, nach denen Sie fragen sollten
- Discovery erfasst Aufgaben und Lücken, ohne Praxis-, Patienten- oder Ergebnisangaben zu erfinden.
- Sitemap und Navigation verweisen auf Seitenauftrag, Quelle und Inhaltsstatus.
- Wireframes halten offene Content-Felder sichtbar statt sie mit Platzhaltertext zu verdecken.
- Tokens, Komponenten und responsive Zustände werden als zusammenhängendes Designsystem geführt.
- Jede Reviewentscheidung gilt nur für ein benanntes Artefakt und eine konkrete Version.
- Asset-Herkunft, Bearbeitungsstand, Nutzung und Ersetzung bleiben miteinander verbunden.
- Designübergabe und technische Entwicklungsabnahme sind getrennte Vertragsenden.
- Quelldateien, Exporte, Bibliotheken und offene Fragen sind außerhalb des Agenturkontos lesbar.
So haben wir die Anbieter bewertet
Bop Design steht vorn, weil die offizielle Seite einen klar benannten Prozess aus Discovery, ersten Konzepten und Sitemap, Design, Content und SEO, Entwicklung sowie Launch beschreibt. Diese Stufen passen am direktesten zum neutralen Artefaktpilot. Sie belegen keine Dental-Eignung, Barrierefreiheit, konkrete Übergabequalität oder Resultate.
Lounge Lizard folgt. Die offizielle Webdesign-Seite nennt strategisches Denken, UI/UX, Content-Struktur, responsive Design sowie einen kundenbezogenen Ablauf über Design, Content, SEO, Entwicklung, Testing und Launch. DE-145 übernimmt keine Fallstudien, Kennzahlen, Testimonials oder Ergebnisbehauptungen. Bewertet wird nur der dokumentierte Umfang.
theStacc steht auf Rang drei. Die Managed-Services-Seite beschreibt Website als Servicebereich und sagt, dass eine Website erstellt, gehostet und verwaltet werden kann. Sie dokumentiert auf dieser Quelle jedoch keinen Discovery-, Sitemap-, Wireframe-, UI-, Review- oder Designexportprozess. Damit bleibt die Passung zu DE-145 indirekt.
theStacc ist zugleich Herausgeber. Der Anbieter erhält keine bevorzugte Platzierung und muss denselben neutralen Pilot unter unabhängiger Fach- und Sprachprüfung durchlaufen. Preise, Mengen, Fallbeispiele und Ergebnisbehauptungen der Quellseite werden nicht übernommen. Die Quelle belegt nur den eigenen beschriebenen Website-Umfang.
Die W3C Web Accessibility Initiative dient als methodische Quelle und ist kein Anbieter. Ihre Designtipps stützen Fragen zu zugänglicher Gestaltung. DE-145 behauptet keine Prüfung, Konformität oder Zertifizierung eines Kandidaten. Umsetzung und technischer Test bleiben bei DE-146 und einer später benannten menschlichen Prüfung.
Preise, Retainer, Websites, Tests, Rankings, Leads, Umsatz, Patientenbezug, Testimonials und Fallstudien fließen nicht in die Reihenfolge ein. Jeder Rang ist eine redaktionelle Passung zum abstrakten Designpilot. Discovery, IA, UI, Content-Handoff, Review, Assets, Recovery und Export bleiben zu demonstrieren.
| Kriterium | Gewichtung | Was gezählt hat |
|---|---|---|
| Discovery und Seitenauftrag | Hohe Priorität | Nutzeraufgaben, Quellen, Lücken, Seitenklassen und Ausschlüsse werden vor der Gestaltung geklärt. |
| Informationsarchitektur und Wireframes | Hohe Priorität | Sitemap, Navigation, Hierarchie, Inhaltsbedarf und Abhängigkeiten bleiben als eigene Artefakte erhalten. |
| Visuelles System und UI-Zustände | Hohe Priorität | Tokens, Komponenten, Breakpoints und Zustände ersetzen unverbundene finale Screens. |
| Content- und Asset-Handoff | Hohe Priorität | Felder, Quellen, Dateien, Nutzungsstatus, Varianten und Ersetzungen bleiben referenziert. |
| Reviewstufen und Änderungsverlauf | Hohe Priorität | Entscheidungen gelten nur für konkrete Artefakte und Versionen und öffnen sich bei Änderung erneut. |
| Designexport und Recovery | Mittlere Priorität | Quelldateien, Bibliotheken, Exporte, Zugriffe und offene Fragen bleiben außerhalb übernehmbar. |
Jeder Anbieter musste dieselben Mindestanforderungen erfüllen, bevor seine Position überhaupt betrachtet wurde.
- Eine erreichbare offizielle Seite beschreibt Webdesign oder einen dokumentierten Website-Erstellungsbereich.
- Der Umfang lässt sich mit abstrakten Seitenklassen, leeren Content-Feldern und synthetischen Assets prüfen.
- Ungeprüfte Preise, Resultate, Testimonials, Fallstudien und Dental-Eignung werden nicht übernommen.
- Designarbeit kann von SEO, Marketing und technischer Entwicklung als eigener Liefergegenstand getrennt werden.
- Discovery, Struktur, UI, Review oder Website-Erstellung sind auf der verwendeten Quelle sichtbar.
- Der Herausgeberkonflikt von theStacc bleibt sichtbar und verhindert eine bevorzugte Platzierung.
Die recherchierte Anbieterliste
Die Platzierungen folgen der veröffentlichten Methodik und dem Stichtag der Quellen; sie sind keine Ergebnisgarantie. Jede Karte nennt die stärkste Eignung und die Einschränkung, die eine Kaufentscheidung am ehesten verändert.
Bop Design
Belegte Stärken
- Discovery wird als erste Prozessstufe beschrieben.
- Erste Konzepte und Sitemap werden gemeinsam genannt.
- Design sowie Content und SEO erscheinen als eigene Stufen.
- Entwicklung und Launch machen einen Übergabepunkt fragbar.
Zu prüfende Grenzen
- Dental-Eignung wird durch die Seite nicht belegt.
- Wireframe-, Token- und Komponentenlieferung müssen gezeigt werden.
- Asset-Eigentum, Reviewrechte und Recovery bleiben offen.
- Deutsche Betreuung, Exporttiefe und Vertragsgrenzen sind ungeprüft.
Bop Design führt DE-145 an, weil die offizielle Seite den Prozess in Discovery, erste Konzepte und Sitemap, Design, Content und SEO, Entwicklung sowie Launch gliedert. Diese sichtbare Reihenfolge passt zum Artefaktpilot. Nicht belegt sind Dental-Eignung, deutsche Betreuung, W3C-Konformität, konkrete Reviewrechte, Asset-Eigentum, Recovery, Exporttiefe oder Resultate.
Übergeben Sie Bop Design ein abstraktes Discovery-Register mit vier neutralen Seitenklassen, offenen Content-Feldern und gesperrten Aussageklassen. Der Anbieter soll zeigen, wie Ziele, Nutzeraufgaben und Abhängigkeiten in eine Sitemap gelangen, ohne eine Praxisgeschichte oder Person zu erfinden. Discovery und Sitemap sind offiziell beschriebene Prozessstufen.
Lassen Sie eine Sitemap, ein Wireframe und einen visuellen Entwurf als getrennte Objekte anlegen. Ändern Sie nach simulierter Sitemap-Freigabe eine Seitenbeziehung. Der visuelle Stand darf die alte Entscheidung nicht verdecken. Die Quelle nennt erste Konzepte und Design, belegt aber keinen konkreten Versionsworkflow.
Prüfen Sie Content und SEO nur als Übergaben. Bop Design nennt beide in seinem Prozess. DE-145 übernimmt keine organische SEO-Abnahme aus DE-141 und keinen echten Text. Leere Felder erhalten Quelle, Status, Zeichenrahmen und zuständige Rolle, bis eine belastbare Fassung vorliegt.
Fordern Sie editierbare Designartefakte, Komponentenregister, Tokens, Assets, Reviewverlauf, offenen Status und Übergabe an DE-146. Entwicklung und Launch sind dokumentiert, bleiben aber außerhalb dieses Rankings. Rang eins folgt aus der Prozessklarheit. Keine Website oder Übergabe wurde praktisch getestet.
Quellen zu den Anbietern: Bop Design, offizielle B2B-Webdesign-Seite, abgerufen am 30.08.2026
Lounge Lizard
Belegte Stärken
- Strategisches Denken und UI/UX werden beschrieben.
- Content-Struktur ist auf der Service-Seite sichtbar.
- Responsive Design wird als eigener Bereich genannt.
- Design, Content, Entwicklung, Testing und Launch erscheinen im Prozess.
Zu prüfende Grenzen
- Dental-Eignung und deutsche Betreuung sind unbelegt.
- Konkrete Discovery- und IA-Artefakte müssen gezeigt werden.
- Reviewrechte, Asset-Eigentum und Recovery bleiben offen.
- Designexport und technische Übergabe wurden nicht geprüft.
Lounge Lizard steht auf Rang zwei. Die offizielle Seite beschreibt strategisches Denken, UI/UX, Content-Struktur, responsive Design sowie einen Prozess über Design, Content, SEO, Entwicklung, Testing und Launch. Das deckt zentrale Design- und Übergabefragen ab. Unbelegt bleiben Dental-Eignung, deutsche Betreuung, konkrete Discovery-Artefakte, Reviewrechte, Asset-Eigentum, Recovery, Exporttiefe und Resultate.
Geben Sie Lounge Lizard dieselben neutralen Seitenklassen und Quelllücken. Der Anbieter soll erklären, welche UX-Recherche, Content-Struktur und Designentscheidung daraus entsteht. Die Quelle nennt strategisches Denken und UI/UX. Sie belegt weder eine konkrete Dentalforschung noch einen bestimmten Discovery-Export.
Prüfen Sie ein responsives Komponentenpaket mit Desktop-, schmalem und Fehlerzustand. Die offizielle Seite beschreibt responsive Gestaltung und Zugänglichkeit als Ziel. DE-145 erklärt keine Konformität und führt keinen technischen Test aus. Erwartet werden nur dokumentierte Designentscheidungen und offene Prüffragen.
Ändern Sie eine synthetische Asset-Kennung nach der visuellen Freigabe. Der neue Stand muss erneut geprüft werden. Content, SEO, Entwicklung, Testing und Launch sind als Prozessbereiche sichtbar. Der Pilot trennt dennoch Inhalt, organische SEO, Design und technische Abnahme in eigene Verantwortungen.
Lassen Sie Quelldateien, Komponenten, Assets, Content-Felder, Reviewentscheidungen und Übergabe exportieren. Der Anbieter muss zeigen, wie Projektzugriff und Recovery ohne Agenturkonto funktionieren. Rang zwei folgt aus dem dokumentierten Umfang, nicht aus einer getesteten Website oder Designwirkung.
Quellen zu den Anbietern: Lounge Lizard, offizielle Webdesign-Service-Seite, abgerufen am 30.08.2026
theStacc Service des Herausgebers, Rang drei
Belegte Stärken
- Website wird als Bereich des Managed-Service genannt.
- Erstellung einer Website wird beschrieben.
- Hosting gehört zum sichtbaren Website-Angebot.
- Verwaltung wird auf der offiziellen Seite genannt.
Zu prüfende Grenzen
- Dienstleister und Herausgeber sind dasselbe Unternehmen.
- Ein Designprozess wird auf der Quelle nicht dokumentiert.
- Sitemap, UI, Reviews und Designexport bleiben offen.
- Custom Development, Dental-Eignung und Recovery sind unbelegt.
theStacc steht wegen Herausgeberkonflikt und indirekter Angebotsnähe auf Rang drei. Die Managed-Services-Seite beschreibt Website als Bereich sowie Erstellung, Hosting und Verwaltung, wenn noch keine Website vorhanden ist. Sie dokumentiert dort keinen Discovery-, Sitemap-, Wireframe-, UI-, Review- oder Designexportprozess. Dental-Eignung, konkrete Gestaltung, Custom Development, Rollen, Recovery, Handoff oder Resultate werden nicht belegt.
Übergeben Sie theStacc nur das abstrakte Discovery-Register. Der Anbieter soll zeigen, ob er daraus Sitemap, Wireframes und Designartefakte liefert oder ob der Service an einem anderen Website-Arbeitsstand endet. Die Quelle bestätigt Erstellung und Verwaltung, nicht die verlangten Designstufen.
Fordern Sie Tokens, Komponenten, responsive Zustände, Content-Felder und Asset-Verweise als neutralen Gegenversuch. Fehlt ein Artefakt im tatsächlichen Angebot, bleibt die Lücke sichtbar. DE-145 ergänzt keinen Designprozess aus allgemeinem Wissen oder aus der Bezeichnung Website.
Trennen Sie Erstellung, Hosting, Verwaltung und technische Umsetzung. Diese Bereiche können verbunden sein, brauchen aber eigene Liefergegenstände und eine Übergabe an DE-146. Die verwendete Quelle belegt keine Custom-Development-Methode, Integration oder Deployment-Abnahme.
Exportieren Sie jedes vorhandene Designobjekt, die Zugriffsgrenze und offene Fragen. Entziehen Sie eine begrenzte Testrolle. Wegen des Herausgeberkonflikts braucht jede Einordnung unabhängige Fach- und Sprachprüfung. DE-145 hat keinen theStacc-Service, Entwurf, Zugriff oder Export praktisch getestet.
Quellen zu den Anbietern: theStacc, offizielle Managed-Services-Seite, abgerufen am 30.08.2026
Vergleichen Sie den Workflow am eigenen Unternehmen
Prüfen Sie die unterstützten Managed Services, Freigabeoptionen, Veröffentlichungsziele und sichtbaren Grenzen von theStacc, bevor Sie sich entscheiden.
Drei Anbieter am neutralen Designartefakt-Pilot
Die Tabelle ordnet nur sichtbar dokumentierte Service- und Prozessbereiche einem abstrakten Designbedarf zu. Sie bestätigt keine Preise, Dental-Eignung, Konformität, Vertragsqualität, Website-Wirkung oder geschäftliche Ergebnisse.
| Anbieter | Leistungsmodell | Belegter Leistungsumfang | Geeignet für | Wesentliche Einschränkung |
|---|---|---|---|---|
| Bop Design | Expliziter End-to-End-Prozess | Discovery, Konzepte, Sitemap, Design, Content, Entwicklung, Launch | Artefaktstufen | Export zu zeigen |
| Lounge Lizard | Strategisches Custom-Webdesign | Strategie, UI/UX, Content, responsive Design, Testing, Launch | responsive UI | IA offen |
| theStacc | Indirekter Herausgeber-Service | Website erstellen, hosten und verwalten | unabhängiger Gegenversuch | Designprozess fehlt |
Einen Webdesign-Pilot ohne reale Praxis, Website oder Inhalte durchführen
Das Prüfpaket enthält abstrakte Nutzeraufgaben, neutrale Seitenklassen, leere Content-Felder, synthetische Asset-Kennungen, eine einfache Sitemapänderung und UI-Zustände ohne reale Marke. Es enthält keine Praxis, keinen Zahnarzt, Patienten, Fall, Website, Testimonial, Bewertung, Preis, Retainer oder geschäftliches Ergebnis.
Geprüft werden Discovery, Informationsarchitektur, Wireframe, visuelles System, UI-Zustände, Content-Handoff, Asset-Verwahrung, Review, responsive Spezifikation, Designexport, Recovery und Übergabe. Kein Anbieter wird als praktisch getestet oder als für Zahnärzte geeignet dargestellt.
1. Discovery ohne erfundene Praxisannahmen durchführen
Legen Sie vier abstrakte Nutzeraufgaben und Seitenklassen an. Jede erhält Quelle, offenen Inhaltsstatus, gesperrte Aussageklassen und bekannte Abhängigkeiten. Eine Agentur darf Lücken gruppieren und Fragen formulieren, aber keine Praxisdaten, Personen oder medizinischen Zusammenhänge ergänzen.
Trennen Sie Geschäftsanforderung, Nutzeraufgabe und Designhypothese. Der Pilot besitzt keine echte Zielgruppe. Eine Annahme bleibt als Annahme markiert und kann nicht durch ein hübsches Layout bestätigt werden. Spätere Forschung und fachliche Prüfung sind nicht Teil von DE-145.
Fordern Sie ein Discovery-Protokoll mit Entscheidungen, offenen Fragen und Artefaktplan. Der Anbieter soll zeigen, welche Ausgabe Sitemap, Wireframe, Content-Brief oder technische Übergabe speist. Ein allgemeines Workshop-PDF ohne referenzierte Folgeobjekte genügt nicht.
- Aufgaben abstrakt.
- Keine Praxisdaten.
- Lücken sichtbar.
- Hypothesen markiert.
- Entscheidungen referenziert.
- Folgeartefakte benannt.
2. Sitemap und Wireframes als eigene Artefakte prüfen
Erstellen Sie eine Sitemap mit neutralen Seitenklassen, Navigation, Elternbeziehung, Inhaltsquelle und Status. Verändern Sie eine Beziehung nach der ersten Entscheidung. Die Agentur muss zeigen, welche Wireframes und Seitendesigns dadurch erneut geöffnet werden.
Nutzen Sie Wireframes ohne echten Text. Benennen Sie Bereiche nach Aufgabe und Inhaltsstatus, nicht mit Blindtext. Ein leeres Quellenfeld bleibt sichtbar. So kann das Praxisteam Struktur beurteilen, ohne einen unverifizierten Inhalt später versehentlich zu übernehmen.
Übergeben Sie Sucharchitektur aus DE-141 nur als markierte Eingabe. Die Designagentur darf sie in Navigation und Seitenhierarchie berücksichtigen, bestätigt aber keine SEO-Behauptung. Sitemapfreigabe und organische SEO-Abnahme bleiben getrennt.
- Sitemap versioniert.
- Beziehungen sichtbar.
- Wireframes getrennt.
- Kein Platzhaltertext.
- SEO nur Eingabe.
- Folgeobjekte geöffnet.
3. Komponenten und responsive Zustände spezifizieren
Definieren Sie neutrale Tokens für Farbe, Typografie, Abstand, Raster und Form. Es gibt kein reales Logo und keine Markenfarbe. Die Agentur soll zeigen, wie Änderungen an einem Token in Komponenten und Seitendesigns verfolgt werden, ohne einzelne Screens manuell auseinanderlaufen zu lassen.
Wählen Sie Navigation, Schaltfläche, Formularfeld, Karte und Hinweis als Testkomponenten. Jede erhält relevante Zustände für Fokus, Fehler, leer, geladen und schmalen Bildschirm. DE-145 bewertet die Spezifikation, nicht die technische Implementierung oder Browserausgabe.
Nutzen Sie die W3C-Designtipps als Fragenkatalog, nicht als Konformitätsnachweis. Der Anbieter erklärt, wo Kontrast, Fokus, Informationsvermittlung, Formulare und Alternativwege im Design sichtbar sind. Eine spätere technische und menschliche Prüfung bleibt offen.
- Tokens neutral.
- Komponenten benannt.
- Zustände vorhanden.
- Responsive Varianten sichtbar.
- W3C nur Fragenkatalog.
- Keine Konformität behauptet.
4. Content und Assets kontrolliert übergeben
Registrieren Sie Content-Felder mit Seitenklasse, Aufgabe, Quelle, Zeichenrahmen, Status und zuständiger Rolle. Der Pilot enthält keinen echten Text. Eine fehlende Fassung bleibt offen und darf nicht aus Wettbewerberseiten oder allgemeinem Wissen ergänzt werden.
Legen Sie ein synthetisches Asset mit Rohdatei-, Bearbeitungs- und Zuschnittkennung an. Es enthält kein Bildmotiv. Jede Designverwendung verweist auf diese Kennung. Ändert sich der Nutzungsstatus, werden betroffene Artefakte sichtbar geöffnet.
Fordern Sie editierbare Dateien, Asset-Verzeichnis, Exportformate und Ersetzungsregeln. Ein eingebettetes Bild ohne Herkunftsbezug oder eine nur im Agenturkonto erreichbare Bibliothek besteht den Handoff nicht. DE-145 behauptet keine reale Nutzungsberechtigung.
- Content-Felder leer.
- Quellenstatus vorhanden.
- Asset synthetisch.
- Verwendungen referenziert.
- Dateien editierbar.
- Ersetzung geregelt.
5. Reviews an Versionen statt an Meetings binden
Geben Sie Discovery, Sitemap, Wireframe, visuelle Richtung, Komponenten und Seitendesign eigene Reviewzustände. Eine Entscheidung enthält Artefakt, Version, Rolle, Zeitpunkt und offene Bedingungen. DE-145 erfindet keine genehmigende Person.
Ändern Sie nach der visuellen Entscheidung ein Asset und einen Content-Status. Nur betroffene Artefakte öffnen sich erneut. Die Agentur muss zeigen, wie unveränderte Entscheidungen erhalten bleiben und wie neue Abhängigkeiten in der Reviewansicht erscheinen.
Führen Sie eine abgelehnte und eine offene Rückmeldung bis zum Export. Beide dürfen nicht als erledigt verschwinden. Ein Meetingprotokoll kann Kontext geben, ersetzt aber keine adressierbare Designentscheidung und keinen nächsten Zustand.
- Reviews artefaktbezogen.
- Version genannt.
- Rolle offen.
- Änderung gezielt.
- Ablehnung erhalten.
- Nächster Zustand sichtbar.
6. Designexport und Entwicklungsübergabe gemeinsam proben
Exportieren Sie Discovery-Register, Sitemap, Wireframes, Tokens, Komponenten, Seiten- und Zustandsmatrix, Content-Felder, Assets, Reviewentscheidungen und offene Fragen. Öffnen Sie das Paket außerhalb des Agenturportals und prüfen Sie Referenzen sowie Bearbeitbarkeit.
Erstellen Sie ein Handoff an DE-146 mit Spezifikation, nicht mit impliziter Designentscheidung. Der Entwicklungsauftrag darf offene Zustände nicht selbst lösen. Code, Integration, Hosting, Deployment und technische Recovery gehören nicht in die Designabnahme.
Entziehen Sie eine begrenzte Testrolle und beschreiben Sie einen neutralen Recovery-Fall. Institutioneller Zugriff und Export bleiben erhalten. Der nächste Designer oder Entwickler muss den freigegebenen Stand, offene Fragen und bekannte Ersetzungsregeln ohne das alte Konto verstehen.
- Artefakte exportiert.
- Extern geöffnet.
- Referenzen intakt.
- Entwicklung getrennt.
- Rolle entzogen.
- Recovery beschrieben.
Fehler, die einen SEO-Vergleich wertlos machen
- Discovery mit erfundenen Nutzerdetails füllen. Unbekannte Praxis-, Patienten- und Inhaltsannahmen bleiben offen und werden nicht als Designfakt dargestellt.
- Eine Sitemap als bloßes Kästchenbild liefern. Seitenauftrag, Quelle, Status, Navigation und Abhängigkeiten müssen an jeder Klasse hängen.
- Blindtext als Content-Handoff verwenden. Leere Felder brauchen sichtbaren Quellen- und Verantwortungsstatus statt kaschierter Inhaltslücken.
- Nur finale Desktopbilder abnehmen. Tokens, Komponenten, responsive Varianten, Fehlerzustände und Inhaltsbezüge gehören zum Designsystem.
- Eine Freigabe auf geänderte Assets übertragen. Neues Asset, neuer Text oder neuer Seitenbezug öffnet die betroffene Designentscheidung erneut.
- W3C-Hinweise als Konformitätszertifikat behandeln. Designtipps begründen Prüffragen, aber keine technische oder menschliche Bestätigung eines Anbieters.
- Design und Entwicklung gemeinsam abnehmen. DE-145 endet bei spezifizierten Artefakten, DE-146 prüft Code, Integration und Deployment.
- Quelldateien im Agenturkonto lassen. Institutioneller Zugriff, editierbare Dateien, Bibliotheken, Assets und Exporte müssen übertragbar sein.
- Nur einen PDF-Styleguide exportieren. Sitemap, Wireframes, Komponenten, Zustände, Content-Felder und Reviewverlauf gehören ebenfalls zur Übergabe.
Häufige Fragen
Welche Webdesign-Agentur eignet sich zuerst für den neutralen Pilot?
Bop Design beginnt DE-145 wegen der sichtbar beschriebenen Stufen Discovery, Konzepte, Sitemap, Design, Content, Entwicklung und Launch. Lounge Lizard folgt mit Strategie, UI/UX, Content-Struktur, responsive Design, Testing und Launch. theStacc bleibt wegen Herausgeberkonflikt und fehlendem Designprozess zuletzt. Keine Position belegt Dental-Eignung. Entscheidend sind Artefakte, Reviews, Assets und Export.
Was gehört in ein Webdesign-Angebot für eine Zahnarztpraxis?
Das Angebot nennt Discovery-Artefakte, Sitemap, Wireframes, visuelle Richtung, Tokens, Komponenten, responsive Zustände, Content-Handoff, Asset-Verwahrung, Reviewstufen, Quelldateien, Export, Recovery und Entwicklungsübergabe. Für jeden Bereich steht der letzte bezahlte Zustand fest. Allgemeines Website Design reicht nicht, wenn Bearbeitbarkeit, Eigentumsgrenze und offene Fragen unklar bleiben.
Welche Praxisdaten gehören in den Designpilot?
Keine realen Praxisdaten sind erforderlich. Verwenden Sie abstrakte Nutzeraufgaben, neutrale Seitenklassen, leere Content-Felder und synthetische Asset-Kennungen. Der Anbieter demonstriert Struktur, UI, Reviews und Handoff, ohne eine Praxis, einen Zahnarzt, Patienten, Fall, Website, Marke, Bild, Aussage oder Ergebnis zu erfinden. Sämtliche Angaben bleiben neutral.
Was muss ein Discovery-Ergebnis enthalten?
Das Ergebnis nennt Nutzeraufgaben, Seitenklassen, Quellen, Inhaltslücken, verbotene Aussageklassen, Designabhängigkeiten, Entscheidungen, offene Fragen und geplante Folgeartefakte. Es trennt bestätigte Eingaben von Hypothesen. Ein Workshopprotokoll ohne Referenzen zu Sitemap, Wireframe, Content-Brief oder technischem Handoff ist für den Pilot nicht ausreichend. Jede Ausgabe bleibt adressierbar.
Was ist der Unterschied zwischen Sitemap und Wireframe?
Die Sitemap beschreibt Seitenklassen, Hierarchie, Navigation und Beziehungen. Das Wireframe ordnet auf einer Seite Aufgaben, Inhaltsbereiche, Zustände und Interaktionen, noch ohne finale visuelle Gestaltung. Beide Artefakte erhalten eigene Versionen und Reviews. Eine Änderung der Sitemap kann betroffene Wireframes erneut öffnen, muss aber nicht jeden Screen verwerfen.
Welche Bestandteile gehören in ein Designsystem?
Ein Designsystem enthält benannte Tokens für Farbe, Typografie, Abstand, Raster und Form sowie wiederverwendbare Komponenten, Varianten, responsive Regeln und relevante Zustände. DE-145 verwendet nur neutrale Beispiele. Ein Satz finaler Screens ohne zugrunde liegende Regeln erschwert Änderung, Entwicklung, Review und spätere Übergabe.
Wie wird Webzugänglichkeit im Designpilot behandelt?
Die W3C-Designtipps dienen als Fragenkatalog für Kontrast, Fokus, Informationsvermittlung, Formulare, Alternativwege und responsive Gestaltung. Sie sind kein Zertifikat. Der Anbieter zeigt Designentscheidungen und offene Prüfanforderungen. Technische Umsetzung, Test und menschliche Bestätigung bleiben außerhalb von DE-145 und dürfen nicht behauptet werden.
Wie funktioniert ein Content-Handoff ohne fertige Inhalte?
Jedes leere Feld erhält Seitenklasse, Nutzeraufgabe, Quellenstatus, erlaubte Aussageklasse, Zeichenrahmen und zuständige Rolle. Es bleibt sichtbar offen, statt mit Blindtext oder erfundenem Text gefüllt zu werden. Das Design kann Layoutgrenzen zeigen, ohne eine unverifizierte Praxisinformation später versehentlich zur freigegebenen Fassung zu machen.
Welche Design-Assets sollte die Praxis erhalten?
Erwartet werden das Asset-Verzeichnis, verfügbare Roh- und Bearbeitungsdateien, Varianten, Zuschnitte, Nutzungsstatus, Designverweise und Ersetzungsregeln. Der Pilot nutzt nur synthetische Kennungen und behauptet keine reale Berechtigung. Entscheidend ist, dass ein Asset nicht nur eingebettet, sondern als übertragbares und referenziertes Arbeitsobjekt erhalten bleibt.
Wie sollten Designreviews dokumentiert werden?
Jede Entscheidung nennt Artefakt, Version, Rolle, Zeitpunkt, Status, Bedingungen und offenen nächsten Schritt. Discovery, Sitemap, Wireframe, visuelle Richtung, Komponenten und Seitendesign bleiben getrennt. Ändert sich ein Asset oder Inhaltsstatus, öffnen sich nur betroffene Artefakte. Eine Sammelmail oder Meetingnotiz ersetzt keinen adressierbaren Reviewverlauf.
Was gehört in den Webdesign-Export?
Exportiert werden Discovery-Register, Sitemap, Wireframes, Tokens, Komponenten, Seiten- und Zustandsmatrix, Content-Felder, Assets, Reviewentscheidungen, Quelldateien, Bibliotheken und offene Fragen. Das Paket wird außerhalb des Agenturportals geöffnet. PDF-Ansichten ergänzen die Richtung, ersetzen aber keine bearbeitbaren Designobjekte, Referenzen oder Versionen. Referenzen müssen erhalten bleiben.
Was trennt DE-145 von SEO und Digital Marketing?
DE-145 besitzt Informationsarchitektur, Wireframes, visuelle Systeme, UI-Zustände, Content-Handoff und Designexport. DE-141 besitzt organische SEO-Arbeit. DE-144 besitzt kanalübergreifende Marketingsteuerung. Such- oder Marketinganforderungen können Eingaben sein, doch eine Designfreigabe bestätigt weder Rankingwirkung noch Kampagnenplan, Messung oder geschäftliches Ergebnis. Beide Abnahmen bleiben unabhängig.
Was trennt DE-145 von Webentwicklung?
DE-145 endet bei spezifizierten Designartefakten, Content-Feldern, Assets, Reviews und Handoff. DE-146 besitzt Code, CMS-Implementierung, Integrationen, Hosting, Deployment, technische Tests und Recovery. Ein Anbieter kann beide Bereiche verkaufen, muss sie aber getrennt liefern und abnehmen. Offene Designentscheidungen dürfen nicht still in der Entwicklung gelöst werden.
Warum steht theStacc auf Rang drei?
theStacc bietet den verglichenen Managed-Service an und veröffentlicht zugleich DE-145. Die eigene Seite beschreibt Website-Erstellung, Hosting und Verwaltung, dokumentiert aber keinen Discovery-, Sitemap-, Wireframe-, UI-, Review- oder Designexportprozess. Rang drei macht Konflikt und indirekte Passung sichtbar. theStacc muss denselben unabhängigen Designpilot wie die spezialisierten Anbieter durchlaufen.
Warum bleibt DE-145 in menschlicher Prüfung?
Die Seite stützt sich auf offizielle Anbieter- und W3C-Quellen sowie einen abstrakten Pilot. Kein Anbieter, Vertrag, Zahnarzt, keine Praxis, Website, Sitemap, UI, Datei, Review, Entwicklung, Recovery oder Übergabe wurde praktisch getestet. Fachkundige Prüfung, deutsche Sprachprüfung und benannter Wartungsverantwortlicher fehlen. Deshalb bleibt der Status needs_human_review.
Quellen und redaktionelle Grundsätze
Lesen Sie die verlinkten Quellen zusammen mit der Methodik und dem Hinweis des Herausgebers in diesem Artikel. Prüfen Sie aktuelle Preise, Funktionen und Bedingungen beim jeweiligen Anbieter; ein Quellenverweis allein belegt keinen Praxistest.
Fordern Sie das Designsystem, nicht nur finale Screens
Ein belastbarer Auswahlpilot verfolgt Discovery, Sitemap, Wireframe, UI-System, Content-Felder und Assets durch getrennte Reviews. Danach werden Quelldateien, Zustände, offene Fragen und das Handoff an Entwicklung außerhalb des Agenturportals geöffnet. DE-145 braucht vor jeder Veröffentlichung weiterhin fachkundige Prüfung, deutsche Sprachprüfung und einen benannten Wartungsverantwortlichen.