Tausend Objekte auf der Karte. Der Kunde braucht eine Entscheidung

Eine Immobilienkarte vermittelt schnell Größe. Ins Viertel zoomen, Punkte erscheinen. Noch weiter zoomen, und es gibt mehr Punkte, als ein Kaufinteressent Zeit hat.

Ich untersuchte Developers Map und bereitete einen Entwicklungsvorschlag vor. Der Dienst selbst stammt nicht von mir. Meine Arbeit umfasst Nutzerreise-Audit, Produktkonzept und einen eigenständigen interaktiven Prototyp. Er nutzt Demodaten und ist kein neues laufendes Immobilienangebot.

Unten steht der gespeicherte Developers-Map-Prototyp mit Demoobjekten. Originaloberfläche und verfügbare Filter lassen sich ansehen.

Karte und Filter

Archivierte Oberfläche · Demodaten

Wo ich anfangen würde

Beim Bedarf: Kaufgrund, Budget, Schlafzimmer, gewünschter Termin und Zahlungsplan. Das Briefing sollte eigenständig gespeichert werden. Sonst beginnt jede Suche wieder bei Filtern, deren Bedeutung allein im Kopf des Maklers bleibt.

Danach folgt: Bedarf formulieren, Optionen finden, Informationen prüfen, vergleichen, dem Kunden zeigen und handeln. Die Karte hat darin einen wichtigen, aber klar umrissenen Platz.

Der zweite Bildschirm zeigt die vorbereitete Decision-Room-Ansicht. Sie gehört zum Diskussionsprototyp und bestätigt nicht die Einsatzreife des Hauptdienstes.

Entscheidungsraum

Archivierte Oberfläche · Demodaten

Mich interessiert die Phase nach der schönen Suche. Was wurde gefunden? Wie aktuell ist der Preis? Ist das Objekt verfügbar? Ist der Übergabetermin belegt? Null, unbekannt und lange nicht aktualisiert müssen unterschiedlich aussehen. Sonst lehrt die Oberfläche Vertrauen in sauber formatierten Datenmangel.

Eine Auswahl muss den Versand überstehen

Ich schlage eine gespeicherte Shortlist konkreter Optionen statt zufälliger Kartenpakete vor. Kundenversion und PDF müssen dieselben Objekte beschreiben wie die Makleransicht, besonders bei Änderungen vor dem Treffen.

Die nächste Ebene ist Decision Room als Vergleichsraum. Kompromisse werden sichtbar: eine Option passt zum Termin, eine andere zum Budget, eine dritte braucht einen anderen Zahlungsplan. Kunden reagieren auf konkrete Varianten; das Gespräch zerfällt nicht mehr in Screenshots mit „und dieses?“.

Launch Room behandelt im Konzept Änderungen und nächste Schritte: Welche Informationen wurden aktualisiert, was muss geprüft und erneut angesehen werden? Es ist ein vorgeschlagenes Szenario, kein Versprechen, dass der vorhandene Dienst bereits alles überwacht.

Warum zuerst ein Prototyp

Das Original hat eigene Technik und APIs. Ich schlage keinen Umbau auf meinen Lieblingsstack vor, nur um einen anderen Filter zu zeichnen. Ein getrennter HTML-, CSS- und JavaScript-Prototyp erlaubt die neue Reise und ihre Diskussion vor Eingriffen ins laufende System.

Auch andere Marktszenarien bleiben eine Erweiterbarkeitsdemo. Maskat, Tiflis oder Bali im Entwurf bedeuten keinen geprüften Objektkatalog dieser Städte.

Für mich ist das besonders interessant: ein leistungsfähiges Produkt nehmen und herausfinden, wo Menschen trotzdem allein entscheiden müssen. AI beschleunigt Recherche und Variantenbau. Wert entsteht, wenn aus Varianten ein begehbarer, prüfbarer Weg wird.

Ergebnis sind ein Vorschlag für eine neue Nutzerreise und ein separater Diskussionsprototyp. Briefing, Shortlist, Decision Room und Launch Room gehören zum Konzept, nicht zu einer Liste bereits veröffentlichter Developers-Map-Funktionen.

Verwandte Beiträge: Telegram-Support · Makler-CRM.